In the past, the justification for not doing so was that it wouldn't be worthwhile to do so since the format changes so much.

OK. At this stage of the game it's pretty clear that the format isn't going to change for 2.0. We will change it post-2.0 as it includes two of the hard limits on the total number of songs usable on a car-player.

So you've got /dev/hda3. It's 16 megabytes long, or 32,768 sectors of 512 bytes. Sectors 4,096 to 32,767 inclusive contain the dynamic data, one sector per FID. So the data for, say, FID 0x4230 would be at sector 4,096 + 0x423.

Each sector contains a 2-byte length field, a 2-byte CRC field, and a data structure the prefix of which is described in lib/protocol/dyndata_format.h in an emptool source release. The CRC algorithm, which obviously only applies to the main data structure and not the length and CRC fields, is the "CRC::CRC16" algorithm from lib/protocol/crc.h in an emptool source release. None of this has changed substantially since before v1.00, although the structure length has increased and some fields were never filled in in older releases.

As you'll have spotted, this imposes a maximum of 28,672 files on the player (in fact, sixteen less than that, because the first fid is 0x100 not 0). So at some post-2.0 point, we'll rejig it to store several fids' data per sector, and whatever tools you're going to write with the information in this post will break.

Of course, tools which use lib/protocol to read and write dynamic data, like emptool does, will be insulated from this change.

(The other hard limit I mentioned is on the size of playlist that can be remembered over a shutdown: this information is stored in the first 512 sectors, in a way which changed between v1 and v2.)

Peter