ITunesDB/Basic Information
From wikiPodLinux
Basic information
The database directory on the iPod is /iPod_Control/iTunes/. This is a hidden folder (attrib +h), but is not otherwise protected.
| filename | description |
|---|---|
| iTunesDB | This is the primary database for the iPod. It contains all information about the songs that the iPod is capable of playing, as well as the playlists. It's never written to by the Apple iPod firmware. During an autosync, iTunes completely overwrites this file. |
| Play Counts | This is the return information file for the iPod. It contains all information that is available to change via the iPod, with regards to the song. When you autosync, iTunes reads this file and updates the iTunes database accordingly. After it does this, it erases this file, so as to prevent it from duplicating data by mistake. The iPod will create this file on playback if it is not there. |
| OTGPlaylist / OTGPlaylist_# | These are the playlist files created by the iPod when you create a new playlist. 4th Gen and up iPod's can create multiple OTGPlaylists. These have the same format as the 3rd gen models, they just get numbers appended to the name. iTunes will turn these into normal playlists and then delete these files during an autosync. The OTGPlaylists cannot survive changing the contents of the iPod. |
| iTunesEQPresets | This is where the equalizer presets that you create in iTunes get stored on the iPod. The format of this file is easy and well understood, but strangely, no iPod actually uses this file yet. You can create an EQ preset in iTunes, sync with an iPod, and the EQ will be put in here by iTunes correctly. But the iPod never reads the file, does not use the preset in this file, and just doesn't work correctly in this respect. Perhaps it will be fixed in a future firmware release. |
| ArtworkDB | This is where data about artwork is stored on the iPod Photo devices. The artwork itself is stored in the \iPod_Control\Artwork folder. On 5g iPods the ArtworkDB is stored in the Artwork folder along with the data. |
| iTunesSD | This is the database that seems to hold information used by the iPod Shuffle device. |
| iTunesStats | The equivalent of the "Play Counts" file for the Shuffle. |
| iTunesShuffle | Contains a list of the tracks on the Shuffle in a random order. Possibly used to specify the order in which the songs are shuffled. |
| iTunesPState | Contains the current playback position and volume of the iPod shuffle. |
| iTunesControl | Nothing more specific is known, yet. |
| iTunesPrefs | Nothing more specific is known, yet. |
| winPrefs | Nothing more specific is known, yet. |
| iEKInfo | This contains the decryption key for protected M4P playback. Previously iSCInfo(?) |
| WABContactsGroup | Nothing more specific is known, yet. |
| iTunesLock | Created whenever iTunes needs exclusive control of the iPod, like when reading or writing the iTunesDB file. |
| PhotoFolderPrefs | Stores Photo Folder preferences. |
| PhotoFolderAlbums | Stores Photo Albums. |
| iTunesPlaylists | Nothing more specific is known, yet. |
| iTunesPodcasts | Nothing more specific is known, yet. |
| iTunesVideoPlaylists | Nothing more specific is known, yet. |
Endian Note
With some exceptions, most of the data descriptions in this document are actually stored in the file in little endian byte order. Meaning that you have these representations of the data when looking at the file in a hex editor:
"01 00 00 00" = decimal 1 "10 00 00 00" = decimal 16 "00 01 00 00" = decimal 256
This means when you read the file, you need to reverse the bytes in memory to make sense of them. Keep this in mind when reading this document and trying to make sense of an iTunesDB using a hex editor.
The exceptions are noted where appropriate (hopefully). But if you are looking at a piece of a file and can't understand the value it holds, try reversing the byte order.
Note that this means the values themselves are in reversed byte order. The order of the fields described is the same as in this document. So if you see that field A is before field B in one of these tables, then when you look at the file with a hex editor, field A really will come before field B. This has confused some people who always reverse 4 byte chunks of data. If you're writing code to read/write these files, I recommend against *always* reversing the data in 4 byte blocks. This only makes the code more confusing in the long run.
