[EE] GPS logger with voice recording - Wear balancing for SD/MMC card needed?

Hi All,

I'm just working on the open source GPS logger with voice recording (to
facilitate recording tracks for the http://www.openstreetmap.org project).

The current architecture includes:
GPS module - http://www.f-tech.com.tw/datasheet/GPS/FGPMMOPA2.pdf -
first tests show, that it performs very well even at low level of GPS
signal.
CPU - Atmega32 or PIC18F4550 - not decided yet (the second one could
provide the USB access to the stored content, but Atmega32 is easier to
program...)
Slot for the SD/MMC card,
The microphone amplifier with the AGC (based on SSM2165 or similar, eg
this one:
http://www.cyfronika.com.pl/kityAVT/avt2312pdf.pdf [Polish, sorry])
UI - very limited. LED diodes or LCD display showing the quality of the
GPS signal and current operating mode. Switch ON/OFF, switch
record/pause, unstable switch - record voice annotation.
Device should be safely operable when driving a car o a bike.

The track will be stored in the NMEA format (no problem with 1GB SD/MMC
capacity).
The short voice annotations will be stored in 8-bit 8kHz PCM (also no
problem with this capacity).

The most important problem I'm facing right now is: how to store the
information on the SD/MMC card to balance the wear?
Does the internal controller perform any block readdressing to balance
the wear?

I'm not bound with any filesystem limitations, because i can use my own,
very simplified filesystem. The device will be dedicated mainly for
Linux users, so it will be possible to read the data either via USB (if
18F4550 will be used) or via FUSE based simple filesystem driver, or via
raw access to the block device.

I have some ideas like:

    * Using the whole card as a big circular buffer (well in fact the
      block 0 will hold an identifier of my "filesystem" to make sure
      that the card will not be treated as a corrupted volume formatted
      with other FS). Each 512-byte block will store it's 4-byte
      sequential number on the begining. Then I will be able to use a
      quick binary search algorithm to find the first free block, when
      starting a new track.
    * Using the first block to store the FS identifier and a number of
      the block storing the "begining block" of the filesystem. The
      begining block would be relatively heavily used when
      recording/erasing track, and if rewritten 10000 times or so it
      could be moved to the other block - which would require also
      updating of the block 0.

Which of the above approaches is better? Maybe I should use yet another one?
Maybe I shouldn't implement wear-balancing at all?
Any suggestions regarding the implementation of the "filesystem" and
other functionalities of the device will be appreciated.