Follow Slashdot blog updates by subscribing to our blog RSS feed


Forgot your password?
Music Media

Automated Ripping with CD Jukeboxes? 274

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.
This discussion has been archived. No new comments can be posted.

Automated Ripping with CD Jukeboxes?

Comments Filter:
  • be careful .... (Score:2, Informative)

    by reaper20 ( 23396 )
    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.
    • Smart software would do a nice producer/consumer blocking queue type thing, where the CD player races ahead until a certain amount of disk space is being used for the temporary .wav files, at which point it would wait for the encoder to free up some space before continuing.
      • Heh, I don't see that kind of software being marketed anytime soon, unless said software company is willing to risk the wrath of the RIAA, fair use be damned...
      • grip for *ix does that already, as well as being an all-around great ripper/encoder. The only problem is that sometimes you don't want the ripping to stop (such as when you need to get a disc ripped and burned quickly), and then you have to override. All in all, though, it's a pretty useful feature.
    • Re:be careful .... (Score:2, Informative)

      by Trepidity ( 597 )
      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.
    • Re:be careful .... (Score:2, Interesting)

      by dfn5 ( 524972 )
      The setup that I have for ripping CDs to ogg vorbis files is a two machine process. I have a ripping machine that dumps the wav files into an NFS directory. That process takes about 20 minutes per CD. I have that process automated to the point where I enter one command, and it rips the CD, and then eject it so I can get the next CD in as quickly as possible.

      The second machine is a Sun E450 with 4 processors. I have a process that sits out there looking for albums that are ready to be encoded, and keeps 4 albums encoding simultaneously.

      The whole process works fairly well and the encoding is almost as fast as the ripping, so the only thing left is an automated way to switch CDs. If anyone can figure that out, that would be sweet. (And I'd be in Ogg Vorbis heaven).

    • I have access to a small LAN of 15 machines all 800MHz or better on 100Mb UTP. This would probably make a neato encoding ensemble.
  • Replace the CD mechanism in a jukebox
    with a Plextor reader??

    Is there a nice automated ripper that pulls track info and builds the ID3 and all just from dropping a CD in the tray?
    • Re:Hack time? (Score:1, Informative)

      by 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!
    • ...a few with a gui. i prefer rip []. if you look around on freshmeat [] there are quite a few more.
    • Re:Hack time? (Score:2, Interesting)

      by Phork ( 74706 )
      for linux there is software that will do exactly what you want. I use a program called abcde, it is really a frontend for various rippers and encoders and cddb. it combines them seamlessly. To encode a cd to mp3 i just put it in the drive, and type abcde. 20 minutes later i have the mp3s on my harddrive, stored in /mp3/artistname/albumname all with proper id3 tags. where the files are stored is configurable, how they are named is configurable, what ripper and encoder is used is configurable. i use lame set for 256k high quality and cdparanoia. you can find abcde at [].
    • Is there a nice automated ripper that pulls track info and builds the ID3 and all just from dropping a CD in the tray?

      SoundJam on the Mac will do that. Just keep feeding it CDs.
  • Processing power would be the first, but relatively easy to meet. The main issue would be the size of the HD, making sure there is enough room. Just script the rest if there isn't some other easy way to do it. Auto-It is what I would recommend if you are using a Winblows system.
  • Most of my music is already ripped, but I guess its time to redo, especially when .ogg is done.

    Imagine if you did this with a DVD jukebox. Throw them in, turn on .... tons 'o Divx on your server.
    • Imagine if you did this with a DVD jukebox. Throw them in, turn on .... tons 'o Divx on your server.

      You can buy a 200 disk DVD/CD jukebox for $999 from PowerFile []. 32X read of CD, CDROM, etc., 6x read of DVD, DVDROM, etc. This thing talks IEEE-1394. Note that it doesn't decode anything; it just reads and ships the stored bits. You need a separate decoder. Proper Linux interfacing is left as an exercise for the student.


    i've been hacking on autorip to support a multi-cd tower (mines on scsi so at least that part is easy).

    autrip is a perl front-end to cdparanoia/freedb/ and a wav to mp3/ogg converter.

    it's written for one device, but easily hacked for multiple (even if just the cheap way of forking it a bunch of times)

    it does track at a time converting so you don't need to worry about a disk full of wav's that need to be converted.

    unfortunately i've put the project on hold -- i can't get a stable 2.4 kernel on my PPC box that supports XFS. Currently when I launch cdparanoia the kernel bombs.
  • by chris_martin ( 115358 ) on Saturday December 08, 2001 @10:49PM (#2677158)
    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.
    • The few reviews I've seen for Creative Soundblaster Live's optional SPDIF input haven't been good. I'm worried about timing the start/stop of the cdrecord program to match the cd spinning up/down in the juke.
    • On some cards, the SPDIF ins resample at 48 kHz. CDDA is 44100kHz. The quality of this resampling varies from card to card. Of course, any variations might well be masked/overwhelmed by the MP3 encoding process/
    • 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.

      But the juke solution will rip 200 cd's in one sitting, whereas you will rip but just one. I unfortunately ripped my whole collection -- about 120 cds -- at 128k before realizing how much better 192k sounded (and before getting about 100 more gigs of space). I would love to have a 200-cd juke slowly-but-surely rip my collection in one pass. The old tortoise and the hare story.

      I want to hear from people who use a beowulf-optimized encoder. That would certainly help minimize temp disk space. Wow, setup a juke like that and you could charge to rip people's cd collections to a 100-gig HDD with next-day service. Sounds like a great way to make beer money for the frat house.
  • 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


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

    -Sifl and Olly
  • Track info (Score:3, Insightful)

    by Karma 50 ( 538274 ) on Saturday December 08, 2001 @10:49PM (#2677167) Homepage
    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!
  • If this is possible (and I don't see why it wouldn't be), couldn't encoding the output be a way around the new "uncopyable" CDs?

    If you can't rip them (due to the "defects" added to them to induce clicking noises), you can certainly encode the digital output (assuming you have a sound card that has the proper inputs), and get your mp3s that way.

    Hhhmmm... it seems that the first person/company to come up with a self-contained device that does this could make a lot of money...
  • by jbridges ( 70118 ) on Saturday December 08, 2001 @10:50PM (#2677170)
    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:

    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.
    • 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: []

      3. Thats what he is asking about, is there a way to do it?
    • 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 I calculate the diskid via the slink-e interface to the sony jukebox.
      3) I also control the juke via slink protocols.
      • Cool. I just looked at the back of my Sony Jukebox, and I also have the slink interface.

        It looks like the only thing you are looking for is the audio connection, and yes, many new sound cards have both coax and fiber SPDIF IO. Check out the creative live/audigy, or the Soyo DRAGON motherboard. The digital audio should be lossless, and error corrected by the jukebox electronics, so you should be able to record with any standard recording software (wavr on my debian box). Throw together some scripts to synchronize the recording start with the signal from the jukebox and you should be set.
    • One thing you can do is build your own CD changer robot. If the only feature you care about is "remove disk from ejected tray and insert next disk", it shouldn't be that hard. But unless you have more than a couple hundred CDs, I suspect you are best buying 3 or 4 CD-ROMs and taking a day to feed CDs into them as fast as you can.
    • CyberDrive 24x (Score:2, Informative)

      by DivideByZero ( 80449 )

      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.

    • The absolute best way to rip hundreds of CDs at one time is to find a laid-off .com business development VP and offer minimum wage to keep changing the CDs.

      On the other hand, you might find the cost of training prohibitively expensive...
  • some problems... (Score:2, Insightful)

    by PhuCknuT ( 1703 )
    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.

    2) You won't be able to automate the naming of files and id3 tags. You'll have to name every track manually.
    • Re:some problems... (Score:5, Informative)

      by Eric Smith ( 4379 ) on Sunday December 09, 2001 @02:01AM (#2677729) Homepage Journal
      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 [] 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 [] 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 [] 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 (Score:5, Informative)

    by norton_I ( 64015 ) <> on Saturday December 08, 2001 @10:52PM (#2677182)
    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.
  • 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.
  • What you want, really, is two jukeboxes (jukeboxii?). One that has real music CDs in it to be ripped, the other which can feed a CD writer. Depending on your writer, you'd need a gig or two of free space. Rip rip rip until you had an MP3 CD's worth of music, then write, write, write... Condensing music CDs down to MP3 cds, with a nice little back up of the music in the process. The software would let you either file the on-line MP3s somewhere or remove 'em to make room for the next batch.
  • Send your CD collection to me, and I'll rip it at your prefered bit rate, all with proofed ID3v2 tags. I can't guarantee, tho, that a copy of the MP3s will not stay on my 160Gb Maxstore MaxAttach NAS that I maintain just for my .mp3 collection.

    I'm serious - really.
  • by JoeShmoe ( 90109 ) <> on Saturday December 08, 2001 @10:54PM (#2677199)
    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
    • by Casca ( 4032 ) on Saturday December 08, 2001 @10:57PM (#2677220) Journal
      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!
    • 1. Massive copyright violations
      2. Child labour
      3. Hiring someone to commit crimes for you

      The Kinderegg commercial is so right, you can get three things at once. And it gets modded up to +5, Interesting. Remind me to quote it next time slashdot complains about those damn pirates ruining their wonderful fair use world...

      Of course I'm inclined to do exactly the same thing myself, so maybe I'm a good slashdot'er too

  • windac32 pro does it for windows. $30 if i remember correctly.

    this is a good program, because its halfway intelligent. it doesn't even store .wav's in the decoding process - it rips the data and feeds it straight into an encoder (lame, ogg, what have you) so the disk you have is only used by the final encoded bitstream.

    a good product, and it has excellent scratch repair. its very much worth $30. []
  • by dstone ( 191334 ) on Saturday December 08, 2001 @11:11PM (#2677293) Homepage
    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.
    • 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.
  • by RainbowSix ( 105550 ) on Saturday December 08, 2001 @11:24PM (#2677331) Homepage
    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.
    • yes
      personally I've ripped my cd collection twice already. and I plan to rip them again when .ogg comes out of beta. why? well, first time I ripped them at 128k. later I had a hard drive failure, and purchased a much larger hard drive. re-ripped at 160k. with a few months(hopefully( i'll re-rip again into .ogg, and forsee-ably I'll be ripping them several more times as bigger hard drives and better codecs are released, not to mention when I move in with my girlfriend and get to rip her entire cd collection too. ripping is a very timely process, especially if you don't have an extra computer to do it with. can't leave it going over night without being there to put new cds in...and can't do much with the computer while it's ripping. with how much I use my computer, that's a huge hassle.
  • by TheGratefulNet ( 143330 ) on Saturday December 08, 2001 @11:42PM (#2677379)
    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? (Score:5, Informative)

    by helixblue ( 231601 ) on Sunday December 09, 2001 @12:18AM (#2677487) Homepage
    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? (Score:4, Informative)

      by artemis67 ( 93453 ) on Sunday December 09, 2001 @12:47AM (#2677562)
      Now just add this PowerFile 200 CD Jukebox [] 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.

    • Since you're using iTunes, let me recommend the VBR feature (select custom as the bitrate, I chose 128 as the minimum, and "Best" quality). Sure you take a fair hit in performance (I went from 4x (160 kpbs) to 2.5x on my G3-350), but it seemed worth it to me because I figured I'd only be doing it once (I've got about 140 disks in my collection), and disk space & quality are forever.

      I've also got dual drives, and only ripped the songs I'd actually listen to, both of which I'd say halved my time, because I could preview the disk I wasn't ripping and decide which tracks I wanted. And iTunes remembers your settings, so I could preview a queue of disks, and then go off to do other things, and then whenever I walked by my computer and had a disc sticking out, just replace and insert.
  • Where can I get info on my CDs based on UPC? I'm not looking to use FreeDB - it's impractical to stick every CD I own into my CD-ROM drive. Instead, I've got a bar-code reader which will read the UPC. It doesn't look like FreeDB uses UPC at all, which is a shame since it's exactly this type of into I'm after.

    This is for a personal, non-commercial project to inventory my discs. Therefore, licensing expensive databases with "commercial" pricing is out of the question. I'd consider hacking together a script which would submit it to an online vendor (such as an amazon or cdnow) and parse the results, however I haven't found anyone who accepts UPC searches.

    Any ideas?
  • by mckwant ( 65143 ) on Sunday December 09, 2001 @12:45AM (#2677557)
    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.
  • A few months ago, I encounted a similar problem.. 40 or so CD's that I wanted to rip but I wasn't interested in sitting in front of my PC and switching out the discs. So, I started building a lego mindstorms mechanism to do it for me.

    When a CD was finished ripping, the PC would automatically eject the CD. The machine would sense the tray being out and pick up the CD (using a piece of double sided tape on the end of an arm). The CD would be dropped to the left of the CD tray (using a little pneumatic "solenoid") and the mechanism would go off to the right of the CD tray, pick up another CD, drop it in the tray. The whole process was timed perfectly so the drive would know when to close. The to-be-burned stack was simply stacked onto one of those spindles you get when you purchase a bunch of blank CD's. It worked pretty well but I took it apart before I documented it. :(

    Now that I've been laid off :( maybe I should try to reconstruct it. This time I could build a better unit now that I know where some improvements could be made. I'll work on it next week, if anyone is interested in the source or a small how-to, feel free to email me.

  • by tramm ( 16077 ) <> on Sunday December 09, 2001 @01:24AM (#2677645) Homepage
    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: []

    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.

    • 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 !
  • by SilentChris ( 452960 ) on Sunday December 09, 2001 @01:53AM (#2677710) Homepage
    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.

  • What do I mean?

    Look at it: A 200 disc audio CD changer that can be computer controlled through an easily accessible interface.

    Now, why isn't that CD drive a CD-ROM, or better yet, a CD-RW drive? Who here wouldn't want to have approx 140 gig of optical R/W storage - cheaply?

    There are larger changers available as well - 400 discs and more. They are cheap.

    Oh, yeah - they do make "commercial" CD-ROM/RW jukeboxes - but instead of being $250.00 - they are $5-15K! WTF? It must be because it seems like a niche market.

    I have a ton of CD-ROMs and CD-Rs that I would love to be able to load into a jukebox to use at a click of a mouse. I have even thought about what it would take to build my own jukebox, or possibly convert an existing cheapo jukebox.

    I know some of you are thinking "Dude! Get a few 100 gig IDE drives and shut up!" - All I have to say to that is that you are forgetting that these hard drives can crash, and there is no cheap way to back up - while a CD will last a very long time - you don't have to worry about it much.

    I just can't understand the large difference for something that would be cheap and easy to do for a manufacturer...
  • I do this using what has become known as the "Tower of Changers". I have 7 Nakamichi 16x 5-disc changers in an external SCSI case. I just load it up with 35 CDs, run my script (which encodes from all 7 drives at once), and a few hours later I have a couple dozen GB of MP3s. Very handy. Not quite as sexy as using a 200 disc changer, but it works very well.
  • by jaffray ( 6665 ) on Sunday December 09, 2001 @04:37AM (#2677914)
    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.
    • I've ripped and encoded about 1000 CDs.

      I just finished ripping +- 1300 CD's. Took me almost 4 months...

      1) Ripping requires significant manual work if you want good results - in particular, cleaning up missing or incorrect or inconsistent data from FreeDB/CDDB

      I gave up on FreeDB and its typos, it was faster just to type in everything myself.

      and cleaning/repairing/retrying discs that you can't get a clean rip from the first time.

      I used ExactAudioCopy [], it rips perfectly!

      btw, i used LAME 3.89beta, it takes quite a while, but at least i'll be sure i have near-perfect mp3's... The commandline i used is: -V1 -b128 -mj -h -q1 (VBR, average bitrate over 7600 songs is 181.5). Its rather pointless to use Xing to rip over a 1000 CD's, it will not sound good.
  • Bite the bullet and do it by hand ... The problem with damn near everything proposed so far is its far more work then actually *doing* the work.

    Get yourself 3 things:
    Fastest computer you can get your hands on,
    Fastest Plextor CD-ROM/CDR you can afford,
    and a skipdoctor ( to repair thrashed discs ...

    Do them in your spare time, if your watching tv, just get up every commercial break and insert a new cd ... its gonna take you a few days to do them all ... but all your doing is inserting discs and clicking -- it ain't that hard.
  • by MMHere ( 145618 ) on Sunday December 09, 2001 @04:52AM (#2677932)
    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.

    • MMHere came out of the closet to say this:
      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.
      lame --r3mix works fine for me. You could also try some of the --dm-preset options for even higher-quality VBR.
  • by The Cunctator ( 15267 ) on Sunday December 09, 2001 @04:54AM (#2677939) Homepage
    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.
  • 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.
  • AudioCatalyst (Score:2, Informative)

    by skadork ( 173626 )
    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
  • cdex (Score:3, Informative)

    by Apreche ( 239272 ) on Sunday December 09, 2001 @11:41AM (#2678454) Homepage Journal
    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.
  • Hardware hack (Score:2, Insightful)

    by aaron_pet ( 530223 )
    Wouldn't it be possible to take the guts out of a nice 50x cd rom.. and replace the drive in the disk changer? Yeah it could get ugly with cut up hardware.. but it should be possible.

    My guess is that the disk changer has a lame latch to hold the cd in place.. that works fine for 1 or 2x.. but not for real fast... you might be able to get by that by installing a bigger spring or something.

  • The time you'll spend developing a flaky system isn't going to pay off very much. Keep it simple, perhaps just write an automation utility that would automatically rip any disc upon insertion (by monitoring the drive's open/close state), fetching info from FreeDB of course. Then grab a big bag o'chips and some soda, move your couch within arm's length of the cdrom drive, and watch TV or play PS2 while swapping discs every few minutes. Boring, repetitive, but fairly efficient.

    With a good drive and a decent CPU (750mhz+), it shouldn't take more than 4-5 minutes per disc, which means 12-15 discs per hour. There also nothing preventing you from using multiple PC's (or just two drives in one box if the encoding is fast enough).

    Of course if you have lots of money to burn on a gadget, you could buy a robotic disc changer (or build your own from legos). But the jukebox thing is doomed from the start.
  • Hard drive space. (Score:2, Insightful)

    by llzackll ( 68018 )
    Make sure you have enough space. Ripping 200 full length cd's would take around 130 gigs uncompressed. probably more like around 90 gigs because most cd's don't use the full length of the cd. If you compressed them to decent quality mp3's, it should only take about 18 gigs though. ;)

Logic is a pretty flower that smells bad.