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.

be careful ....

[reaper20]

If this is possible, I can imagine that the pace of ripping would still be way faster than encoding. You'd need some serious space on your machine to compensate, unless you slow it down considerably .... I could see myself turning this on ang going to sleep, only to wake up with a machine crammed full of .wavs...

I have 3 scsi cdroms on my box ... and even at that pace I have to slow down for a while to let the machine catch up.

Then again, depends on your processor, so ymmv.

Probably not going to work the way you want

[chris_martin]

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:be careful ....

[Trepidity]

No it wouldn't be. Jukeboxes can only read off one CD at a time, and since they're audio devices only do it at 1x. So you'd have a continual 1x stream coming into the digital input, which any decent computer can easily encode in real time.

Some might think it's better this way.

[insane]

This is certainly possible, and perhaps better. The SPDIF output from your Sony has been error corrected by the CD mechanism inside. Using CDDA on a CD-ROM is prone to more errors since the data isn't error corrected the same way. On newer drives this usually isn't a problem, but it can be. One thing though, since you can only play the CD's out through the SPDIF in real-time, your idea will certainly be much slower than ripping from a 40x CD-ROM

-apg

---------------
"Oh, Precious Roy you get us every time..."

-Sifl and Olly

A couple of problems

[norton_I]

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.

Re:Hack time?

[Anonymous Coward]

Yeah, that automated ripper that gets the track info and builds a spiffy ID3 just by dropping it into the tray is iTunes!

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

[Tide]

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.

Re:External Jukeboxes can at best RIP at 1X

[Casca]

1. Who cares if it is slow, automation is the key. Set it up, and let it run for a couple of days, or a week...

2. I think this will fix that: http://akom2.2y.net:81/mp3ascd/ [2y.net]

3. Thats what he is asking about, is there a way to do it?

Re:Track info

[apago]

Via slink interface. I am already calulating the diskid and looking up track info via freedb.org.

Re:External Jukeboxes can at best RIP at 1X

[apago]

1) if it's automated I don't really care about the speed since I don't have to change discs.
2) I already can get track info via freedb.org. I calculate the diskid via the slink-e interface to the sony jukebox.
3) I also control the juke via slink protocols.

Re:be careful ....

[zhensel]

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.

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

[dstone]

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.

avoid ide jukeboxes; they tend not to do DAE

[TheGratefulNet]

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.

there are alot of perl scripts that do this plus..

[gimpboy]

...a few with a gui. i prefer rip [sourceforge.net]. if you look around on freshmeat [freshmeat.net] there are quite a few more.

iTunes? cdslayer?

[helixblue]

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!

Having just ripped 800+ CDs....

[mckwant]

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.

Re:iTunes? cdslayer?

[artemis67]

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.

-----

Comment removed

[account_deleted]

Comment removed based on user account deletion

False

[Skipio]

Not true. The SP/DIF can actually degrade the digital sound signal [by causing jitter] . If you want to know more about this please read the following two articles on the subject.

http://www.republika.pl/mparvi/digital.htm [republika.pl]

http://www.geocities.com/jonrisch/jitter.htm [geocities.com]

Btw.: Many [most?] sound cards use 48khz as an internal sample rate and upsample any sound signal that has a lower frequency. A 44.1khz CD track would therefor be upsampled to 48khz if input via the SP/DIF connector on the sound card. This, of course, degrades the sound signal somewhat.

I've done it and it's GPLed

[tramm]

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.

Re:some problems...

[Eric Smith]

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.

Re:You want Automation?

[apago]

Thanks for the suggestion but I already have an Ibook among several other computers. I use GlobalCom web jukebox for ripping now. It's very fast and overlaps ripping CDDA, encoding to mp3 and normalizing volume levels. It looks up CDDB data from freedb.org. However it's still a slow process. I have ripped about 2400 songs in my spare time over the last week. Automation would kick ass and allow me to reencode the cds if I decide the change the encoding method (switch to vbr or some non-mp3 compression scheme) without having to sit in front of the computer for days on end.

Re:I've done it and it's GPLed

[ZxCv]

Why hasn't this been mod'd up higher?? Differentiating itself from all of the other typically close-but-no-cigar posts found here, it actually addresses the exact question posed by the submitter exactly.

Amazing, but true.

Moderators use your points and give this guy just credit !

Re:be careful ....

[Ares]

It's actually 44.1khz at 32-bits. 16 bits per channel. So the audio data rate really is 172KBps.

Grip is your friend

[terminal.dk]

I have been using Grip on Linux. It is the best tool I have yet seen for this.

It will read the audio at full speed, buffer it on the harddrive while converting, eject CD, start new rip when next CD is inserted.

So it takes a few minutes per CD, and you could easily do 20-50 CDs in a few hours if you have harddisk space for them to be buffered before conversion.

Re:Track info

[sxpert]

can you post a link to the software, as some of us can be interested

AudioCatalyst

[skadork]

I've done this before. I've found a way that is alittle bit faster than doing it manual. It does, however, require two cdrom drives and a good version of AudioCatalyst. In AC there is an option for "continuous ripping". what this does is open up two copies of AC. It will begin ripping from one cdrom and when its done, it will eject, then move to the next cdrom. So, you simply replace the finished CD with a new one and you're set to go. And just as a hint, I would put all the popular CDs together and do them first to make sure AC can find a CDDB entry for it. Then I would do the ones that might not be so popular so you know that you will get the right filenames and an ID3 tag. this is just my opinion

CyberDrive 24x

[DivideByZero]

I used to use one of these with CDParanoia - When it was in a good mood, it'd just give me an endless pile of jitter errors - When it was in a bad mood, it'd flood my SCSI bus and cause General Badness. The same disks ripped OK with my Plextor, but that isen't exactly fair, is it? :)

I guess most people would assume that a $15 SCSI peripheral would be junk, but I thought a comment was worth making before somebody dropped $150 on ten of these things.

cdex

[Apreche]

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.

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

[Stormin]

A few jobs ago, I had a client (who was a DJ) that wanted exactly this written. Except he wanted to use CDJ (program that comes with the Slink-E), and have the MP3's go into CDJ.

We had a sound card with a TossLink input that did an outstanding job of recording from the Sony changers.

CDJ made it easier to get the track names since it handled the CDDB stuff, and it had an automation interface so we could control it (and the CD player) from the program.

We built a version in about a week that would rip two sample CD's we'd made for the purpose.

When we went to production we had various problems - mainly, with the Slink-E, there are enough delays that you can't guarantee you are starting the recording at the right place. The gap isn't always the same, so you can't add a set amount to the beginning.

The end is even worse - For a track reported as 2:30 by the player when it started, sometimes 2:30 was the last time indication we'd see. Other itmes, 2:29 was the last indication. This made it very hard to stop recording at the right place.

I don't know if they ever used this or not, because I don't work there anymore. I think if I were doing it I'd use a computer, since you can rip faster than 1x.