Slashdot Mirror
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.
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.
-- Chris Martin, System Administrator
This would be way cool, but I forsee two major problems:
.mp3 files, you need to solve the TOC problem.
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
PowerFile 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 which includes visual basic samples.
People think Microsoft is the answer. Microsoft is just the question, "No" is the answer.
Yeah. But if you try to encode with a decent encoder and VBR scheme (the r3mix.net Lame method for example), you'll find that you won't be able to encode terribly quickly. With a 650 duron overclocked to the neighborhood of 750, I get about 1-1.5x encoding depending on the song. Also, you should try ripping from the CD with a secure method to avoid getting data errors. Yeah, I'm anal, but it's worth it.
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. 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
someone's project & some links
HA support
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.
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.
--
"It is now safe to switch off your computer."
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!
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.
.wavs at 1 or 2x, however, is completely unacceptable. That would've increased my time to completion by a factor of "a whole bunch."
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
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.
ceci n'est pas un sig.
Comment removed based on user account deletion
http://jukebox-control.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.
-- http://www.swcp.com/~hudson/
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 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.
The GeekNights podcast is going strong. Listen!