iTunes – Library Pointing to Wrong Files

itunes

Somewhere along the way, a significant portion of the songs in my iTunes library seem to be pointing to completely incorrect files (1640 of 9160, to be exact). I know there are tools and means for fixing files that are simply in a new/different folder and still have the same filename, but is there an easy/automated way to fix thousands of songs that are pointing to completely unrelated files?

Example from iTunes Library.xml:

    <dict>
        <key>Track ID</key><integer>13712</integer>
        <key>Name</key><string>Lover's Spit</string>
        <key>Artist</key><string>Broken Social Scene</string>
        <key>Album Artist</key><string>Broken Social Scene</string>
        <key>Album</key><string>You Forgot It In People</string>
        <key>Genre</key><string>Indie</string>
        <key>Kind</key><string>MPEG audio file</string>
        <key>Size</key><integer>11613871</integer>
        <key>Total Time</key><integer>382302</integer>
        <key>Disc Number</key><integer>1</integer>
        <key>Disc Count</key><integer>1</integer>
        <key>Track Number</key><integer>11</integer>
        <key>Year</key><integer>2002</integer>
        <key>Date Modified</key><date>2012-07-25T18:48:35Z</date>
        <key>Date Added</key><date>2010-10-20T18:39:51Z</date>
        <key>Bit Rate</key><integer>241</integer>
        <key>Sample Rate</key><integer>44100</integer>
        <key>Comments</key><string>Source: eMusic</string>
        <key>Play Count</key><integer>7</integer>
        <key>Play Date</key><integer>3427320429</integer>
        <key>Play Date UTC</key><date>2012-08-09T08:27:09Z</date>
        <key>Album Rating</key><integer>60</integer>
        <key>Album Rating Computed</key><true/>
        <key>Artwork Count</key><integer>1</integer>
        <key>Persistent ID</key><string>B664192E9854A1F1</string>
        <key>Track Type</key><string>File</string>
        <key>Location</key><string>file://localhost/Applications/_Productivity/Pages.app/Contents/Resources/Templates/Modern%20Photographer%20Invoice.template/Contents/Resources/zh_TW.lproj/</string>
        <key>File Folder Count</key><integer>10</integer>
        <key>Library Folder Count</key><integer>3</integer>
    </dict>

Notice the Location node, in particular. It's pointing to a Pages template file rather than its MP3 file: file:///Users/administrator/Music/Broken%20Social%20Scene/You%20Forgot%20It%20In%20People/11%20Lover's%20Spit.mp3.

Not even close to what it should be!

I've already tried the following things, to no avail:

  • Re-add Music folder to library — Unfortunately, this leaves me with duplicated entries. The broken item still remains, with play counts, ratings, etc. and the new item is started over from scratch. Not really ideal.
  • TuneUp and Rinse — I tried running it through the trials of TuneUp and Rinse, which didn't seem to catch on to the problem I was having.

My last resort idea is to setup a script that parses the XML and checks for non MP3 Location strings. When one is found, attempt to re-construct the filename based on iTunes's automatic filenaming convention (e.g. Lover's Spit above becomes 11%20-%20Lover's%20Spit.mp3. This likely would get me 90-95% there. The remaining items could be manually fixed.

Of course, that would involve a lot of scripting time and trial and error. I'm hoping there's a simpler solution to my problem.

Ideas?

Best Answer

I would suggest a combination of your first and last ideas. You could re-add your Music folder to your library, and then use a script to change the location of the old entries (correct metadata) to the new entries (correct locations).

Pseudocode rough draft:

for every song in the XML file (seek)
  search the rest of the XML file for other songs of the same name
  if only one is found (found)
    log seek's name to file1
    if found is newer than seek
      copy found's Location value to seek
      remove found
    else
      copy seek's Location value to found
      remove seek
  else if more than one is found
    log seek's name to file2 (for manual editing)
  else (no others are found)
    log seek's name to file3

This script design would assuredly be quite inefficient, but it would fix most problems itself, and you would (er, should) only have to review the songs with more than 2 duplicate versions.

See this answer for details on how to make these XML changes take effect on your library.