Jay Tuley

Releases: Picard and libtunepimp: “We released the 0.6.0 version of Picard today — this release fixes many bugs and adds the much anticipated mp4, mpc and wma plugins! Also included in this release are support for generating cuesheets, M3U, PLS and XSPF playlists….”

(Via MusicBrainz Blog.)

So it looks like official MusicBrainz client has mp4 support now, unfortunately the change log doesn’t mention any of the OS X problems being resolved. These problems are GUI related though, and otherwise the application Picard (python) and backend libtunepimp (c++) should otherwise work for OS X as far as the last time I tested. A Cocoa gui via the PyObjc Bridge might be a good option for some one out there wanting a full MusicBrainz client. iEatBrainz is a bit beyond resurrecting code wise (It does still work, but changes by Apple or MusicBrainz will certainly break someday in the future), while parts of it could be harvested, I’d suggest to anyone thinking about it to strongly consider a cocoa gui for Picard as it has a lot more features and with MusicBrainz fingerprinting up in the air it’s a much safer approach.

iEatBrainz 1.07 is a small update but it’s got a solution to a major problem that has been plaguing iEatBrainz worse and worse with each new version of iTunes. It should be able figure out what songs you are trying to tag in most cases when the iTunes Music Library.xml file is out of date. It’s got some other minor improvements, but those are basically due to shared code between NicePlayer and iEatBrainz.

The reason this is the final version, isn’t quite the same as it was going to be. Originally i was working on directly writing aac/mp3 tags to try and get past that bug that this release has a slow work around for, and to perhaps write a newer version based on the framework I was writing to do this, or just release the framework giving other cocoa programers and easy way to write their own take on musicbrainz tagging.

However MusicBrainz has an issue of their own, their acoustic fingerprint server is reaching it’s limits. See the MusicBrainz blog General update: What’s up with TRM??. Their acoustic fingerprint server was donated by a company that’s no longer in business, and is proprietary, and about to crap out. Ironically MusicBrainz’s codebase is licensed under the GPL, which is designed to keep something like this from happening, however fingerprinting was all done on a separate server so it didn’t have to follow the GPL.

MusicBrainz’s current solution is to go completely to tag based searches, which hopefully will turn out okay. MusicBrainz meta data, while free and open, hasn’t been as rich as those provided by other taggers such as MPFreaker , but the fingerprint really set it apart. Not too long ago MusicBrainz added advanced relations which promises to give it much richer data, I hope this will be enough of a draw to keep people using it.

Since what i’ve been working on is pretty much deprecated by this, and my copious free time is not actually copious, I’m going to officially say this is the last version of iEatBrainz I’m releasing.

MusicBrainz was originally going to release their next generation tagger for Mac OS X / Windows / Linux which will use the new scheme of tagging anyway, unfortunately it was announced also that this was no longer going to be the case for Mac OS X Bad news: Picard on OS X. The good news is the problem with it seems to be the cross platform GUI widgets, and since you can use a cocoa gui from python, the potential for porting by someone wanting to take it on is good (However, I won’t be that person).

Apple Bug Friday

So I’m was reading many blogs today, and I feel so uncool with all these “Apple Bug Friday” posts. I have an apple bug (or at least I considerate it, don’t know if apple will) that I had written some unit tests to explain the behavior problems. I’ll have to prime for next friday it’s 19 minutes past saturday!

The state of the projects

Yeah so this was not the summer of code for Jay Tuley, but now that the girlfriend is finishing school in London, I’ll have some time this fall that will need occupying with code.

So basically NicePlayer is the project that has gotten the most attention from me, because Robert works on it too, and I use it on a regular basis being that it’s now september we’ve missed another self imposed milestone, whoops. I’ll have some time to work on this for sure this fall.

i’ve worked on iEatBrainz very intermittently, fixing little bugs, trying to get the applescript update to be more reliable, I’m going to release it soon, and that will probably be the last update of that code base by me, then I’ll focus on iEatMeta.

iEatMeta was going really good in the spring, and then poof I stopped working on it as life got in the way, it’s current status is that I have reading m4a, m4p, and mp3 metadata that iTunes does plus MusicBrainz data, I want to make some design changes in the api, before releasing the source, I’m not sure the best way to implement writing the m4a tags, I have some ideas, but I think reading is quite useful, and it’s better to get the framework out there, just incase for some reason life gets in the way again.

Sleep

I had some other odds and ends but I’m too sleepy, and am starting to forget what I’m writing, I’d rather just post something now than waiting and posting later. Good night!

So someone asked me a question, and I’ve had this question before, so I decided to answer it in my blog.

Tom asks:

One thing that’s been confusing me for awhile is locating the XML file for the iTunes library. The iTunes library can be in an arbitrary location, so relying on it being in ~/Music/iTunes/ is bound to fail for anyone who relocates their library.

My question is, in iEatBrainz, how do you extract the location of the iTunes library from the iTunes preferences, which are guaranteed to be in a defined location. From looking at it, iTunes seems to encode a Classic-style ‘alis’ resource into the data fork, but I can’t figure out how to turn that back into something I can manipulate from Cocoa.

It’s a pretty good question, when I originally looked into locating the iTunes Music Library.xml file (for the Music Recommendation System), I also was under the impression that the file could be in arbitrary places just like Tom. However, I soon discoved that there are only specific places that file can exist. It had only seemed like this wasn’t the case because the default location for iTunes Music Folder is the same as where your library files need to be. So if you look for the library file at ~/Music/iTunes/iTunes Music Library.xml, you’ll be okay even if the Music Folder is set to be somewhere else.

So that’s easy enough, but wait, you may now be wondering did If I really mean “places” when I wrote “specific places” and indeed there is another place your library could be located, ~/Documents/iTunes/iTunes Music Library.xml. iTunes checks in precedence for the iTunes folder, first ~/Music, if it doesn’t find it there it checks in _{/Documents. If all you have is the iTunes folder} /Documents it will use the library there and save and update it, if you have both, it will use ~/Music. If you have neither it create a folder in ~/Music. Another thing you should do to make sure that you find the iTunes Music Library.xml file, is because some people tend to movie things around with aliases, you need to resolve aliases in that path, you can do that with this code from Apple.

So that’s basically all you have to do to find the iTunes Music Library.xml file. And if for some reason you program still can’t find the xml file you can pop up an open dialog box.

There are some other notes about the xml file worth noting, it’s periodically updated, and seems to be in place for Cocoa apps like iMovie, iPhoto, and iDVD, however none of them check for the file in ~/Documents (so if you look in the the secondary location, you and iTunes are already one step in sync better than Apple’s own iApps). The tracks are also numbered inside the XML with a Track ID, and in AppleScript they are referred to as “Database ID”, these values aren’t constant, and every so often they get renumbered, it’s worth noting as this has been the bane of iEatBrainz in the past and present.

Finally, while it doesn’t concern most, in my opinion there is a major bug regarding the dates in the XML file. The XML file uses the GMT offset for the daylight savings time that you are currently observing, not the offset for when that date occurred in time.

So on this day of posting I’m currently not observing daylight savings time. So that’s 6 hours behind GMT where my thinks it’s located.

Song A was added in November (not DTS, thus 6 hours behind)
2001-11-27T01:35:27Z (-600 = 7:35:00 PM) in XML
Monday, November 26, 2001 7:35:27 PM in Applescript and GUI

Which is right, everything matches, however:

Song B with a Data added in July, thus in DTS
(5 hours behind GMT in my location)
2001-07-18T20:24:29Z (-500 = 3:24:29 PM) in XML
Wednesday, July 18, 2001 2:24:29 PM in Applescript and GUI

That’s wrong! the XML doesn’t match up with the GUI and AppleScript!

If I change my current time to a day in daylight savings time:
2001-07-18T19:24:29Z (-500 = 2:24:29 PM) in XML

iTunes rewrote the date, and now the time matches the GUI, however all the non DTS dates now don’t match!

It’s just frustrating, I filed a bug report with Apple last June, but I’m not sure if they care as iMovie, iDVD, and iPhoto, don’t care about dates.

So yeah, I guess that’s the iTunes Music Library.xml file in a nutshell.

So it feels like with each new version of iTunes, the hackish applescript retagging gets less effective. It motivated me to dig deeper in finding out about how meta information is stored in the M4A files. I found out it was pretty easy to parse (ATOMS are amazing) and I had a test app, and figured out all the atoms that I would need to know to read the equivalent of what iTunes allows you to edit. After that i decided I’d try getting mp3 id3 tags using a library. So I wanted something that i could dynamically link to (with out making my code GPL) and low level to get iTunes specific tags, thus I used id3lib, which seems work really well. I’m a little concerned that projects seem to moving from this to libid3tag, however, the only complaints I’ve read are that it’s “over engineered” which makes me feel a little better. I have a library now, iEatMeta.Framework, that reads metadata, and I’m currently working on writing metadata, and hopefully it won’t be too long before I get it how i want it, and I release it under MPL/LGPL. This framework would be the foundation for redesigning iEatBrianz.