I was just wondering if the data on the number of plays per track is stored anywhere you can access?

Or is it somwhere in dynamic partition?

It's part of the dynamic data partition.

logical place really.

Thanks Tony. Shame that stuff isn't documented.

Out of pure interest, what were you thinking of doing with the data? (maybe someone has already done it / is doing it).

Cheers, Sim

Your order number is 73
Order placed at Mon 3 Feb 2003 8:27 am

I've got 2 empegs and use rsync to update them. I was thinking it might be possible to somehow combine the play counter. Silly I know

Silly, maybe, but a complete reverse-engineering of that partition would be helpful for many reasons. There have been posts on this BBS by the Cambridge guys, suggesting that it's a fairly simple format and it shouldn't be all that hard to suss out.

Silly, maybe, but a complete reverse-engineering of that partition would be helpful for many reasons. There have been posts on this BBS by the Cambridge guys, suggesting that it's a fairly simple format and it shouldn't be all that hard to suss out.

Or they could just, *gasp* supply us with the format...

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. With that in mind, reverse-engineering it and then writing something which depends on that format wouldn't be any more productive. Why can't they just give us a spec?

Then they can tell us they didn't tell us the format, and not feel guilty. I'm debating reverse engineering it, but if I do I'm not putting out anything until I can figure out how to tie it to a version or disable itself if it doesn't match.

I think we will probably get the spec when 2.0 is released.

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

COOOOOOOOOOL.

Someone please put this in the Developer Info section, posthaste.

bing!

Cool. So... No mention was made of how the tuner presets are stored. Is that something that can be gleaned from the emptool sources? Or is our assumption that they're stored on the dynamic data partition incorrect? While we're at it, aren't the EQ presets stored there, too?

Peter,

Thanks for the info. Now for the fun :-)

In reply to:

---

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.

---

I guess Paul is worried about this limit

If you have 2 drives, does it double the number of tracks or does it only use hda3?

If you have 2 drives, does it double the number of tracks or does it only use hda3?

I think only the first drive is used to store dynamic data.

lib/protocol/dyndata_format.h doesn't mention tuner or EQ stuff, both of which are supposedly on the dyndata partition.

OW!!! It is not nice to put hard limits on things!!!

I still have some headroom, though. At latest figuring, I have 20,301 unique files on the player, including playlists. (4f4d0&1)

Well, it's good to know one thing:

They can keep close tabs on how well their software works at the edge of the envelope, just by using Paul as their guide.

It will take a little while to get out there, though. It took me this long to get to that 20,000 mark. They might be on 3.0 by the time I get close to the edge.

bing!

I'd prefer to see a big bold warning at the top of that entry, saying that while the information applies to all software versions between 1.00 and 2.00 inclusive, it will become incorrect after that (I realise that the text says that further in as well).

Another thing to bear in mind, is that none of the player software was written in the expectation that third-parties would be writing to that partition, and so if anyone does feel like writing a tool that accesses it directly and not via lib/protocol, they should keep a clean backup of the whole partition somewhere ready to dd it back again if their changes make the player crash.

People wishing to back up their EQ and tuner settings should back up the 32 sectors starting at sector 2,048. The format of these blocks has changed several times since 1.0.

While we're on, the other entry on that riocar.org page is slightly misinformed: the swap partition can't be used for anything other than a swap partition, or synchronising will fail.

Peter

People wishing to back up their EQ and tuner settings should back up the 32 sectors starting at sector 2,048. The format of these blocks has changed several times since 1.0.

What about since 2.0 Beta 13? We've been talking about using the GPS to reprogram one of the banks of tuner presets. Any chance that format will change between 2.0b13 and Final?

Well if they put 8 fids in each sector and start using both drives partition 3 you would be ok for a while as the max would be 458,752

I would have thought that they could multiple (8) fids per seconds with just a couple of lines of change in the code.

I'm going ahead and updating the entry with the disclaimers and such. I hope that when changes are made in the post-2.0 releases, we'll be able to get an update on how the format has changed.

Note that anybody who wants a remote PC/workstation tool for reading (or re-writing) the dynamic data partition can start out by simply using Hijack kftpd/khttpd to GET/PUT /dev/hda3 (16MB file).

For software on the player that doesn't use the Empeg libs, just open "/dev/hda3"), and lseek() to the byte offset for the sector you want to read.

Cheers

Is the skipped_count updated?

I selected 1 album and put it on repeat. After it playing a few tracks I started again skipped all the tracks (including the 1 I was watching multiple times)

Here's the data :-

  

0000000 003c 32f7 0000 0000 0000 0007 75bb 3e41

0000020 472f 1df4 0000 0000 55a9 1555 ffff aa9a

0000040 a956 aaaa aaff fabf aaab fffe aa96 aaaa

0000060 fff9 bfff 0000 0000 306b 0000 03b6 0000

0000100 0000 0000 0000 0000 0000 0000 0000 0000

Is the skipped_count updated?

No.

lib/protocol/dyndata_format.h doesn't mention tuner or EQ stuff, both of which are supposedly on the dyndata partition.

Working on it...

Bleah, I need to go put the empeg in the dash so it has a tuner in order to do that part usefully. I'll look at the eq stuff now.

Sector 2048 has the eq stuff in it. I'm still playing, but it looks like the left channel starts at byte 229 and the right channel at byte 269, (each of the EQ bands using 4 bytes) and the left and right use up through bytes 268 and 308.

Makes sense since there are 10 bands, I haven't yet figured out the encoding or the significance of bytes 178 and 188 (which are 0 until the EQ is modified, and which probably represent some sort of bitmask of which bands are active (left and right respectively) or of bytes 5 and 6 (but it's going to be size or checksum)

Actually I think I mischaracterized that slightly. Stay tuned.