Slashdot Asks: SATA DVD Drives That Don't Suck for CD Ripping? 330
To work around the problem, I've temporarily yanked an old Promise IDE card I had in an ancient K6-2 rig (timothy found parts of it in a dumpster even) and am using the old drive, but it's approaching a decade and was pretty heavily used. What with having lots of moving parts and a laser or three, I don't see it lasting another decade, and I'd like to have a drive usable with a bus that hasn't been deprecated for almost as long. I'd also like to avoid anything that can read/write Bluray, because the hardware implemented DRM is pretty heinous.
For those interested in the gory details of the hardware I ran cdparanoia -A on both drives: ide drive, sata drive. As you can see, the old drive is way faster, and it looks like the primary difference is that it also has a cache that works with non-linear access, but that behaves "correctly." If you own a drive you want to recommend and can analyze it with cdparanoia, I'm interested in seeing the output.
A note on software suggestions: it has to be FSF-definition Free Software, and GNU/Linux is the only operating system in my house. That basically leaves... cdparanoia. I'm a bit uptight when it comes to tagging (mostly because: once I've done this, will I ever have the stamina to re-tag? Nope), but I'm not trying to start a pirate CD factory and don't really care about getting 100% frame-accuarate rips, just error-free ones.
USB CD rom (Score:5, Interesting)
Buy a collection of USB CD roms, so you can rip many discs at once. Then you aren't pulling apart your computer to add these drives, and they have a lifetime beyond your current computer.
Mass ripping (Score:5, Interesting)
The problem isn't the drive speed, but the amount of manual labor involved in placing hundreds of drives, sorting out the ones that have failed to be retried, and then restocking them. There are multiple optical disk loaders out there, but they aren't intended for transient use and usually require a painful data entry step at the beginning before the drive can locate them.
I have a similar problem, but for a collection of over a thousand mixed-media items. What I've settled on is building a three-spindle set and using a robotic arm with a vaccum sucker to life each item off the spindle and set it into the drive. The spindles are incoming, complete, and failed. The arm is controlled by a simple microcontroller and a couple of sensors to track position and success of each pickup, and connected by USB to custom software. The software alarms if there's a failure, and stepper motors for precise location. The arm "free-falls" from the top of the platter (on a gas piston to reduce contact shock) and a pressure sensor to detect when contact with the next item has been made. It also controls the drive eject/load and the ripping software is triggered using auto-it scripts. Any failure is detected the same way, by watching window titles, and then signalling pickup of the optical media after. There is also a webcam placed directly over the optical drive insert with a bright LED, and a picture is taken of the 'top' of each inserted media at high quality (in case the title is only printed on the inner track). The picture is placed in the same directory as the ripped ISO, and each directory labelled sequentially.
All of this makes post-processing a lot easier; The system can be loaded once a day (before I go to work), and when I get home, it will have ripped about 13 bluray discs. It only takes me a few minutes to rename each ISO to match the disk title from the image, after which it's placed in the pending folder which the ripper autoloads periodically.
But this setup requires knowledge of basic programming and some basic understanding of how robotic tasks are performed; And a significant understanding of electronics and assembly. Any of the homebrew microprocessor kits out there can perform the interface tasks as long as they have GPIO pins. Arduino, for example, has pre-built shields for controlling stepper motors to further simplify this process. The hardest part for me was building the actual robot arm; For that, I looked to how 3D printers are assembled as they've largely solved the problem of using stepper motors and precise placement within a 3D space without significant feedback.
Just make sure your robot's "sucker" can reliably release the optical media and not drag it; it only takes a little bit of moisture or stickiness to lift the optical media slightly and misposition it in the tray, and once the LOAD command is sent, your drive will eat the disc, permanently damaging it. It's also difficult to detect this in software -- the only indication of fault will be an unreadable disk and drive being unresponsive to load/eject commands. Make sure your apparatus fails safe, and I suggest testing all possible failure modes with throw-away media before using on production material.
Re:Alternative approaches: multi-CD, services, arr (Score:4, Interesting)
The OP didn't mention why the need to re-rip and why he's going with FLAC (other than the obvious FLAC benefits and a concern over media longevity), but if he has the CDs and is concerned about the time to rip, go lossy! And if so I'll add one more alternative that will save even more time:
Alternative F: Purchase one year of iTunes Match ($25 US) and you probably won't need to rip most of your CDs at all. Depending on what you have now the downloaded iTunes versions may be of better quality. I'm making the assumption he doesn't already have them in FLAC format because if so why re-rip?
Wrong solution. Think parallelism. (Score:5, Interesting)
Years ago when I had to rip all of my CDs to MP3s, I had about 500 to go through. I was a Linux user, so take this with a grain of salt if you're not one, but I simply went to the local university surplus yard, picked up 12 2x SCSI CDs for about $5 each, and connected them to some spare SCSI adapters and powered them with junk PC power supplies and 4-pin Y-cables. I'm sure you could cook up something similar these days with SATA or even USB and cheap eBay bare-board SATA->USB adapters. You could probably piece together at least a 4-6 drive solution for less than $100.
Then, I wrote a shell script that leveraged some basic shell tools. I don't remember what they were (I haven't done this for years), but one was cddb-something (queried online CD databases) and of course cdparanoia and lame and I think one called id3tag.
I scripted things up with the following logic, run on all drives simultaneously:
While (forever):
Poll drive for inserted CD.
If one is in, query cddb, save names in shell variables.
Rip using cdparanoia and default filenames, encode with lame.
Rename all files using track names in shell variables and folder using album and artist in shell variables.
Use id3tag to tag MP3 files according to file and folder names.
Eject disc.
End while.
Ran this on all 12 drives simultaneously in a terminal. Whenever a tray popped out, I took out the CD that had just been ripped and tossed it in the "done, recycle plastic medium" pile, and then stuck in the next CD in the queue and closed the tray.
With all drives cranking, it took no more than a couple days' intermittent CD-inserting (in the midst of doing whatever else I was working on--browsing the web, writing, studying, etc.) to move through the queue. And then I was done.
When I was done, I stuck all of the basically valueless drives in the garage, and I think years later they ended up at the dump.
If I'd had to nurse along a single drive, I don't think I'd be done to this day. Too big a PITA. 12 slow drives with an automated script > 1 fast drive by hand.
I'm impressed (Score:5, Interesting)
Re:Who cares? (Score:4, Interesting)
I've been using abcde for a decade (I'm the only who added the local cddb cache support, as a wee lad!), and the cddb editing stage is the problem here. It'd be nice to rip in the background while editing cddb, but unfortunately way too much of the script relies on the cddb info being ready before ripping starts. I'm guessing from comments that it's intentional that you have to edit before ripping, so that you can watch the ripping process. I guess that makes sense for people not using --never-skip.
Looking at the source again, it looks like it'd be less frustrating (hacking on a 10k line shell script and all) to set up abcde to batch rip and only rip into the work dir, and then "resume" with a different config and edit the cddb then. Of course, to add support for extra tags and grabbing the ISRC from tracks I've already rewritten cddb-tool in Scheme... the maintainer is going to love me when I submit all of my patches.
The only problem I have with batch ripping and resuming to tag/encode later is ... if I do too many of them at once(enough to make it worthwhile to either parallelize or wander by the computer every ten minutes), it would probably end up taking longer as I have to hunt through N cd cases to verify the info, especially in the case of multiple disc collections. Decisions, decisions.
Re:Who cares? (Score:5, Interesting)
Rip it all and then use something like beats to figure out the audio fingerprinting and correctly tag things for you.
Re:Advice from a DAE veteran (Score:5, Interesting)
1. The problem with EAC is that it's not open-source, and while it'll run on Linux with Wine, it requires you to use a GUI, which may not be an option on headless boxes. I won't deny that cdparanoia isn't as good as XLD, EAC, or dBPoweramp, but for a Linux box, it's still about as good as you can get, and although it doesn't support C2, cdparanoia III 10.2 does finally do well with most disc caches today. I mentioned in another reply here that I've used cdparanoia pretty reliably, although there are still issues (you need to keep a close eye on the quality gauge, as its repair mechanisms can actually deterministically mess up a CD rip!) But with a high-quality CD drive (Like the Plextors you mention) that gives low error rates by default and some double-checking of cdparanoia errors (i.e. assume that if cdparanoia reports that a track has errors that it didn't correct them), cdparanoia will work about as well as any other option. Yeah, you can't recover from errors as well as EAC or dBPoweramp can, but if you've got a pretty clean CD collection, you won't be too bad off. Combine cdparanoia with some of the command-line AccurateRip tools out there (as you mention), and you can probably be pretty sure your rips are good.
2. The only downside with AccurateRip is that it's not actually compatible with the GPL (use of the database imposes additional restrictions that aren't GPL compatible). The CUETools Database [cuetools.net] is GPL compatible (and even can repair some errors using some parity data!), but as of right now, no command-line tools play with it on Linux, and it's probably always going to be a little worse than AccurateRip due to fewer tools supporting it. I've been meaning to add support to rubyripper, but I haven't gotten around to it yet.
3. The Plextor PX-716UF is the external USB version of the 716SA, and may be better suited to setups where you absolutely don't want an IDE bus in your machine.
Re:HP DVD Drives (Score:5, Interesting)
Actually I have downloaded torrents of CDs I own. It tends to be faster than ripping and someone else has already gone to the trouble of doing all the metadata, downloading album art and most importantly checked the quality of the rip.
The faster you rip the most likely you will get errors. Mostly they are inaudible because the CD format is designed to cope with a few bit errors, but for nerds like me it matters :-) There is an app for doing this (http://www.accuraterip.com/) but it does take a lot longer than a normal high speed rip.
Re:HP DVD Drives (Score:5, Interesting)
Yeah, I don't think you know what you're talking about.
iHAS is not a feature or anything to be 'flashed out', it's the model number/name of the drive.
The firmware you linked to is still the Liteon firmware, it's just been patched to allow writing all the way to the rim of the DVD-R DL, specifically for piracy of Xbox 360 games with the XGD3 copy protection.
iHAS burners are a lousy choice for ripping audio CDs, and that's also true for damned near any current drive on the market. CD Audio extraction quality and speed is simply NOT a mass marketable feature anymore, and hasn't been for a while.
Re:HP DVD Drives (Score:4, Interesting)
Actually I have downloaded torrents of CDs I own. It tends to be faster than ripping and someone else has already gone to the trouble of doing all the metadata, downloading album art and most importantly checked the quality of the rip.
You must not be picky with metadata tags accuracy. I gave up on torrents when I stumbled upon songs like Brown Eyes Girl by Jim Van Morrison or Red Red Wine by Neil Young.
Re:HP DVD Drives (Score:5, Interesting)
THIS is why I cling to my Yamaha CRW-F1.
10 years old, 1000s of CDs ripped and burned, and never a bad rip, or a coaster to it's name!
Have you heard of these? Any thoughts?
Cheers!
Re:HP DVD Drives (Score:4, Interesting)
Actually, in a perfect world, mastering errors wouldn't exist to begin with -- it's perfect, remember? And over here in the real world, I normally get perfect rips from clean and undamaged CDs, even at rather high speeds.
Moving the head to re-read a single block? Just how physically wide do you think these blocks are that the weight of the head assembly would be a significant factor on either wear or speed, given the microscopic level of movement this entails?
Now then, I'm open to the suggestion that some readers may be better at ripping an audio CD than some recorders. But reasoning that excess mass must be the root of this perceived disparity seems more like blind faith than sound logic.
To wit, every cheap-shit DVD-RW that I have here, from Lite-on to LG, works both faster and better than the 32x Plextor SCSI CD-ROM reader that I bought exactly for this purpose ever did.