Automated Ripping with CD Jukeboxes?

apago asks: "I am ripping my large collection of CDs to MP3 one at a time. This takes forever. I would like to know if there is a way I can use my Sony 200 disc jukebox to help automated the ripping process. I can already drive the jukebox thru Sony's S-Link interface using a Nirvis Slink-e device. The juke has SPDIF output. Can I get a sound card with SPDIF input and start ripping thru the digital optical connection? Will this be the same quality as the CDDA data streams?" Now if something like this is possible, it would finally sell me on those multi-CD devices. I too am in the process of sending my CD tracks to MP3 format. It's a fun process, but a little bit of automation couldn't hurt.

Re:be careful ....

I think that is largely incorrect.

I HAD and still have a single speed CD-ROM (special Mitsumi interface board required!).

It does indeed play CD music just fine, and it reads data at 150 kb/s.

I think what the poster meant to say was this:

Since CD-audio is sampled at 44.1khz (44,100 hz), and is described at 16-bits of resolution the per second data rate is 705,600 bits. Converted to bytes that is 88,200 bytes/second. In kilobytes, that is 86.132 kb/s. That means a typical "classic" CD drive must sustain that transfer rate to play realtime CD Digital Audio.

I believe that when the CD format was defined that they defined the acceptable transfer rate at approximately 2x that rate, or 172kbps. Early production runs showed some trouble reaching that rate, and so, 150kbps became the standard. If memory serves, this was done to accomodate error correction and to provide a bit of room for extra data - perhaps extra channels or more resolution. 150kbps was defined as a "1x" speed after newer drivers offered beter performance. A 2x drive is 300 kbps, 4x is 600 kbps, etc.

But anyways, enough of my bad memory recollections. "1x" drives existed, but they were simply called "CD-ROM Drives" - they had no relative speed to compare them to. Just like the original DVD drives are now called "1x" - its because they need a baseline to compare "6x" drives by.

Probably not going to work the way you want

The SPDIF connection on your juke is 100% digital. The signal doesn't go through a D/A conversion, so it'll sound perfect, what your sound card does with it remains to be seen, though they all should do well. Creative labs has an add on to their PCI cards that add optical and coax digital connections. The problem is that the juke will only send the data out in real time. So where it takes but a few minutes to rip to MP3 on your computer using you internal drive, using the Juke it would take up to 80 minutes.

Re:False

Actually, you are only partly correct.

AES/EBU & SPDIF extract the clock from the incoming encoded bitstream with a phase locked loop. If you use this clock to drive your D/A converters, you are bound to the recovered PLL clock jitter specs. Tiny amounts of clock jitter cause real noise and distortion (Non-Harmonic Distortion!).

HOWEVER, in this case, you are just receiving the data words and storing them. The timing of these words is not important anymore. You don't care about clock jitter. That is not recorded when you store the the words to disk. So AES/EBU & SPDIF clock jitter do not matter in this case.

Anyways, that sucks if your sound card wants to sample-rate-convert the signal up to 48khz. Yes, that will cause distortion. My RME Audio 9652 (24 adat optical in/out, spdif in/out, wordclock, 44.1, 48, 96khz) pci card doesn't do that.

However unless they use a really crappy sample rate converter algorithm, that distortion will be masked by the mp3 encoding distortion.

--jeff

Track info

How would you get track info?

CDDB etc. use the track lengths etc. to work out which album it is but this information won't come along with the audio, so you'll need to post-process the ripping operation to look up the album and rename the files or you going to have 1.mp3 through 3000.mp3 which would be a PITA!

External Jukeboxes can at best RIP at 1X

Problems with using external home audio jukeboxes are:

1. Top ripping speed is 1x... slow

2. No disc info, so no CDDA type track ID info, are you going to type in all the track info?

3. No standard interface for controlling the external jukebox.

So although it would be GREAT to rip 50, 100 or more CDs at a time, there is no inexpensive way to do it.

A few years ago there were SCSI jukeboxes commonly available. I have a couple 7 disc ones sitting on my shelf, one 2x, the other 4x. Sadly both are so old they do not support audio ripping.

Unfortunately that market seems to have all but disappeared to be replaced with SCSI jukebox towers. You can build one yourself using cheap SCSI CD-ROM drives, and a big SCSI tower case. ComputerGeeks sells 24x SCSI CD-ROM drives for $15 each:

http://www.compgeeks.com/details.asp?invtid=240S

You don't even REALLY need a case, you could just stack them up, tape them together, and use an old AT power supply to give them juice. Heat is not an issue since you are only using one at a time.

Re:some problems...

1) How will you automate separating the tracks? If you are recording from spdif it's all going to be one long mp3. I'm sure you could write a filter to do silence detection, but that doesn't work even close to 100%, many song have pauses in them.

If your SPDIF input hardware on the computer lets you access the User bit, that contains the Q subcode from the CD, which has the track number and time information with a granularity of 1/75 second. One user bit is transmitted per SPDIF subframe, and the CD Q subcode bits are packed into those in a pseudo-async fashion, where 16 consecutive zero bits indicates the start of a Q subcode frame, and a one bit is used as a leadin for each set of seven subcode bits.

Most SPDIF receiver chips (e.g., those from Crystal Semiconductor) provide a way for a processor to examine the Channel and User bits. I have no idea whether common PC sound cards have this capability. Wiring up an ISA card with a Crystal Semi receiver chip would be pretty easy.

For details, I recommend

• The Art of Digital Audio [amazon.com] by John Watkinson. 2nd edition had detailed coverage of CD subcode in section 12.18 and of SPDIF User bits in section 7.11. These may have moved in the third edition, but I expect that they're still present.
• Principles of Digital Audio [amazon.com] by Ken Pohlman. Chapter 9 has good coverage of CD subcode. Chapter 10 includes information on the SPDIF User bits for CD sources, but not in as much detail as in Watkinson's book.
• IEC [www.iec.ch] standard 60908. The definitive reference on the CD-Audio format, including the subcode. Not available free, but it's not too expensive (CHF 228.00, about US $133), and you can buy a PDF file online.

A couple of problems

This would be way cool, but I forsee two major problems:

1) Speed. AFAIK, multi-disk CD changers only read at 1X. Even with the highest qualtiy settings, I can encode at 3-4 times that rate on my dual CPU PIII.

2) Access to TOC. This is the real killer: if you want all the nice freedb lookups to work right, you need to extract the TOC from the disk and compute a hash of it. I am almost positive this doesn't go down the SPDIF line.

The speed I could deal with (just leave it running when you go on vacation for a week or so), but unless you want a hard drive full of unnamed .mp3 files, you need to solve the TOC problem.

Don't know about PCs, but on the Mac use PowerFile

PowerFile [powerfile.com] is a 200 CD/DVD jukebox over FireWire. Hell they even sell a re-writeable version. Not sure how it would work on a PC, but on the Mac its AppleScriptable and along with iTunes 2 you could load this puppy up and have it rip all weekend. I have one of these at work for archiving and I will bitch about its ease of use, though with some tweaks to their provided scripts, it worked fine.

Anyone know how this could work on PC/Linux? They have a M$ SDK here [powerfile.com] which includes visual basic samples.

This may sound silly but...

I actually hired a neighborhood kid to do that. A friend of mine was moving out of the area and I decided to make a local mirror of his collection so that I could continue to "borrow" CDs from him. It was around 400 CDs or so that I was interested in ripping but I quickly realized what a major hassle it was.

Then I got an idea and called up another friend and ask if his younger brother (age 13) wanted to earn a little money. I offered to pay $40 to rip them for me. I brought over a stripped down Win98 box with a fast CD-ROM and he got it done that weekend. All he had to do was stick the CD in, wait for CDDB to fill in the names, and click the convert button in MusicMatch or whatever the hell I was using back then. Rinse, repeat.

I mean, kids these days are usually familiar with the process anyway. A completely low-tech solutions but hey, if this is a one time deal why buy hardware that costs ten times as much?

- JoeShmoe

Re:This may sound silly but...

What a great idea, give the kid a little tech training, and get him started down the path of "RIAA is bad" at the same time. I like that!

Slink-e, S/P-DIF, etc.

Can I get a sound card with SPDIF input and start ripping thru the digital optical connection? Will this be the same quality as the CDDA data streams?

Every bit of audio present on a CD will be retrieved with a SPDIF connection. Enough quality for ya? ;-)

As for the interface and ease of writing discrete MP3 tracks when the SPDIF stream changes, tagging, etc., well, that's where a SPDIF connection becomes more of a hassle than normal ripping. But that's all really just a software issue -- all the hardware is available. Like the poster, I also have a Slink-e from Nirvis [nirvis.com]. Great box and it lets you pull approximate TOC info from the CD in a single or multi-disc Sony player (via an S-Link cable) to retrieve CDDB (or equiv) info for tagging or naming. You'll need another connection (S-Link, for example) alongside the SPDIF connection for player/disc/track data.

The Slinke hardware is platform independent, though the software the give away with it is entirely Windows. Search around and you'll see some Linux and Apple support for the Slink-e also...

in Python [connactivity.com]
someone's project & some links [www.hut.fi]
HA support [sourceforge.net]

By the way, the Slink-e is great for general infrared in/out in addition to controlling Sony (and a few other manufacturers') CDs, MDs, receivers, TVs, etc.

Is there really a market?

Now if something like this is possible, it would finally sell me on those multi-CD devices.

Of course it would be cool to throw all your CDs in a 50 CD changer and have it auto rip.. but would you buy one? The real question is, would you use it a second time?

Once you rip your collection, you only need to rip your new CDs (likely purchased one at a time) as you buy them. This you can do with a conventional CD drive.

I think at the cost that mp3 home audio is going for now, it isn't worth it to market or purchase something that is designed for this type of single use convienence.

avoid ide jukeboxes; they tend not to do DAE

I went thru at least 4 models/brands and none of them did DAE (dig audio extraction).

I am told there's a few Nakamichi changers that extract DAE over the scsi bus.

you really don't want to be stuck with a 1x system (spdif). even 4x beats that. plus, when you extract over a computer bus (not spdif) you can ID the disc and even read its TOC to get the song lengths, and use that to get the network cddb info. with an spdif stream, none of that is do-able.

iTunes? cdslayer?

I had originally written a script (based on ripit) that did mass-encoding into ogg or mp3 format on my FreeBSD box. The advantage it had over typical rippers is, other than total automation (auto-eject, auto-insert detect), it had a seperate fork for encoding and ripping. So you could rip 3 CD's while you were still encoding the first. You batch up 40 CD's in the rip queue, and wait overnight as the encode queue catches up. CDDB for ID3 tags and filenames, of course.

However, now that I'm using MacOS X as a desktop, I use iTunes, which is actually better, oddly enough. While it doesn't have the seperate rip/encode queues, it does have auto-eject & auto-encode on cd insertion. Where it beats out my old cd-slayer is speed. cd-slayer had seperate processes, iTunes does encoding as it's ripping!

The speed is pretty incredible, on some tracks (Front Line Assembly), it does the rip/encode process for 192K/s songs at 15.5X. More typically, I get 8X performance. iTunes smokes anything I've used by not only combining both processes, but having a nice SMP AltiVec Fraunhoffer based encoder.

So, this still means a single CD takes 4 minutes, but that aint half bad. It still means spending 13 hours on the weekend inserting a new CD when you hear the completion sound and the gears turning as your CD drive ejects. Slot drive encouraged!

So, if someone has a nice G4 around, do what my roommate does.. "Hey Thomas, can you rip these for me real quick?". Just an idea!

Re:iTunes? cdslayer?

Now just add this PowerFile 200 CD Jukebox [powerfile.com] that someone mentioned above, and use the Mac's built-in scripting language, AppleScript, to control it all and suddenly you're Hillary Rosen's personal nightmare.

-----

Having just ripped 800+ CDs....

The bottleneck isn't encoding. Period. Admittedly, I used CDex, which, from my understanding, is a Windows implementation of LAME, and it worked fantastically for my purposes.

Having said that, if I had to do it all over again, it would make a lot of sense to rip the CDs to wavs on a linux box, then have a cronned script to encode them.

By and large, the ripping took longer than the encoding. I was normalizing my CDs, so maybe that had something to do with it, but it'd be really nice if I could rip, rip, rip, then have my linux fileserver's processor manage the encoding while I was gone.

I think this concept maximizes the time that a human actually has to be around, and lets the computers do all of the repetitive crap. Which, of course, they are good at.

Ripping to .wavs at 1 or 2x, however, is completely unacceptable. That would've increased my time to completion by a factor of "a whole bunch."

Take your time, convert it to a format you WANT, and let the computers do as much work as you are comfortable with.

Speaking from experience, you definitely will NOT want to do this again.

I've done it and it's GPLed

I used to have my entire home theatre automated. Much of the work went into reverse engineering the specs and control protocols for Sony S-Link devices. The hardware and software are no longer supported by me -- I've moved and sold my house with the theatre. But you can still download the code, drivers and schematics for the small hardware interface:

http://jukebox-control.sourceforge.net/ [sourceforge.net]

Interfacing to grip, lame, etc is fairly easy. It has FreeCDDB interfacing and can grab the TOC from the disc. It also will write the title information back to the jukebox so that you can easily select discs from the front panel.

XBox = painful CD ripping

If you think that's bad, you should try ripping your CDs to the XBox. WMA format is fine, but you have to type in each of the track names. On a virtual keyboard. With a game controller.

I love being able to listen to my music while playing Tony Hawk, but it's painful to get to that point. Can't wait until they get this thing online so it can download the names from the CDDB.

Changers aren't worth the bother

I've ripped and encoded about 1000 CDs. Lessons learned:

1) Ripping requires significant manual work if you want good results - in particular, cleaning up missing or incorrect or inconsistent data from FreeDB/CDDB, and cleaning/repairing/retrying discs that you can't get a clean rip from the first time. (And normalizing if you want that.) Even if you could reduce manual CD-changing to zero, it'd still be a tedious process.

2) Ripping isn't easy. You really want a player with fast reliable DAE and software you can trust to detect possible errors. Ripping a large collection is enough work that you don't want to redo it because you eventual discover sporadic errors in your first results.

3) CDROM drives are cheap and well-supported. CD changers are expensive and require kludges. Instead of messing with a changer, it makes a lot more sense to stick a few extra CDROM drives in your system. Borrow some good drives and an extra IDE or SCSI controller, or buy/sell them on eBay to effectively get a cheap rental. Then rip the discs four or five at a time at 15-20x using cdparanoia.

Rip all CDs to WAVs on RAID, make MP3s w/multi PCs

Crunching MP3s from WAVs is the time consuming part. I focused on automating this.

I ripped all of my ~400 CDs to WAV format stored on a Linux RAID which is shared on my home network. I have two Western Digital 120GB drives striped in RAID-0, which gives me about 220GB useable online storage -- easily enough for 400 uncompressed CDs.

Granted, the ripping process was not automated with a juke, but it only took about 5 minutes per CD with my Plextor CD-ROM/R/RW drive.

The most time consuming part is converting WAVs to MP3. I've decoupled the ripping and compressing processes, and automated the latter. I do this with LAME running on multiple machines against a common data store (on the RAID).

I have a simple "multi-processing" script which runs on Linux and windoze clients; I run one copy of it per PC on the net that can reach the input WAV repository and the output MP3 repository. These two repositories can be on the same RAID, or can be at different locations on the net.

Each album is represented by a single directory of WAVs, and each copy of the script (running one copy of the script on each of several PCs) "owns" the crunching of a single album directory from WAV to MP3.

Since the crunching process is primarily CPU bound (not I/O bound) throwing multiple machines at it radically speeds the conversion process. The 100Mbps NICs and switch I have are more than enough I/O bandwidth. I can even use some PCs which live elsewhere in the house (on the other side of a ~10Mbps HPNA2/phone-net bridge).

I can process the entire collection from WAV to MP3 in about a day using 7 PCs of various vintage. House stays nice and warm too.

Since I haven't yet found the "best" LAME command line incantation for me, I've found that I've re-crunched the WAVs->MP3s more than once. My plan is to keep all the original WAVs around until I find a set of LAME conversion options that create MP3s nearly indistiguishable [to my ears] from WAVs.

-----

Juke auomation idea is pretty darn cool. I could have physically loaded 200 CDs in a fraction of an hour. Less than a day later (assuming 8X rip speed is somehow possible), the RAID would have been ~1/2 full with no further intervention by me.

Why not use MP3.com?

They've got this great service whereby their
site confirms that you own a CD, and then you
can use their catalog of MP3's on the fly, saving
the trouble of ripping all of your CDs one at a time. It's a classic example of the American dream, where innovation with new technology creates new markets, expanding the horizons of creativity and comfort while driving the economy to everyone's benefit.

Oh, wait, the recording industry, which takes huge profits from the work of creative artists long after any of its contributions to production and marketing have been recouped, and sells product to consumers at monopoly prices, thus gouging both sides of the buyer-seller equation, might not benefit.

Oops...never mind.

cdex

the easiest way to rip mp3s I've seen is a program called cdex. you insert cd, you wait for cddb. you click on button, you wait, the whole cd is now mp3s.