iTunes Album Artwork Directory Structure

NeonDev · 03-11-2008, 09:06 AM

so far this is the best information I have regarding the album artwork downloaded through the iTunes Download Album Artwork feature

The problem is that the directory structure described is only true for the LOCAL subfolder (ie the one with the cache files for the songs with EMBEDDED art that NBB already supports)

does anybody here know how to decipher the structure of the folder containing the downloaded artwork? its almost as if apple has encrypted something just to annoy me.

here is what i can tell you (you will likely want to read the content in the above link):

the track persistent id 9B04AB519C0A563C somehow corresponds to the file located at "Album Artwork/Download/'Library Persistent ID'/10/03/12/'Library Persistent ID'-AE8C30086A012C3A.itc"

I only know that because i opened up that file (because it is the first one) extracted the image information with a hex editor and found the only song corresponding to that album art and got its ID. In the local directory the 2nd part of the hex string that makes up the itc file name is the track persistent id as you can prolly see 9B04AB519C0A563C /= AE8C30086A012C3A

Why is it that the local folder has one structure and the download folder has a different one?

NeonDev · 03-11-2008, 11:13 AM

a couple of farther observations:

the .itc files are stored in the same order as in the itunes XML (as far as I can tell) ie the first file in the XML with downloaded album art corresponds to the itc file in the first folder of the downloaded art folder. I have checked this for 5 downloaded album arts and it is consistent.

Also for me the folders start at 10 and go to 15 but each subfolder of those is 03 and each 03 subfolder is 12

that still leaves me nowhere as far as NBB getting the downloaded art because I don't know how the hell itunes is deciding where to file the itc files.

Bugbyte · 03-11-2008, 12:46 PM

My file structure in the Downloads folder has a hex ID (4CD651A28ED49D8) that precedes the persistent Track ID. In fact, all of the artwork is contained in a folder with that ID. (Download-->4CD651A28ED49D8). That's followed by the folders named 00 or 01 or 02 and so forth. Ultimately, it breaks down to an .itc file with the first Library persistent ID and what must be the track persistent ID.

If the last part of the file name = the persistent ID, would it work to just search the iTunes Album Artwork folder for any file that has that Track persistent ID in the last part of the filename? Because it's such a long string, it is almost guaranteed to match.

NeonDev · 03-11-2008, 01:14 PM

that naming convention is only true for the local folder. the download folder SEEMS to follow except that it is not using the track persistent id (you can verify against that by looking at the itunes xml file)

my only guess is that either the second hex string in the name is the ALBUM persistent id if there is such a thing (there is none in the XML file) or apple is purposely encrypting the track id in the download folder to make it hard/impossible for 3rd parties to access it.

the thing that really ****es me off is that even finder know exactly how to find which itc goes to which song. once you delete the itc finder displays the generic icon so it must be reading that very file.

Why must apple make it so hard? F*** DRM and F*** cover flow

Does anybody know how apple generates these "Persistent IDs"?
Has nobody else figured out how to use this album art?

also why does apple even need to segregate the downloaded art versus the itc that was cashed using the embedded art?

Its looking less and less likely that anybody is ever going to figure out the filing system behind the downloaded itc files and therefore less and less likely that NBB will ever support non embedded artwork. Luckily there are a number of apple scripts that will go through your library and embed the artwork for you. a pain in the a$$ i know but I don't know what else to tell people

iamgnat · 03-12-2008, 09:13 AM

Quote: Originally Posted by NeonDev

the thing that really ****es me off is that even finder know exactly how to find which itc goes to which song. once you delete the itc finder displays the generic icon so it must be reading that very file.

Am I remembering correctly that you are not using QT in NBB? I have to believe that Finder would be accessing the info via QT (the same way iTunes would) which would explain why it can see it.

Have you checked the meta data for the file (mp3 tags, extended attributes, ...) to see if there is a custom key they are using to point it to the correct itc file?

-dave

NeonDev · 03-12-2008, 09:19 AM

I am using QT, and I have searched the contents of various mp3 and aac files for the 2nd hex string and came up short each time (i searched as both hex and ascii)

I will go through the quicktime framework documentation to see if there is something related to artwork in there...

Has no other dev here attempted this before? or are they safe guarding the secret?

iamgnat · 03-12-2008, 11:32 AM

Quote: Originally Posted by NeonDev

I am using QT, and I have searched the contents of various mp3 and aac files for the 2nd hex string and came up short each time (i searched as both hex and ascii)

Sorry, was remembering wrong then.

Any chance the itc hex string is the MD5 hash of the file it belongs to or something like that?

Have you tried doing a hex dump of the audio file and searching for the hex string (e.g. maybe it's just in a specific location but not attached to a tag)?

Quote:

Has no other dev here attempted this before? or are they safe guarding the secret?

The last time I messed around with album artwork directly (e.g. CFE just pulls it from iTunes via AS) was before they implemented iTunes Plus and the free album art.

-dave

NeonDev · 03-18-2008, 10:03 AM

there is no chance that the second hex string is the hash of the file itself since, if you look at it, they are sequential. by that i mean the file in the folder structure 10->03->12 has the value 8C806EA192F99CA1-AE8C30086A012C3A.itc and the file in folder structure 11->03->12 has the value 8C806EA192F99CA1-AE8C30086A012C3B.itc even they are completely different songs. as I said before they go in order (the first track with downloaded art in the xml matches the itc in the first folder) when you look inside the xml file (as far as i can tell).

Quote:

Have you tried doing a hex dump of the audio file and searching for the hex string (e.g. maybe it's just in a specific location but not attached to a tag)?

yes i opened several files with a hex editor and searched the file for both the hex and ascii representation of the string (even narrowed my search to the last 3 chars)

if i only knew how apple is generating that second hex string. (which by the way is different in different libraries for the same EXACT song)
obviously i am staunchly opposed to running itunes simply to grab album artwork, I would very much like to decipher their artwork database since grabbing the artwork from that would be even faster than getting the embedded art since NBB would no longer have to open the file and parse the tags.

for anybody interested i found this apple script that will embed the downloaded album art

tell application "iTunes"
repeat with aTrack in selection
repeat with anArtwork in artworks of aTrack
if downloaded of anArtwork is true then
set theData to data of anArtwork
set data of anArtwork to theData
end if
end repeat
end repeat
end tell

link to script

iamgnat · 03-18-2008, 10:57 AM

Quote: Originally Posted by NeonDev

obviously i am staunchly opposed to running itunes simply to grab album artwork
...
for anybody interested i found this apple script that will embed the downloaded album art

If you aren't using iTunes for something else (e.g. playing the music), I would agree. As an alternative, you could offer the user the option to import the images directly to the files or into a format/location that NBB is happy with (e.g. run iTunes once, do the grunt work, then don't have to run it again unless they need to update the images).

That can be slow though (AMP does this and is painful when updating your library).

-dave

NeonDev · 03-18-2008, 12:29 PM

Quote:

That can be slow though (AMP does this and is painful when updating your library).

that is why i am trying painfully hard to avoid any importing... I've got to say its really frustrating to have everything I need right in front of me but having no idea how to access it in a reasonable manner

NeonDev · 03-18-2008, 01:16 PM

so after more experimenting I am quite certain that it is the ALBUM persistent id that I require. unfortunately that info is not stored anyplace i know of and I have no idea how apple generates their persistent ids so it looks like I am up **** creek on this one.

It seems the best i can hope for is to see if apple script can go through an itunes library and dump the album ids into a file that i can the use to look up from within nbb... the user would have to run it everytime they added new art but it would be a lot faster than exporting the artwork

anyone out there good with applescript and itunes?

NeonDev · 03-18-2008, 01:37 PM

well I just had an interesting thought to try and use the apple quick look framework to snag the thumbnail... anyone here used the quicklook framework?

iamgnat · 03-18-2008, 01:43 PM

Quote: Originally Posted by NeonDev

so after more experimenting I am quite certain that it is the ALBUM persistent id that I require. unfortunately that info is not stored anyplace i know of and I have no idea how apple generates their persistent ids so it looks like I am up **** creek on this one.

Is part/all of it possibly the CDDB/FreeDB code? I know in the early days of iTunes/iPod, Apple was using CDDB. I don't know what they did after Gracenote ****ed everyone off though.

Quote:

anyone out there good with applescript and itunes?

From a quick test (can't spend time on it at work), it does not look like the album's PID is available via AS. The only reference I can find is the string value of the name from a track item (e.g. "get album of current track") which does not seem to translate to anything useful for these purposes.

-dave

NeonDev · 03-18-2008, 02:35 PM

well im pleased to announce that using the quicklook framework has proved fruitful!

I will likely use that to render all album art from now on (depending on how fast it is)

anybody suffering the same problems with album art should use it. it is less than 25 lines of code to fetch the preview and is guaranteed to work with anything quick look understands. im sure it is quite a bit more efficient than opening up the entire file (twice really since the qtkit was opening it anyway) to parse for the album art tag.

i would be happy to help anyone in need of assistance as well

thank you all for trying to help me figure it out tho.