Media Server Odyssey Part 4: Autorip

If you have time on your hands, feel free to start at the beginning.

So now the thing plays music. I also want to be able to update the music supply painlessly. Specifically, I would like to be able to insert a CD into a drive attached to the headless Pi and have it rip the disk, with ID3 tags, and pop the disk without any further interaction.

This is where a flexible solution like a Raspberry Pi starts to come into its own – it doesn’t just play music, like the Streamium or Sonos, it’s also possible to extend it to do anything a Linux box can do. There are packaged devices that play and rip, but they are pretty expensive.

I guess here I’m demonstrating that I’m an ancient crusty person who still buys CDs. I could just buy the MP3s instead and copy them straight to the disk. Meh.

The hardware for CD ripping was easy to come by. I bought a cheap DVD drive on eBay. It’s also USB powered, so my Raspberry Pi media centre (aka giant pile of wires and USB devices) is still driven from a single power socket:

IMAG0524

For the software, a tiny amount of googling will identify the best hands-off Linux ripping tool – abcde, which stands for A Better CD Encoder. There are many things I like about this tool:

  1. Command line driven
  2. Configurable, but also designed for use-cases like mine. Some highly configurable tools are very hard to get to do the simple things you want…
  3. Capable of ripping completely non-interactively (the -N switch)
  4. Based on standard tools like lame and cdparanoia
  5. Written in pure bash! In a single 4,500 line script! It’s some of the most transparent Linux software I’ve ever used because I love bash and wallow around in it all day at work. If I want to know how abcde does things, it’s extremely easy to open up the one source file that does the work and browse through it to find the answer.

I found a standard config file for MP3 ripping, which required minimal customisation.

I wanted to use the SD card as the wav file temp space since I thought it might be faster but there wasn’t enough space; possibly there is too much clutter in my install by now. In any case, I’m not actually that interested in how quickly (within reason) it can rip the CDs – I just want it to be easy. Since my media centre sits in my living room, I should be able to gently feed in CDs at my leisure.

The tougher part was getting abcde to launch on CD insert. As always with Linux, there are several hardware event toolkits which succeed each other and all look completely different. The latest in the chronology is udev, but I found that if I ran “udevadm monitor” and plugged in a CD I got no events 😦 Maybe I just didn’t understand the man page – it certainly wouldn’t be the first time.

So I tried halevt. This time, running the monitor command:


lshal -m

and then inserting an audio CD gave this:


Start monitoring devicelist:
-------------------------------------------------
21:19:30.866: storage_serial_HL_DT_ST_DVDRAM_GSA_T20L________________________________0_0 property storage.removable.media_available = true
21:19:30.991: storage_serial_HL_DT_ST_DVDRAM_GSA_T20L________________________________0_0 property storage.cdrom.write_speeds = {'4234', '2822', '1764', '706'}
21:19:31.361: volume_part_1_size_472217600 added

I also got useful information about the relevant device by examining the output from lshal, which dumps information about all your devices. There was still a bit of argy-bargy to get the halevt listener/handler configured properly. The first thing I had to do was remove all the default entries, which are all to do with automatically mounting USB drives, something that interfered with my existing mechanism for doing this.

The configuration documentation had some good information, but as usual examples are most useful and I just adapted what was in the default config file. One thing that confused me was that there looks like there is a halevt directory for scripts to be launched from halevt events (/usr/lib/hal/scripts/), but if you put “env > somefile.txt” (note you’ll need to use XML encoding for file redirection operators! It’s hard to put these in my main code examples because WordPress sucks) as your event script, you find that the $PATH is actually just /sbin:/usr/sbin:/bin:/usr/bin. That’s fine – abcde and all its tools are installed there anyway. This was my final config:


<?xml version="1.0" encoding="UTF-8"?>
<halevt:Configuration version="0.1" xmlns:halevt="http://www.environnement.ens.fr/perso/dumas/halevt.html">
<halevt:Device match="hal.storage.cdrom.cdr = true">
<halevt:Property name="hal.storage.removable.media_available">
<halevt:Action value="true" exec="echo $USER > /home/pi/log/abcde.log ; sleep 10 ; abcde -N >> /home/pi/log/abcde.log 2>&1"/>
</halevt:Property>
</halevt:Device>
</halevt:Configuration>

This has two crucial components – selecting the appropriate event (a combination of the Device match attributes and the Property name attributes) and the commands:


exec="echo $USER > /home/pi/log/abcde.log ; sleep 10 ; abcde -N >> /home/pi/log/abcde.log 2>&1"

This keeps track of what’s happening in /home/pi/log/abcde.log for debugging purposes. I think the $USER is actually root for halevt runs – I probably don’t need this part anymore. Note the sleep 10 – I found that it took some time after the event for the CD to settle and be available for abcde.

It works beautifully – put in a CD and the Pi rips it to the target directory and pops the disk. You just need to wait a little while for the encoding to finish and then update the mpd database from one of the clients – you can do this with mpdroid.

One potential problem was that the disk pops after it has finished ripping the wav files, not the whole process. This means you can rotate the disk straight away and the poor old Pi will have to rip this one while still encoding the last. However, I found it coped perfectly well with this; the Pi can rip one track, encode two others and play MP3s through mpd at the same time. The system load goes up to 5-7, but the Pi soldiers on with no obvious problems. Impressive.

Advertisements

One Response to “Media Server Odyssey Part 4: Autorip”

  1. Janne Says:

    Awesome. This goes to my headless NAS box right away 🙂

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: