for Philips™ HDD 100/120 Audio Jukebox

How to use the Philips™ Audio Jukebox without the DMM software.


RELEASE 0.9.8 : playlists creation, "recordings" management, ...



Download HDDTool

Main features

How to use it

Revision history

Technical details



Due to many demands of developers and other people for details about HDD100/120 database and the "naming rules" of files on HDD i have decided to publish this page with all information i discover while working on HDDTool.


Thanks to Mr Spoon for some extra (hidden tracks, file source, ...).


These details are here to help you to manage HDD 100/120 database with your own software. I would appreciate if you let me know about your work and ideas



1) General information about HDD file structure


On the HDD we find the following directory structure :



   |___ System

             |___ _DATA_

             |___ DATA

             |___ FONTS

             |___ GRAPHICS

             |___ MUSIC

             |___ PLAYLIST

             |___ RECORDINGS

             |___ VOICE


In the System directory you find the firmware file Philips.MI4 (and perhaps a file EQLNK.BIN - for equalizer purposes, not yet investigated).


All the System tree has "hidden" attribute.


When using DMM to transfer music files, these are copied in System\MUSIC directory ; the names of the audio files must be compliant with "HDD naming rules".


The HDD database is created by DMM in System\DATA directory ; when the HDD starts it copies the DATA directory to _DATA_ one (i suppose for backup purpose).


The PLAYLIST directory contains all the playlists files in a HDD specific format.


I ignore the use of FONTS and GRAPHICS directories : they are empty on my HDD


About RECORDINGS (and perhaps VOICES) directory i suppose it is used when recording audio directly from HDD ; not yet investigated



2) HDD database


And now the heart of HDD : the database


The database format looks to be a "Philips" one so i found no mean to use any standard database connector to access it and work in an easier way with these files ...



The System\DATA directory contains all the database files : header (.HDR), data file (.DAT) and index files (.IDX).


So in this directory we find :














DB5000.HDR is the header file of DB5000 database ; it contains the database structure : names of data file and index files, size of records, number of records in database, ...


DB5000.DAT is the data file of DB5000 database ; it holds one record by audio file on HDD with details about it : path, name, bitrate, samplerate, duration, tags, filesize, ...


DB5000_....IDX files are index files of DB5000 database ; the content of these files determines the play order of files on HDD.



If no other precision, notice that for all database files, the following conventions apply :


* numeric values are stored in double word format using Intel platform convention

* string values are stored using two-bytes coded chars ("wide string")




        2.1) DB5000.HDR details


The DB5000.HDR is a 13 044 bytes length file holding the database structure.



Positions (decimal byte offset) of useful values in DB5000.HDR are :


Position Data Default value
1036 DB5000.DAT record size 408
1040 DB5000.DAT records count  
1604 DB5000.DAT pathname length 28
2148 DB5000.DAT filename length 16

When updating HDD database you must adjust the record count in DB5000.HDR according the number of lines in DB5000.DAT.

Beginning at byte offset 12964 you will find the DB5000.DAT record description ; the value gives the offset in bytes of data in the DB5000.DAT records :

Position Column Value
12964 Reserved (value 0) ? 8
12968 File Path 12
12972 File Name 68
12976 Bitrate (in bits per second) 100
12980 Samplerate (in bits per second) 104
12984 Duration (in seconds) 108
12988 Artist 112
12992 Album 192
12996 Genre 272
13000 Title 312
13004 Track number 392
13008 Year 396
13012 File size (in bytes) 400
13016 File source (value 0) 404


Notice that offset 0 of DB5000.DAT record is not described in the above array ; the beginning of the record is made of 2 double word (for hidden tracks ... see DB5000.DAT details).


Considering that file source is a double word size, we find again the 408 bytes for DB5000.DAT record length.



        2.2) DB5000.DAT details


The DB5000.DAT file contains one record (according to the above description) for each audio (WMA or MP3) file existing on HDD.


As seen in DB5000.HDR details, each record has a 408 bytes length ; all the string values (file path, file name, artist, album, genre, title) are made of two-bytes chars ; this is why file path is limited to 28 chars and file name to 16 chars even if offset in DB5000.DAT record shows 56 and 32 bytes lengths.


So the DB5000.DAT record can be described like that :


Position Length and type Data
0 1 double word hidden track (1 if hidden, 0 if not)
4 1 double word reserved (always 0) ?
8 1 double word reserved (always 0) ?
12 28 wide chars file path
68 16 wide chars audio file name
100 1 double word audio file bit rate (in bits per sec)
104 1 double word audio file sample rate (in bits per sec)
108 1 double word audio file duration (in sec)
112 40 wide chars artist
192 40 wide chars album
272 20 wide chars genre
312 40 wide chars title
392 1 double word track number
396 1 double word year
400 1 double word audio file size (in bytes)
404 1 double word file source (0: audio file, 1: optical in, 2: analog in, 3: mic in)

in the above array wide char is used for a two-bytes coded char


It seems that even if tags are empty in audio file, HDD firmware needs to find a value in DB5000.DAT file : you can put whatever you want but not an empty string (by example : no artist, unknown album, other genre, no title, ...).


There is no particular restrictions for using any char in strings ; extended ASCII (above 127) are well recognized by HDD firmware.


Notice there is no CR or CR+LF between records.


The order of records in DB5000.DAT does not matter ; the playing order is made with the IDX files.


So everything would be OK if we could use long file names and long file paths in DB5000.DAT file .... but we can't : database structure limits path to 28 and name to 16 !

This is a bit short to preserve usual long names we prefer ...

So it is the only reason to rename files on HDD and that is not related to any DRM protection !! ( even if DRM protected WMA files can't be directly played by HDD ).


DB5000.DAT stores audio files (MP3 or WMA) but NOT the playlists files.



        2.3) DB5000.IDX details


All IDX files are 12 bytes record length files.



The structure of records in the IDX files is always :


Position Length Use
0 1 double word hidden track (1 if hidden, 0 if not)
4 1 double word song ID (position in DB5000.DAT)
8 1 double word index data


The song ID is the "record position" of the title in the DB5000.DAT assuming that the first file holds the ID 0.


Index data is a double word value conversion on the original index data.

Hum .... perhaps an example would be easier to understand :


for this example we use DB5000_FNAM.IDX index file : this is the index file of file names values.

This file must be sorted by file name ascending order (believe me for now, we will see this later ...)

Assume we have two audio files on HDD and so in DB5000.DAT file :

        myfavorite_audio_testfile.mp3   (first in DB5000.DAT)


        another_audiofile_for_test.mp3  (second in DB5000.DAT)


DB5000_FNAM.IDX file must contains 2 lines (one for each file) sorted by audio file name, but the size for index data is only one double word (4 bytes) !!

So we need to find a function to convert the audio files names to a 4 bytes length value with the caution that this function returns always the same value for the same input file name ...

Hum ... it looks like a cryptographic function or some thing like that :-)

The easiest i found was a CRC32 calculation of the file name !!

So now we just need to calculate CRC32 value for each file name and put the result as index data in the DB5000_FNAM.IDX file :-)

Finally easy, no ?


The corresponding DB5000_FNAM.IDX file must contains the following lines (byte level) :

00 00 00 00 01 00 00 00 0C 43 FF DE         <-----  for the another_audiofile_for_test.mp3

00 00 00 00 00 00 00 00 32 A1 F3 98         <-----  for the myfavorite_audio_testfile.mp3


Notice that record order in IDX file is based on original data value (here file name) and not the double word conversion value.


I hope above explanations about the conversion between the original data and a double word value are almost clear


When understanding this you have all the needed keys to write the index files


Just have a look on the following array presenting the use of each index file and the order of records in them :


IDX File Use DB5000.DAT original data column Sorting order
DB5000_@DEV.IDX Unknown ? 0 value hidden track asc, song ID descending
DB5000_FNAM.IDX audio files names file name hidden track asc, file name asc, song ID desc
DB5000_FPTH.IDX audio files paths file path hidden track asc, file path asc, song ID desc


album of audio files album hidden track asc, album asc, song ID desc


genre of audio files genre hidden track asc, genre asc, song ID desc


title of audio files title hidden track asc, title asc, song ID desc


artist of audio files artist hidden track asc, artist asc, song ID desc


track numbers of files track number hidden track asc, track number asc, song ID desc


source of audio files file source hidden track asc, file source asc, song ID desc

asc for ascending order, desc for descending order


Notice that sorting order as a direct influence on the playing order on HDD.



With the above information you should now be OK to update the HDD database with the audio files you put on HDD.



3) HDD files naming rules


So now you have a complete look on the structure of HDD database and you have seen that the "only" limitation you have is that file names are limited to 16 chars and file paths to 28 ...


As it is not enough we can use a trick to bypass this as does the DMM software !


If you remember about the CRC32 calculation used for index data values, here we are using the same process : convert file name and file path to a double-word value ; this will provides us a unqiue eight digit name for any name of file or directory and so the 16 chars length for file name is OK and the 28 chars length for file path allows us to have up to 2 sub-directories in paths.


Understanding the above paragraph is all you should need to manage files on HDD


To not be limited by the already existing length of "System\MUSIC" path, the best is to work directly at the root of HDD.


To provide a "reverse" function for restoring original names of files, HDDTool stores in a file on HDD each couple of original file name/CRC32 name ; this is done because CRC32 reverse computation is not a direct operation and would be too much "time-consuming".



4) Playlists


The last dark part of HDD is one of the easiest to manage : the playlists files !!


HDD uses a specific playlist format with ".PLP" files (these files can have long names ).


So to process the M3U or WPL (or any other format) playlist files you need to convert them to PLP format and put them in the System\PLAYLIST directory.


The PLP format is quite simple :


each playlist file has a constant header :







And each track in playlist file in prefixed with :




Notice the invisible "space" after the comma



Each line end with a CR+LF



As for all the HDD database the strings (even the CR or LF chars) are made with two-bytes coded chars (wide chars).


That's all for playlists files



5) Known limitations of firmware


Hum ... there is a lot to say about firmware's limitations on HDD but the most annoying thing is the limited length of the file names and file paths.


I tried to modify database structure to make it accept long file names and file paths but it seems that HDD firmware can't read them and freezes

(maximum acceptable values may be 34 for file path and 18 for file name ... very little progress ...)


I also tried to use "DOS short names" in DB5000.DAT file and preserving original long names on HDD but firmware can't find corresponding files ...


So a solution would be to directly work on a modified firmware file but i have no skill about this and i have no information about the hardware in HDD.

This great job could also allow new audio formats (ogg, ...) to be playable on HDD





You now have almost details i have collected about HDD structure while working on HDDTool.


Go to work and make a great HDDTool to be shared with everybody !!



Thanks for reading this heavy page


If you need some more details you can email me : if i have them i would give you.

And if you find new information about HDD let me know




To contact me : mailto:solonweb@free.fr