iriver E10 database

[nyaochi]

This thread is for a porting effort for iriver E10 player.

Constituents:

• \System\E10.sys
• \System\db.dat
• \System\db.idx
• \System\db.dic
• \System\Tuner.DAT

Basic information:

• Byte order: big endian
• Text encoding: UCS-2 (or UTF-16)

Necessary tasks:

• Understand the structure of db.idx
• Make sure db.dic is constant

How to create 'clean' database with iriver plus 3:

• Open "C:\Program Files\iriver\iriver plus 3" folder and remove "plus2_0.db" and "plus2_0.bak"
• Open "D:\System" folder (change the drive letter for your environment) and remove "db.*"
• Transfer music files to the player
• Run iriver plus 3 and choose "Tools" -> "Portable Device" -> "Database Update"

[nyaochi]

E10.sys describes the hardware information in human-readable ASCII (INI, CR+LF) format. The file is 512 bytes long with space characters filled at tail. This file is useful to detect the model of a player connected as a UMS device.

The content of my E10.sys

Code:

[E10]
version = 1.4
language = kor
mode = UM
tuner = OK
space = 6G
DRM = 0
Burnkey = 1

[nyaochi]

A primitive source code is available:
http://pmplib.sourceforge.net/tmp/e10db.zip

[hullbr3ach]

An observation: It seems like entries in db.idx are ordered by Genre, within that by Album and within that by Song.

[nyaochi]

http://pmplib.sourceforge.net/tmp/e10db/

* e10_root1.zip
[E:\01_01_StadiumArcadium.ogg]
Title: Dani California
Artist: RED HOT CHILI PEPPERS
Album: STADIUM ARCADIUM JUPITER
Year: 2006
Genre: Rock
Track #: 01
Duration: 04:42
Bitrate: 128kbps

* e10_root1_rating5.zip : e10_root1.zip
[E:\01_01_StadiumArcadium.ogg]
Rating: 5

* e10_root2.zip : e10_root1.zip
[E:\01_02_StadiumArcadium.ogg]
Title: Snow ((Hey Oh))
Artist: RED HOT CHILI PEPPERS
Album: STADIUM ARCADIUM JUPITER
Year: 2006
Genre: Rock
Track #: 02
Duration: 05:34
Bitrate: 128kbps

* e10_root3.zip : e10_root2.zip
[E:\Music\RedHotChiliPeppers\StadiumArcadium\01_03_StadiumArcadium.ogg]
Title: Charlie
Artist: RED HOT CHILI PEPPERS
Album: STADIUM ARCADIUM JUPITER
Year: 2006
Genre: Rock
Track #: 03
Duration: 04:37
Bitrate: 128kbps

* e10_root4.zip : e10_root3.zip
[E:\01_Bright Idea.ogg]
Title: Bright Idea
Artist: Orson
Album: Bright Idea
Year: 2006
Genre: Pop
Track #: 01
Duration: 04:14
Bitrate: 128kbps

* e10_root5.zip : e10_root4.zip
[E:\02_No Tomorrow.ogg]
Title: No Tomorrow
Artist: Orson
Album: Bright Idea
Year: 2006
Genre: Pop
Track #: 02
Duration: 02:51
Bitrate: 128kbps

[nyaochi]

http://pmplib.sourceforge.net/tmp/e10db/

* e10_many.zip
92 tracks, 7 albums
- James Blunt - "Back to Bedlam" (Rock), 2005
- JAMIROQUAI - "Dynamite" (Acid Jazz), 2005
- Jamiroquai - "High Times (Singles 1992-2006)" (Pop), 2006
- Orson - "Bright Idea" (Pop), 2006
- SCISSOR SISTERS - "TA-DAH" (Pop), 2006
- THE ZUTONS - "Tired Of Hangin'around" (Rock), 2006
- Zutons - "Who Killed The Zutons [JP]" ({empty genre}), {empty year}

[hullbr3ach]

Rating: I just compared root1 and root1_rating5 using a binary diff program.

There are a lot of changes between the two files, just for having a different rating. What stood out though was that at position 04B7 the value changes from 01 to 05.

Just to be sure, did the file have any rating before you set it to 5? If not, the above might be a coincidence and it would be nice if you could post the same database with the file set to rating 1.

[hullbr3ach]

Database size: Comparing root1 and root2.
It seems that the database size/end is indicated by the value in 0002 and 0003 (or possibly a dword from 0000-0003). It marks the offset for the end of the last entry plus one dword of 0s.
E.g. in root1 it is set to 00 00 04 BD while in root2 it is 00 00 06 B1.

[hullbr3ach]

Filename entries: Examining root2.

It looks like there is a pointer to the end of a filename entry just before each filename.
E.g. for the first filename in root2, the dword at 00E3-00E6 is set to 00 00 01 1B. Looking at this position, it is visible that it points to the end of the filename.
For the second file, the dword at 04ED-04F0 is set to 00 00 01 1B. Looking at this position, it is also right at the end of the filename.

[hullbr3ach]

File iteration pointers: Examining root3

This one looks important.
Before each filename entry, there appears to be a navigation block. The block consists of a dword pointing to the previous block, followed by a dword pointing to the next block.

Example: I think the first navigation block lies at 00CF-00D2. This dword is followed by 00 00 01 7E at position 00D3-00D6. This value is the offset for the next navigation block.

There you find 00 00 00 8E (I don't yet know where it points to exactly, but it definitely points to somewhere in the previous entry). Following is the dword 00 00 08 84 at position 0182-0185 which points to the navigation block for the next file.

There you find 00 00 01 9E which points back to the second file (again, I don't exactly know where in the second entry), followed by a dword forward pointer of 0s, as there is no further file (#4).

[hullbr3ach]

File pointers, continued: Examining root3

Behind the navigation block described in the previous post, there appears to be a second navigation block consisting of a dword forward and dword backward pointer. I can't yet tell what exactly the difference is. Maybe it just allows navigation to songs in the same album, while the first one is for overall database navigation.

As expected, the first such block has it's backwards pointer at 00D7 pointing to 00  00 00 42 (don't exactly know where this is). The forward pointer points to 00 00 01 86 which is the beginning of the next navigation block (the one described here).

The second track has a backwards pointer to 00 00 00 00 (also don't know exactly where) and a forward pointer to 00 00 08 8C for song 3. And so on.

[hullbr3ach]

Following the second navigation block, there seems to be a dword serving as some sort of counter for songs within an album. It doesn't seem to be the track number though.
After this counter, the filename length pointer starts as described above.

[hullbr3ach]

Summarizing what I found so far, a file entry looks like this:

Description:	pointer to previous track, pointer to next track	pointer to previous track, pointer to next track (both only within albums?)	(album?) track counter (!= track number)	pointer to end of filename string	filename	pointer to previous track (same as in nav-block 1)
Example for root3:	00 00 00 39, 00 00 01 7E	00 00 00 42, 00 00 01 86	00 00 00 03	00 00 01 1B	.0.1._.0.1._.S.t. a.d.i.u.m.A.r.c. a.d.i.u.m...o.g. g	00 00 00 39

[nyaochi]

Rating: I just compared root1 and root1_rating5 using a binary diff program.

There are a lot of changes between the two files, just for having a different rating. What stood out though was that at position 04B7 the value changes from 01 to 05.

Just to be sure, did the file have any rating before you set it to 5? If not, the above might be a coincidence and it would be nice if you could post the same database with the file set to rating 1.

I regenerated root1_rating5.zip by changing the rating value on iriver plus 3. I once modified the rating value on the player but this action might change many fields in the database since the player may maintain playback information (playcount, etc.). I replaced the root1_rating5.zip in the server. The WORD value at 0x01AA in e10_root1 or e10_root1_rating5 seems to indicate the actual value of the rating.

[nyaochi]

Database size: Comparing root1 and root2.
It seems that the database size/end is indicated by the value in 0002 and 0003 (or possibly a dword from 0000-0003). It marks the offset for the end of the last entry plus one dword of 0s.
E.g. in root1 it is set to 00 00 04 BD while in root2 it is 00 00 06 B1.

Yes, the first DWORD appears to present the size of the database.