Also, what does this file do anyway? And will it balloon in size as I add more music to the iPod? What would deleting this file affect? Posted on Nov 3, AM. Page content loaded. Nov 4, PM. It's not usual, or necessary for you to be looking in the Root folder of an iPod. If you delete a file like that, don't be surprised if your iPod stops working.
One thing you will notice in the capacity bar shhown when you connect the iPod to iTunes is that some space on the iPod is used by "Other". This is data that the iPod uses for control etc. The only time you need to do anything about the "Other" is if the space it's taking up on your iPod exceeds 1GB or so. Especially when you have a GB iPod with just 27 albums on it. My advice is that you learn to use the Sync method no such thing as manual sync to manage your iPod.
Figure 15 contains the 16 unknown bytes for the four mhod blocks shown in Figure We find a 4-byte number that is always one, a varying 4-byte number and 64 bits of zero. On closer inspection, the second number seems to vary with the length of the subsequent string and is, in fact, its length in bytes.
We will add a test to our validation program to check if this is true for all mhod strings. Our validation program finds text data chunks where the first number is zero instead of one.
These follow mhod chunks where the type is , probably an empty string type. Figure 16 contains a complete description of the mhod chunks. We can use the mhod children of the mhit chunks to figure out which songs relate to which mhit chunks. This helps us figure out the rest of the mhit chunk: n5 changes based on the file type; n7 is the size of the song's file. See Figure 17 for a diagram of the mhit data chunk. Our analysis of the left side of the tree is complete, and using it we can find the information for all the songs on the iPod.
Earlier we hypothesized that the other main use of the iTunesDB file is for playlists, so we will look for playlist information in the right side of the tree.
Hoping for symmetry, we want to find one mhyp chunk for each playlist, as there was one mhit chunk for each song. Looking around, we know this iPod has three playlists yet there are four mhyp chunks. When we run our validation program on a variety of iTunesDB files, we learn there is always one more mhyp chunk than the number of playlists.
We will use our validation program to display information about the children of the mhyp chunks. It shows us that every mhyp chunk has a first child that is an empty string mhod chunk type with a mysterious extra null bytes. Then it has an mhod chunk with a string in it.
For the first mhyp chunk, this is the name of the iPod; for every other mhyp chunk it is the name of a playlist. After the name mhod chunk comes a series of mhip and mhod pairs, until the next mhyp chunk. The mhod portion of the pair is an empty string. The number of these pairs is equal to the number of songs in the playlist. Thus, we can theorize that this first playlist is a master playlist containing one entry for every song on the iPod.
We know that a playlist is a named list of songs with a title. We found the name already, but we need to figure out how the list of songs is stored.
We start by looking at the mhip chunk in Figure We saw n4 in the mhit data at n2. Thus, we can guess that n4 is a song identification number and that the mhip chunks use song identification numbers to specify which songs are in the playlist.
We can add a test to the validation program to match n4 in the mhip chunks, with n2 in the mhit chunks to confirm our theory. The remaining mhip mystery is that the n3 number is similar in magnitude to the song key, n4.
If we change our test program to look for songs whose key is the number following the key we already found, we won't find any songs with these identification numbers in any iTunesDB file.
We can deduce, then, that it is a unique identification number for these chunks. Adding a test to our validation program confirms they are indeed unique. Figure 19 contains a diagram of the mhip data chunk. The mhyp chunk see Figure 20 is the final chunk we need to evaluate.
The master playlist has n3 set to 1; all other playlists have it set to 0. Using the three reverse engineering strategies of hypothesis, pattern recognition and validation, we deciphered the iTunesDB file format. Hopefully the ideas presented here will help Linux users reverse engineer more devices and file formats to make them compatible with Linux. Figure 1. Figure 2. DeltaMac Tech. Please notice that this thread was started more than 6 years ago, and iTunes was substantially different, compared to what it is now.
I don't have access to iTunes on a Windows system, so it's possible that the file is no longer named itunesDB with newer versions of iTunes.
You should find what you are looking for in the iTunes folder. This article describes where that folder is located. Applewhyyougottabesorude Registered. Hey Everyone! So it's After searching different forums for hours this one was the most helpful but what I did was different.
A finder window should pop up with your Ipods content. What I did was make a copy of that whole folder to my desktop before importing them and then manually, by folder, import the songs. They don't look like normal song files but when you import them into Itunes, double click them, they should show up as normal songs with all info! This took a good two hours to do. The first time a lot of songs were missing. Not sure if it was from me importing songs from each folder before it had enough time to import one folder at a time or if i just missed folders by mistake.
I now have my 6, songs back though and will be backing them up this time. Best of luck! Last edited: Mar 23, Lucky Registered.
A type number. Contains an MHLP also. This MHLP is basically the same as the full playlist section, except it contains the podcasts in a slightly different way.
See the Playlists section. If this value is 1, the song is visible on the iPod. All other values cause the file to be hidden. Was previously known as unk1.
This appears to always be 0 on 1st through 4th generation hard drive-based iPods. Was previously known as unk2. This really is an integer field and is reversed in iTunesDB used in mobile phones with reversed endianess. Note that the iPod does not update this value here when you change the rating. See the Play Counts file for more information. Volume adjustment field. This is a value from to that will be applied to the track on playback. If you adjust the volume slider in iTunes track info screen, this is what you are adjusting.
The value 0 is special, the equation is not used and it is treated as "no Soundcheck" basically the same as the value This equation works perfectly well with ReplayGain derived data instead of the iTunes SoundCheck derived information. Note that the iPod does not update this value here. Previously known as unk5. This is used for AudioBook filetypes. AA and. M4B based on the file extension. Note that there is also a bookmark value in the play counts file that will be set by the iPod and can be used instead of this value.
Unique 64 bit value that identifies this song across the databases on the iPod. Previously known as unk7 and unk8.
This is the rating that the song had before it was last changed, sorta. If you sync iTunes and the iPod, and they have different new ratings, the rating from iTunes will go here and the iPod rating will take precedence and go into the normal rating field. I'm uncertain what exactly this is for, but it's always set to what the iTunes rating is before each sync.
The number of album artwork items put into the tags of this song. Even if you don't put any artwork items into the tags of the song, this value must at least be 1 for the iPod to display any artwork stored in the ithmb files. The total size of artwork in bytes attached to this song i. The sample rate of the song expressed as an IEEE 32 bit floating point number. It's uncertain why this is here. For podcasts this corresponds to the release date as displayed to the right of the podcast title.
Formerly known as unk Seems to be set to 0x02 for tracks without associated artwork even if artwork is present, it will not be shown on the iPod and 0x01 for tracks with associated artwork. Note that Protected AAC files.
To determine if a file is bookmarkable, therefore, check the file type first. If it's not an. Formerly known as flag3. When this flag is set to 0x1 then the "Now playing" page will not show the artist name, but only title and album.
Until dbversion 0x12, same data as dbid above added in dbversion 0x0c. Since 0x12, this field value differs from the dbid one.
Observed to be 0x01 for non-podcasts. With podcasts, a value of 0x02 marks this track with a bullet as 'not played' on the iPod, irrespective of the value of play count above. A value of 0x01 removes the bullet. Appears to be 0x1 for files encoded using the MP3 encoder, 0x0 otherwise. It seems that this field denotes the type of the file on e.
It must be set to 0x for audio files, and set to 0x for video files. If set to 0x00, the files show up in both, the audio menus "Songs", "Artists", etc. It appears to be set to 0x20 for music videos, and if set to 0x60 the file shows up in "TV Shows" rather than "Movies".
Previously known as unk Has something to do with protected files - set to 0x0 for non-protected files. The gapless playback does not work for MP3 files if this is set to zero. Maybe the iPod prepares the next track when rest 8 frames in the actual track. For AAC tracks, this may be zero. Setting this offset to! This value should be set to the id of the corresponding ArtworkDB mhii Offset Only the Master Library Playlist should have a 1 here.
Probably three more flags, the first of which has been observed to have been set to 1 for some playlists. Formerly known as unk4. This is set to 0 on normal playlists and to 1 for the Podcast playlist.
If set to 1, the playlist will not be shown under 'Playlists' on the iPod, but as 'Podcasts' under the Music menu.. The actual title of the Playlist does not matter.
0コメント