HDDTool 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, ...

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 :

Root

   |___ 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

DB5000.DAT

DB5000_@DEV.IDX

DB5000_FNAM.IDX

DB5000_FPTH.IDX

DB5000_TALB.IDX

DB5000_TCON.IDX

DB5000_TIT2.IDX

DB5000_TPE1.IDX

DB5000_TRCK.IDX

DB5000_XSRC.IDX

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 :

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 :

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 :

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 :

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)

        and

        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 :

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 :

PLP PLAYLIST+CR+LF

VERSION 1.20+CR+LF

CR+LF

And each track in playlist file in prefixed with :

HDD,

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