The software included, called simply 'Scribe' was designed for mass duplication efforts plus printing, so wasn't suitable.

It basically consists of a list of queued operations, and just typically either takes an ISO copy, or writes an image back to disk. It does have some half-arsed audio CD capability, but it wasn't viable.

A browse around the C: drive revealed an interesting PDF file for technicians, detailing the task of altering the CD insertion point for different drives. This also revealed how you communicate with the robot, which is simply via serial USB (9600 8n1 I believe) and a set of single character commands.

Hyperterminal served as the diagnostics tool.

K (in capitals) for instance carries out the whole process of lifting a disk up from any of the input bins, and popping the disk into (one of) the left drive(s). It has limit opto-interrupt switches, IR optical sensors, and just goes through a pre-canned, quite fast, motion to complete the op.

It knows if it succeeded in successfully depositing the disk, and will return either a capital X for success, or a capital E for error.

Furthermore, another single capital character (can't remember) will also pick the disk out of the tray and deposit it on the output 'spike' which is just a thicker metal spike for containing loads of disks, through the middle hole - this output spike obviously rules out any possibility of the robot independently being able to get them back off of the output pile, so repeat ops are pretty much out of the question.

I saw absolutely no reason to dig further into the control chip, or rewriting firmwares, or even hacking in some custom firmware, due to the fact it did everything I already ever needed. Furthermore I had aspirations of re-doing the driver board entirely, but simply didn't need to!

So armed with this knowledge, to be able to rip disks in a stack, was simply to programmatically get together all the independent operations required, and implement them on a loop, with error checking in place -

• Insert disk
• Remove disk
• Eject Tray
• Retract Tray
• Recalibrate robot (return home in error condition).
• Rip CD.

I had no idea whether any software was already out there to do this, but it seemed an interesting (and simple) enough job to just come up with my own software in Windows.

So I set out building a Windows Forms .NET 2 application in C# (It's running on XP - didn't want to install any more bulky recent frameworks) which carried out all these steps.

This is the result, called 'Robot Ripper'. Notice how I put up a button for all the individual tasks, very handy for trying out the gripper after reworking it. The main AUTOMATE button is the bit that just sequences everything, carrying out correct wait operations (not blocking delays!) before proceeding.

It's all very simple, and because I've written it myself it's fully extensible, any error conditions could be flagged up and alerted in real time (although I haven't done this yet).

Of course another feature needed was the all important ripping software, but I didn't have a clue about how to do this in .NET. So I leveraged the services of a brilliant suite called CueTools - critically includes a command line ripper program called CueTools.ConsoleRipper.exe.

ConsoleRipper is great because it goes off and fetches a WAV of the whole disk, and a .CUE file containing the album name and song names, looked up in an online database. Then I need to convert the WAV to .MP3s, to do this, the CUE file contains all the info required to do the conversion, as it also stores the track separations for the disk.

One of the key features is to be able to compare your rips byte for byte against a big database called AccurateRip, to see if it's a totally golden copy.

I highly recommend it, even the GUI is pretty good.

At the right time, Robot Ripper just shell launches the ConsoleRipper program and gives it the correct drive ID. Off it goes - Robot Ripper doesn't block horribly, it sits listening for the process-end callback event before it moves on.

This is critical, as the program can sit doing things in the background, or foreground listening for user input. The 'cancel job' operation benefits from this way of working as you can click it at any time to quit the process.

I had Robot Ripper actually redirect the CUETools.ConsoleRipper.exe output text into an internal text box before (the one on the right of the Robot Ripper window), but this introduced a delay in the grabbing process, something to do with the speed with which the progress bar updated I believe, so I went back to simply spawning it in it's own window, but not before spawning a CMD.EXE for it to run under as well.

The bottom big text box shows the ripping process, showing when a cycle is completed, also whether any errors occurred, handy for looking back at a failed robot placement.

I should own up here - I didn't actually implement dual rips at the same time, it only rips to the left drive. The reason? I'm lazy, yes, but I realised the slow-assed PC could barely keep up with one rip let alone two. There is also the matter of the event coordination to worry about - what if two drives finish ripping at the same time, which one gets the attention of the robot arm to prevent disrupting the other rip? There are concurrency issues of which were not beneficial enough to deal with - basically implementing a full-on queueing system. Nuh uh.

The last step involves copying the WAVs up to another PC for doing the MP3 conversion. This is just SO much quicker on my normal desktop PC it's no competition. The instructions for this project detail pretty much the whole process. Suffice it to say, I use the CueTools GUI 'convert' profile.