193 words
I’ve run into some odd behaviour of iTunes regarding certain MP3 files before, and never cared enough to investigate further. It seems that certain old files with what iTunes considers to be the ‘wrong’ Creator code may be to blame. At least for Aiport Express music playing related problems that seems to be the case and a description of how to resolve the problem can be found here (via 2lmc).
However, the whole use of Python looks a bit scary to me. What about just doing a Spotlight search for all files of Type ‘MPEG’ in your home folder, selecting them all and running a little AppleScript? It’s not exactly the same (and might include the risk of finding some movie files of Type ‘MPEG’ as well) but it’s much less scary…
In principle you should be able to do all of this in AppleScript. But as it is a one-off, it’s probably not worth figuring out. Particularly as I couldn’t get the Finder’s find
command to do anything other but spawn broken Spotlight-style windows which belong to the Finder (rather than the SystemUIServer as usual) and don’t do anything.
Yes, the Python solution is scary because it works ;)
Good luck writing that as clearly in AppleScript, especially if you’re going to do it to only the files that iTunes knows about.
Bob, I thought the Python stuff was scary because it involves yet another script language, command line usage, the word database, Objective-C and so on. YMMV.
Even with AppleScript’s quirks all of this can be done in iTunes itself. Like this, say.
Yeah, but in my case, I have so many tracks that querying iTunes with AppleScript and then asking Finder about every single file in the whole database really just isn’t a very good option.
I’m sure the Python version ran several orders of magnitude faster, because it was leveraging information that iTunes already had (but doesn’t offer up in the AS dictionary).
I’m pretty sure the Python version should be much faster than the AppleScript version (which on my 400MhZ computer, while playing music etc, processes around 25 songs per second). But for a one off I couldn’t care less. The time saved by using the Python version is probably smaller than the time I’d need to find and istall the PyObj C stuff in the first place.
As I think that you managed to explain a problem that more people are seeing, it’s probably good to have a way of solving it without being overly geeky.
In total I’d say that the Python version is faster, but that’s irrelvant. While the AppleScript version gives better results (thanks to using aliases rather than paths which let it find files which you moved since you last played them in iTunes), which in most cases is equally irrelevant.
At 25 songs/sec, it would take 20 minutes to process my library. The way I did it took less than that to figure out what to do and blog about it :)