Choosing An Automated CD Duplicator

In the past few weeks I’ve been spending a lot of time evaluating CD duplicator/printer units, sometimes called “CD publishers”.  That’s because the business I’m building around my self-improvement blog is finally getting to the point where I’ll be selling courses on CD, not just a book or a teleseminar series.  And, my first two courses will have 6 and 16 CDs in them!  Plus, next year I’ll be doing a monthly newsletter+CD by subscription.  So, I need to get a machine that will:

• Accept audio files and graphics from a PC
• Duplicate and print the CDs, and
• Stack them in groups!

Now the funny thing is that the last of those items is surprisingly hard to find in an off-the shelf duplicator, without doing any custom programming!  Most of them seem to be optimized for duplicating one CD, over and over, or else producing unique CDs, with no duplication.  That is, just being sent a bunch of files to create a one-off CD (e.g. with photos, just-recorded music, data files, etc.).  But virtually no manufacturer that I found, offers a way to say, “okay, here’s a batch of six different CDs, make me five batches, stacked in the output so that I can just grab off each batch of six and pack them to ship to somebody!

I evaluated systems from probably 5 or 6 companies in all, each with many models of machines.  The top three finalists (in descending price order) were:

• The Rimage 2000i,
• The Discmakers Elite2, and
• The Primera Bravo Pro

What these machines have in common is that they all support unattended operation for batches of at least 100 discs, do 4800dpi inkjet printing, and at least 48X recording speeds.  And, unfortunately, none of them provides any official support for collated multi-CD batches, without custom programming!

Evaluating the Discmakers Elite2

My initial preference among these units was the Discmakers machine, because it had a high capacity, and didn’t require a PCI/Firewire interface like the Rimage does.  Although it costs somewhat more than the Bravo, it seemed more rugged-looking (metal vs. the Bravo’s plastic) and it had a 175-CD capacity to the Bravo’s 100.  (Indeed, the Bravo only supports running 100 CD’s if you attach its “kiosk mode kit”: a flimsy-looking plastic bin that hangs off the front so the machine can dump CD’s into it!)

And the Discmakers folks were very helpful on the phone.  Steve tried to answer my questions as best he could, but explained that the included software could only do multiple CD’s in what they call “relay mode”.  In this mode, you put a master CD on top of a bunch of blanks, followed by another master and blanks, etc.  The duplicator reads the master, and then writes copies of it until it detects the next already-recorded CD.  Then it reads that disc and continues.

At that point, I asked if there was any way to record disks from the command line, or if there was an API available.  But it turns out that their basic software doesn’t have any kind of job queueing built in, so there was simply no way to tell it to burn a set of discs in series, except for relay mode.  But, Steve offered, they had a network package that you could get for about $400 more, that added a network-based queueing system for jobs, and had both an API and a command-line interface.  He sent me the pfcnet documentation, so I could investigate further.

At first, that approach looked promising.  I wasn’t keen on spending an extra $400 just to get a command-line interface, but the total price was still competitive with the Rimage 2000i.  The “pfcnet” program took a simple text file definition of how to burn the CD, with impressive flexibility.  Any needed file, be it a disk image, audio track, or label graphic, could be specified as an FTP or HTTP URL, a UNC (Windows network) path, or a straight filename.  There was also a web interface, in addition to the command line one.

But then I realized the problem, as I dug deeper into information about the cache files setup and the web interface.  The paths and URLs and whatnot weren’t being processed by the server. They were, as far as I could tell, being processed by the client, and then the actual bytes would be sent to the server.

And that would mean that if I submitted these jobs individually, I’d be streaming each individual CD over the network, even if I did it from the same PC.  The files would get read off the hard drive… and then written back to the hard drive in a cache file, before burning each CD.

And as you can imagine, that really wasn’t what I wanted.  So I started looking at the Rimage more closely.

The Rimage 2000i

Now, the Rimage, as the highest-priced unit, was also in some ways the most attractive.  Although it only has a 100 disc capacity, it doesn’t drop the discs out the front into a plastic catchbin.  The catchbin is built-in, and metal.  Also, the robotics on the Rimage are extremely simple: all the arm does is go up and down, picking up and dropping CD’s.  It doesn’t rotate or slide horizontally or anything: it just goes up and down.  And, most importantly, its software description strongly implies that it can do multi-disc sets!  That is, it says:

Save single disc jobs, multiple disc jobs, and group multiple jobs for easy resubmission

Sounds good, right?  Well, sort of.  I talked to their sales department, who were fairly sure you could do multiple disc jobs, but weren’t sure if you’d actually get them in order or not.  They thought that you would probably get N copies of one, N copies of the next, etc.  But to be sure, they sent me to their “application engineering” department, where I left a message and received a call back the next day.

Well, several calls, actually.  Because the person who called me back didn’t really have the answers at first either.  But to make a long story short, she explained that the main issue was that their software was designed to absolutely maximize disc throughput, even at the expense of changing the output order.  Since the unit has two CD drives, it will basically choose to print and drop whichever CD finishes burning first, if both drives are in use.  So, the output order isn’t really predictable, because it depends on how long it takes to print and burn the CD’s in question.

There was, however, on their more advanced software ($999 extra), an option to set a “FIFO mode”, in which CDs would always be printed in the job input order, even if it would slow down the overall throughput.  Also, there was an XML-based messaging queue system that the more advanced software had, so that I could send it stuff to do.  The “production server” of that software runs as a Windows service (daemon), so I could just write a program to feed it XML job files and do what I wanted.   Except…

It had the same damn problem as the Discmakers Elite!  The server wasn’t set up to just burn images already on its hard drive, it was set up to read things and then cache them as images.  Basically, she explained, this mode of operation was designed for producing unique CD’s… just like the Discmakers.

So I was a bit disappointed.  I really liked a lot of things about the Rimage: ruggedness, lack of assembly required, and the documentation I read about their network software made it look like they really had their act together, software development-wise.  Unfortunately, that act just didn’t include what I was trying to do!  So it was time to consider other options.

The Primera Bravo Pro

I had more-or-less previously ruled out the Bravo machines.  In part, this was because I thought there was only one: the Bravo II, a single-burner unit with a maximum capacity of 50 discs.  But the Bravo Pro has two burners and a 100-disc capacity, putting it back into the running as soon as I realized the difference.  But now the question was whether the software would actually do what I needed.

What I found surprised me.  First, although the Bravo’s Windows-based software didn’t support multi-disc jobs, its Mac version did!  (At least, according to a few reviews out there on the net; I couldn’t find any docs on Primera’s site that indicated one way or the other.)  Second, although the basic Windows software didn’t support multi-disc duplication, the Bravo Pro included a free network version of the software – and I found documentation on their site for their PTBurn SDK’s queueing API (PDF).  The queueing mechanism is actually based on inserting files into a queue directory, and there’s some primitive backchannel communication of job status.

Most important, the file paths (including disc images) are processed directly by the server, rather than being streamed over the network, meaning that it should be able to simply burn each disc straight from the hard drives to the CDs.  And, since the server renames job files as it picks them up, I should be able to write a simple Python program to submit new jobs one at a time, waiting for the server to pick up the previous jobs before submitting new ones, thereby enforcing a serial order.

In fact, the PTBurn API provides a wealth of status information about the system, like how many jobs it has left, how many jobs are ahead of a particular job, and so on.  You can tell just from a job’s filename whether it has been “noticed” by the server, whether it’s actually being run, and when it’s finished.  You can find out stuff like whether the ink is low, what time a job started, when it finished, and how many bad CD’s got thrown out during the job.

Indeed, the richness of the PTBurn API was comparable to that of the Rimage…  except that the PTBurn network software comes with the base unit, at no extra cost!  Even without having the full PTBurn SDK (which includes a standalone installable version of PTBurn, and some sample code for creating job files), I could still use just the documentation I found to write some Python scripts and make a standard, off-the-shelf Bravo Pro do my bidding!

In Conclusion

So, after contemplating the options a bit further, I decided to go with the Bravo.  While there’s still no guarantee I’ll get it to do exactly what I want, there seems to be a much better chance than with the others, and the price simply can’t be beat, especially on eBay.  Many sellers offer new Bravo Pro’s for less than you can get used or refurbished units of the other types I looked at.

Meanwhile, its low-tech queueing API seems like just the tool for the job, and it looks like it would be easy to create a Python API that conveniently exposes all of its features.  Heck, I’ll probably release it as a Cheeseshop package.  In fact, since PTBurn will accept .BMP or .JPG images for printing on the discs, I could perhaps use the Python Imaging Library (PIL) to generate custom-labelled discs with the name and a picture of the person they’re being made for!  (I don’t actually have a use for that right now, but it sure sounds like a cool idea!)

As of this moment, however, I haven’t actually received the unit yet, and probably won’t have a lot of time to play around with it at first.  I’ll post more when I know more, and maybe again if/when I release a Python API for the machine to the Cheeseshop.