nixfiles : ripperbot : rathole

Anatomy of a rathole

It should have been a simple, quick hack. I have lots of cds, and a very low tolerance for repetitive tasks like ripping them one-by-one. Furthermore, I have lots of friends who would like to archive their collections but don't have time to do it disc-by-disc. So I decided to throw a little technology at the problem.

The proposed solution: load all the cds into a jukebox, and write a script that rotates them in and rips them, one by one. Consumer cd jukeboxes are becoming more common (and cheaper), so it seemed natural that someone would take a jukebox or changer mechanism and hook it up to a computer drive.

Surprisingly, there aren't many units like this available yet. The one I found was the PowerFile C200 Solo. This box holds 200 cds in a carousel, and has a single DVD-ROM drive that the cds can be swapped into. It uses a firewire (ieee 1394) interface to connect to a computer running windows. To the os it appears as two devices, a standard DVD-ROM device a custom device for the changer robot. The list price was $999, but I found one through yahoo shopping for $899.

Snags followed.

snag 1: decent activex scripting

The changer comes with a simple interface to windows explorer, so you can click on some icons and menus to mount or eject discs. Whoever designed it didn't think about user interfaces too much and buried the most common operations beneath a layer of roll-over menus, but I wasn't looking to use the mouse to drive this thing anyway.

The changer came with "c200.ocx", which should be accessible from visual basic. From past experience I know that writing any kind of significant program in vb requires a higher pain threshold than mine. My first attempts to access c200.ocx were from perl, but perl turns out not to have very good activex scripting support. Tocx provides activex support for Tcl, but after fixing a few bugs it became clear that it was too incomplete. The scripting language of choice for this project appears to be python. Python has support for lots of win32 apis. Unfortunately they are sparsely documented and I have had to spend a lot of time in the python source code figuring out how things are supposed to work - but that's faster than writing them myself. I figure I need to learn this stuff anyway, since python is also the most rationally designed and implemented of the popular scripting languages and I'd like to get better with it.

Another possible approach at this point would have been to get off windows completely. I decided that reverse-engineering the changer control protocol for linux would probably take way too long. If I had known what was ahead I might have decided otherwise, but the python experience has been completely worth it.

snag 2: ocx licensing

Unfortunately, the company that makes the changer thinks that mouse control is all you need in the basic model. I did not get a 200 cd changer because I wanted to use the mouse to drag cd icons into drive icons - I could just use my fingers to put real cds into real drives. For the privilege of scripting this thing, they want to charge me another $500 dollars for the "developers sdk". I think not.

Fortunately, the licensing protection for activex controls is extremely weak and well-documented on the web. The controlling application that came with the jukebox passes a magic string when it initializes the ocx; I watched the magic string go by and put it into C:\WINNT\system32\c200.lic.

snag 3: mounting new media

At this point I've spent enough time figuring out their OCX that it would have been "cheaper" to just buy their damned developer's kit. However, I have too much free time and too much pride and I'd rather give up on the project than pay them another cent.

Now comes the worst roadblock (so far): when I swap cds using my script, windows doesn't seem to notice that the cd in the drive has changed. Their driver software isn't signalling windows to re-read the drive, which would normally happen when a new cd is inserted into a cdrom drive. The explorer interface hides this brain damage because explorer is smart enough to scan for a new disc when reading it fails, but i don't know what explorer is doing. So I could circulate all the cds through the drive, but I couldn't actually read them without using the mouse. Aargh.

I gave up in disgust for a couple of months, occasionally skimming windows documentation to see if I could find anything new. Eventually I figured out the relevant DeviceIoControl call (and how to open the raw drive from python). The changer control part appears to be done.

snag 4: aspi on win2k

The early cd writers (and rippers?) were scsi devices, and the state of cd ripping software hasn't recovered yet. When drives using the more common atapi or ide interface showed up, people dealt with this by using a software emulation of the scsi protocol called aspi. For a long time, aspi drivers were only available from adaptec, and adaptec wasn't supporting them for windows 2000 and later. Win2k provides a new interface that should hopefully bypass the aspi madness, but not many rippers support it yet. I tried about 4 different vague ways to get adaptec's old aspi drivers working with windows 2000. Lots of people claim to have gotten this working, each in their own way - I did not. Fortunately, the folks who make the nero cd ripping and burning software have written their own win2k aspi driver and made it available at ftp://ftp.nero.com/wnaspi32.dll.

The best aspi page I found is Bart's page about aspi.

snag 5: scripted ripping

On unix this would be no problem, but all the windows ripping apps are designed to be mouse-driven. If I'm going to spend time hacking on a ripper it might as well be open source: the most serious one I found was CDex. My python skillz are getting pretty good at this point and it only took me a day to make a python wrapper around the cd ripping library that is part of CDex. This library includes the cdparanoia robust ripping code.

snag 0: was this really necessary?

After all this, the question comes up of whether this thing is still worth doing. It takes about 45 seconds per cd to load the changer - pretty convenient when it takes 10 minutes to rip the cd once it's in there. But, while I've been struggling with this, they've come out with drives that can rip an audio cd in a couple of minutes. Is the tradeoff still worth it? I dunno. But it's too late to stop now.