build_m3u

I was reading this article on m3u files and decided to scratch one of my long-term itches, building a decent windows playlist on the file server. It’s a.. large collection, so I don’t want to build things on the client end, you see, it takes bloody ages.

Up till now, I’ve just created a list of paths, and used that as the playlist. This had 3 disadvantages:

  • it’s very hard to have it sorted by anything useful, using the filename is hopeless as there are several different naming conventions involved. blech’s fault.
  • I’d quite like to have the track lengths already by the tracks when winamp starts, as opposed to have it add them whenever you see them.
  • for some reason, winamp starts much faster when there are EXTINF tags in the playlist file. Don’t know why. Don’t care.

So now I search the server for files, read the id3 tags, sort by artist/album/tracknum/title and print out, along with the track length and name in an EXTINF tag. The whole process takes almost exactly 2 mins, but it’s not very memory-efficient. For various complicated reasons the server has almost a gig of memory in it (ok, they’re not complicated reasons – we just don’t own any other boxes that can use the stuff) so I don’t care about this.

code is here, if you care. It’s hard-coded for my server, but the only thing you’d really need to change is at the beginning, where $root and $remote are defined – $root needs to be where the music lives on the server, $remote is where it lives on the network. For my server, I samba share /music on the server cowboy as cowboymusic. Also, $playlist should be where you want the playlist to go.

string.pl

blech has been on at me recently to finish my half of our evil ‘Wire and string’ project – it’s a cunning, cunning plan which we really should put more effort into. Anyway, here’s a heap of self-congratulation that I’m done, and he should get off his butt and implement the other half.

Essentially, the problem is as follows: We have a computer in the lounge that can play music, hooked into the network and the stereo system. But there’s a complete lack of decent software to control the thing. We searched and searched, and all the interfaces we could find sucked.

Now, the best music control interface we know of is iTunes. We want iTunes to control what is being played on the lounge machine. But it’s not a mac. Hence the goal – have iTunes on a mac locally, pick up what song is selected/playing, and send that to the lounge computer, which will then play it through the amp. blech took the iTunes half (the Wire), I got the server half (the string).

Now, there are no non-awful MP3 playing interfaces for perl. None. Almost everything that I could get to compile at all (and didn’t need non-free libraries you can’t download any more) wrapped either mpg123 (now that’s a pretty web page) or xmms. The mpg123 wrappers seemed to be the best bet, and for the most part they work, but there are… issues. I didn’t get proper events for songs ending or stopping, it was quite easy to wedge the thing to the point where you couldn’t control it any more, etc, etc. | believe these are limitations of the command line mpg123 interface, and I can work round them, but I don’t want to have to patch the source code just to get a working system, and it makes distributing things a complete pain. I also need the server to be absolutely robust, it’s no good having to SSH in every 5 mins to fix the server – the whole point is to avoid having to think about it.

Wrapping xmms isn’t much of an improvement. It’s got a much nicer interface to control it, but, of course, it’s controlling xmms, which is a seperate app that needs to be running, and it needs to be running on a machine with an X server. Hard, given this is a headless server.

But, in the end, that’s what I used. I was saved by Xvfb – I can run an X server on the machine without having to worry about graphics cards, and launching xmms from the cgi is possible, so it will run as the right user and everything. After a lot of messing with annoying permissions, I have a CGI that will make noise.

The other problem is that the Mac only knows where the music is on the machine locally. Rather than having the iTunes end convert the local path into something the server knows about, I take anything that might possibly be a path to some music, and trim things off the left of it till the right hand side matches something in the ‘locate’ database. Disadvantages – you need an up-to-date locate database. Advantages – you can pass just about anything that is music, and the server will have a shot at playing it. In practice it works really quite well.

So, yeah, code . w00t.

AudioFile::Identify::MusicBrainz

After much muttering back and forth between blech and I, I have written and released AudioFile::Identify::MusicBrainz. The old MusicBrainz client relied on the C library they distribute, which was silly for something that sent and recieved pure RDF, so a pure-perl implementation was just begging to be written.

So, upsides, it works, there’s exactly one sort of query you can send it, but that’s fine, it’s the important one – you can say ‘I know this about a track, tell me more’. The next step is to give the user a nice choice, and then let them write the updated information back into the ID3 tag.

Downsides, I’m not using ‘real’ RDF parsers, I’m using XML::DOM. This worries me, frankly, I’d much rather do the right thing, but I get a headache trying to make the perl RDF stuff work. There’s an RDF::Simple out there now, though, so maybe I’ll try that…

I’m going to get a reputation here for stupidly long module names, you know.