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. These are probably the actual band definitions, more on that shortly.

Bytes 169-178 and 179-188 are literally the offset in db on each band, left and right channel. I see octal 377 at -1db, 376 at -2, and octal 1 at +1, octal 14 at +14.

Bytes 5 and 6 are going to be the crc, almost certainly. So let me figure out now what the band representation is.

The second set of EQ settings is in sector 2049. I guess the third set will be in sector 2050 and so on. Still going...

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. These are probably the actual band definitions, more on that shortly.

Ok, so it looks like the 4 bytes decodes thus at each db setting in a band:
+12db to 94578288
+11db at 84286808
+5db at 42224896
+4db at 37630220
0db to 23736102
-1db to 26634296
-2db to 29886364
-3db to 33527318
-4db to 37630220

But the only indicator of + versus - db seems to be the simple index in bytes 169-178 and 179-188, and those are literal, so I don't understand what the point of these are. I don't know enough about equalizer application to know what this might be for. Comments anyone?

Derrick, remember that the eq is selectable between 2x10 or 4x5 channels.

Hmmm. Ok, I guess I need to figure out how to do that

I don't know whether that'd match with anything in kernel land, and whether taking a look at arch/arm/special/empeg_mixer.c (and friends) would help. If the player is storing the raw values as written to the kernel's IOCTLs then they may match up. If the player is storing 'user-friendly' values and converting on the fly, then probably not.

Actually the 2x10 versus 4x5 (when I figure out how to do it) probably isn't a big deal, just something indicating how the 20 channels are split.

I'm going to play with Q and the band setting and see what happens now.

Oh, I forgot to put it back in "car" mode. Sigh.

Ok, so it looks like the 4 bytes decodes thus at each db setting in a band:
0db to 23736102

Q is at .55 by default when the above happens. If I change it
If I change Q
.56 gives 24165598
.54 gives 23306606

Ok, so this is the result of the parametric function, I guess. Duh. I'm not very quick.

Byte 189 starts 20 sets of 2 bytes which are literal encoding of the band in hz. So for 50hz it's octal 62 in byte 189 and 0 in byte 190. For 18khz it's 120, 106. It tops out at 18khz. I guess what's left are:
-figure out how to toggle 2-4 channel mode, i need to reboot the player
-figure out the parametric equation.

Ok, so it looks like the 4 bytes decodes thus at each db setting in a band:
0db to 23736102

Q is at .55 by default when the above happens. If I change it
If I change Q
.56 gives 24165598
.54 gives 23306606

If I push Q to its extremes:
100.1 gives 4294537728
0.01 gives 429496

The resulting number varies linearly with Q, but my higher math is so far gone that I can't quantify this. I'll leave the equation to someone else, and move on to figuring out how 4x5 versus 2x10 is set. If I need to visit my car to get tuner info, that will have to wait until tomorrow.

Oh, I forgot to record Q for each of the db settings.
0: .55
1: .62
2: .70
3: .78
4: .88
5: .98
6: 1.1

And it's symmetric.

Byte 12 gets set to one when you're in 4 channel mode. Instead of having (the 2 byte) decibel offsets at byte 169 it appears to be at byte 29. Looks like fronts are at 29 and 39, the rears at 34 and 44. I guess this is since if 4 channel is enabled it's only on in car mode.

And it looks like the parameters which would start at byte 229 in the 2 channel case start at byte 89 in the 4 channel case. Front bands start at 89 and 129, rear bands at 109 and 149.

It looks like there are 16 sets of eq parameters, so 16 sectors 2048-2063.

All that should be left for the EQ is figuring out how to calculate the parameter given the Q and "db" settings for each band.

Good thing I managed to miss this message. Not that it was a big deal to figure this out.

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.

Nope, the fake_tuner stuff works fine. Also looking at this now.

Changing a preset A1 changes 2 bytes at byte 263, which I'm guessing are a CRC on either a bank or a station. The station name starts at byte 269 and runs to byte 276. I'll guess bytes 277-279 are the station but I can't prove that yet.
Two bytes at byte 283, and 2 at byte 477 also seem to be changing, sometimes, and I haven't figured out what they are. I think I will sleep and try to find some time tomorrow.

Haha I remember when I did this same reverse-engineering stuff on the empeg_flash block that stores the player state. Great work... Ain't it fun?

I haven't done anything like this in a while; I was probably overdue.

Hey Derrick (or Peter if you're still tuned into this thread.)

Where's the current running order (not playlist) stored? If I could programmatically get the FID of the next and previous songs, it'd help me a lot so I can cache the lyrics. Otherwise, it can take a good 3-5 seconds while the player and the lyrics scroller are both trying to read the MP3 fid at the same time. I'd love to be able to cache a few songs in advance.

No clue. Maybe when I finish poking at tuner...

equalizer sectors begin with 'EQUA'
it looks like tuner station records begin with 'OIDR' but are 256 bytes; record A1 appears to start at offset 256 into the first sector of tuner data. The station name is 8 bytes starting at byte 13 of those records. Guessing, bytes 7 and 8 are a CRC.

Byte 5 is 1 for FM, 2 for AM. Bytes 21-24 appear to be the station, but I don't know what the encoding is yet.

Actually, duh. For AM the 1380 appears to be encoded as 1380000. For FM 104.3 is 104300000. So it's just the frequency in hertz. Bytes 25 through 36 seem to change when I switch bands but I have no clue yet what it is.


.

Wow, I'd be interested in the current running order also. If Mark was nice enough to make this available in XML like the playlists, I could include the current running order in the web interface (default page, below the now playing).

Tom

I am not sure that the current running order is actually stored ANYWHERE.

If it's a premade playlist that's running, well.. the FID for the playlist is stored in the flash savearea, along with the FID of the currently playing track.

If it's a randomly convoluted playlist, then they probably just do the randomization on the fly, with known randomizer seed (maybe also stored in the flash savearea?). They could step forward/back through the "playlist" by just (re)generating the pseudorandom sequence on the fly.

???

Actually, I partially take that back.. the current playlist FID is NOT stored in the flash savearea.. and I don't see any "randomizer" or "playlist position" fields in the savearea, either.

So the playlist FID must be on disk (dynamic data partition) somewhere, but there's still no need to store the entire playlist there, as playlists are already in the database. For a random shuffle, they just need to keep track of the random seed, so it could be regenerated on the fly. I don't know if "order tweaks" survive power loss -- anybody?

??

Okay, nevermind, the current play order IS on the dynamic partition -- Peter even said so, I just missed it earlier.

The first 512 sectors (each sector is 512 bytes long) of /dev/hda3 is used for the current play order. Here's what I know thus far, using a short playlist:

There is something resembling the playlist, but incomplete, in the first sector. In particular, the early entries in this playlist appear to have been zeroed out, but otherwise it is in the same format as what I report below:

In the second sector, is the playlist, stored 8-bytes per entry. Within each entry, the first 4-bytes are the FID (little endian byte order), and the second 4-bytes appear to be the same for all FIDS, at least that's the way it looks for my simple 3-album playlist test case. Let's call this the "FID table".

I do not know what determines the size of the playlist, but immediately following it on disk is the play sequence, with 4-bytes per entry. Each entry consists of a 4-byte (liitte endian byte order) position index for the "FID table". When the playlist is not being shuffled, these are simply the values 0, 1,2,3,4,5,.. in sequence. But press "Shuffle" on the remote, and then look at it again (after the disk activity indicator goes on and then off again..), and you'll see the same position indexes, but now in a randomized order, such as: 1a,c,14,16,7,0,9,f,..

The same wierd position indexes can be seen in the first sector as well.. shuffled there as well.

One could presume that for a longer playlist, these two copies of the running order will each span multiple sectors, instead of being contained within the first and second sectors.

The way I'm poking at this is easy: I just pop up the Hijack "Vital Signs" screen, and watch the FID change as I use the FRONT PANEL BUTTONS to change tracks. This gives me the running order, and allows me to move forward/back at will, and see the effects of shuffling. Then I also do a hexdump of the first 512*512 bytes of hda3 (fetch it from the player using httpd, and then dump it in hex using tools on my Linux box).

Okay, somebody else take over now.

Cheers

Yep, tweaks are retained over a power cycle according to my quick test - Whole player shuffled, 'Hate Artist' on first 4 artists, 'Like Artist' * 3 to get first 4 tracks by the same artist. Track count and shuffle order both restored as expected.

I wonder whether this is the reason that selecting a new playlist sometimes takes a while - a small playlist seems to load immediately, whereas a long playlist 'hourglasses' (Disks already spun up in both cases, shuffle off). Since the whole database is already in RAM, and we only need to know what the first 4 tracks are for display purposes, database access doesn't explain it. In both cases we only need to start caching the first track before starting, so that doesn't explain it either. But if we needed to write the running order to the dynamic data partition then that would be dependant on playlist size.

One could presume that for a longer playlist, these two copies of the running order will each span multiple sectors, instead of being contained within the first and second sectors.

Yes. One could also notice that this area isn't really big enough at 512 sectors or 256K. If, in your playlists, you've got four references to each FID (say, once in an Artists playlist tree, once in Decades/Years, once in Genre, and an average of once more in ad-hoc playlists) then playing the whole player with down-down-down uses 24 bytes in this area for each track (8 for the "FID table", known as the "programme" in the player code, and four lots of 4 for the "play sequence", known to us as the "running order").

This means that if you've got more than 10,901 tracks on your player (which is not at all out of the question for a grzelakian, sorry gargantuan, player), and play all of them, then it won't be able to remember your playlist over a power-down. This is a genuine reported problem, and a much bigger spur to completely reorganising the dynamic partition than the 28,000-or-so limit on the per-FID dynamic area. But, as I said, we won't get round to this for 2.0final.

Incidentally, there are three more 512-sector-long playlist dump areas at offsets 512, 1024 and 1536: the three bookmarks.

Peter