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.

iPod Database Files
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.

Personal tools

  • Google Search (