Slashdot Asks: SATA DVD Drives That Don't Suck for CD Ripping?
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.
I work in the entertainment industry, and we have to rip about 100 albums a month at work for online promotions of various sorts. The HP DVD drives work pretty well.
Why can't I mod "-1 Idiot"?
You might find the following list very useful. It was made by the author of Accuraterip:
http://forum.dbpoweramp.com/showthread.php?25782-CD-DVD-Drive-Accuracy-List-2012
Most new drives come with a control for the sound level, which will intentionally keep them running slower so that they don't sound like they're going to take off.
http://hektor.umcs.lublin.pl/~mikosmul/computing/tips/cd-rom-speed.html
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.
I take it that you did not read the question. It was regarding quantity to transfer immediately, not performing one-off copies.
With the drive that the poster already has, it will take 112h30m of continuous time in front of his computer to simply swap the discs. By comparison, the faster drive mentioned would result in a completion time of 37h30m.
Thirty four characters live here.
Online, as in actively spinning media inside of my computer, that I have RAIDed and backed up. I've disambiguated the text.
HAL 7000, fewer features than the HAL 9000, but just as homicidal!
1. Stop using cdparanoia - it isn't very good, at all. It tests poorly, we're sad to say. The software you actually want to use is Exact Audio Copy. You want to use Secure Mode with NO C2, accurate stream, disable cache. Yes, we said DISABLE cache. Trust us on this. We checked. Very very extensively. Yes, we know it runs slowly: that is because it actually does need to physically read every sector at the very least twice - that's the POINT. Sadly EAC isn't open-source (and despite many years passing, there still is no open-source software that does a Secure Mode), and runs under Windows (although it will function in a virtual machine if the drive is passed through well, such as VMware).
2. Use AccurateRip in that if you can. Matching the read offset is strongly-recommended-to-required - ideally, find one of the few drives that can overread into lead-in AND lead-out. You won't hear it on many discs, until you come across That One Disc that has the track transitions exactly just so and thoroughly audible if they're off (despite the Red Book standard having a truly ridiculous amount of defined leeway either way).
3. Hardware time.
a) Best case scenario: The Plextor Premium, which does have a (rare) SATA version as well as the IDE version. That is the best CD drive ever made, and it is the highest quality DAE drive ever made, by far. That, and the above software (especially if you set the drive to "first session mode", or use AnyDVD), will rip clean through any "Copy Controlled" discs you may have in your collection too, by virtue of sheer quality. Be warned: that drive is no longer made, and REALLY sought-after. It will cost hundreds of dollars to find one new, and any used ones will be totally clapped-out by a lifetime of ripping and burning discs in professional CD-R duplication towers, or poorly refurbished.
b) Can't get that? The Plextor PX-716SA will do the best job of any DVD drive. If you can find one easily, grab it.
c) OK, plan C: something else. You'll need to check up on DAE quality. Check the offset tables on AccurateRip, which might give you a few clues. Lite-ON are way, way more reasonably priced, and some models work well at this; check them. So do a few LG drives. If you get lucky, you may have some good hardware already. Be warned, however, that you may NEED AnyDVD to rip any "Copy Controlled" discs that you may have correctly if you don't use one of the few drives that are out there that can do the job.
4. Destination: Rip it to FLAC --best. Really, you're making an archival copy, and you are probably talking about terabytes of storage to play with - why WOULDN'T you use a lossless codec that is suitable for archival, well-known, free and open source, contains an internal MD5 checksum, supported by damn near every toolchain, supports all the metadata you need, and is absolutely guaranteed to not leave you with any possible transcoding issues if you ever want to transcode to a lossy codec for portable or streaming usage at any bitrate in any codec you want in the future?
5. No online storage is even close to trustworthy enough for archival purposes. By all means, if you want, for convenience: but buy a couple of hard drives and put it on there too, and put them away. OK, they might not work after a long time on the shelf - that is a risk. But it is still A safety-net that is less likely to fail than an online storage company which bears a multitude of risks (many of them legal ones, if they are storing people's music files for them in any useful manner).
Just throwing some other approaches out there - I'm sure people will point to SATA drives that rip plenty fast (myce.com is sure to have some recommendations, for what it's worth).
Alternative A: Why just 1 drive? Get multiple. They're cheap (sub-$15 for an external CD drive that'll happily do DVD as well. And burn them. Sell them on when you're done.)
Alternative B: Better yet, since you have so many discs, get a (semi-)automatic CD changer system. Sit back, let it rip a bunch at a time. Sell system on when done.
Alternative C: Why even bother with it yourself at all? Go find a CD ripping service. I have no experience with these guys - http://musicshifter.com/ - but at less than $1/CD and the option to have them rip lossless (yes, including FLAC) and send them a drive to put it on, perhaps it's worth it to let them deal with it and use your time and effort elsewhere. I know it's not much effort (I just digitized every single Stargate DVD between working on things, just swapping out the DVDs - each taking about half an hour), but the option is out there anyway.
Alternative D: Piracy! Well, it's not really piracy since you already have the CDs. There's some sites out there that will happily let you submit your CD's code (either the simple code used by e.g. Windows 95's media player or a more complex one) and spit out links for getting digitized versions. I'll let you do the Googling there.
Alternative E: Buy them. Certainly a lot (understatement, seriously) more expensive than the other options, but on the up side you should get perfect metadata, album art, etc. included.
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.
#fuckbeta #iamslashdot #dicemustdie
The OP states he only has linux in the house. I did this exact same thing a few years back, using abcde which is an interface to cdparanoia and cddb.
I set up an automounter script that automatically ran abcde when a CD disc is inserted. It reads the TOC in a couple of seconds and asks you to confirm the CDDB entries, which in most cases is just pressing enter twice. When it's finished it can even eject the disc for you. I'd literally just pop to the computer room every 10 minutes or so and just swap the disc and let it carry on. Probably about 10 seconds per disc.
That's if the digital 'locker' doesn't decide to change its policies and then wipe your files, or your internet connection goes down, or you run out of bandwidth for the month... It's still better to have a local copy and pressed cds are about the most reliable backup option there is. They'll outlive any human for sure if well taken care of. hard drives require IO ports that are constantly changing and take the media with them when they die. when the cdrom reader dies, just throw it away and get another. your data is still safe.
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?
Nonsense! Encode at 128k to save a ton of space on your drive, then convert the files to FLAC whenever you need higher fidelity. Win-win!
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.
STOP . AMERICA . NOW
Using a CD-ripper is so 1990s. What you want to do is buy a good quality scanner and scan your CDs using high-resolution mode -- should take about 20 seconds per disk. Then use any of the usual conversion programs to convert the scanned images into whatever audio format you prefer.
Keep your cds in a box somewhere as a catastrophic recovery, and have one duplicate of your ripped files offline somewhere.
So glad you told him this. Too bad that he had already thrown half of his CDs into the furnace before he heard your advice.
Breakfast served all day!
There's been a trend on Slashdot to shoot down questions like this without due consideration of what the submitter is asking, or just posting some obvious answers and consider the issue resolved. It was really nice to see this thread put forth a lot of information from the community. I didn't realize that there were 1) issues with SATA drives having issues on things like this 2) that there were people who cared about this kind of thing enough to have done the homework and the research behind it. It's called to my attention that there's a sub-genre of people for whom this matters, a lot. I've ripped scores of CDs in the last decade, but never paid enough mind to have it as more than a rarely-used utility. Thanks for the information, and you go, geeks =)!
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.
HAL 7000, fewer features than the HAL 9000, but just as homicidal!
Rip it all and then use something like beats to figure out the audio fingerprinting and correctly tag things for you.
Join the Free Software Foundation
That's the problem with WORM media.
Boffoonery - downloadable Comedy Benefit for Bletchley Park
Since we're talking about a manual process of inserting disks and clicking buttons, the different between five minutes and fifteen minutes can be rendered insignificant if you plug in enough drives. Since we're talking about a SATA system here, any reasonably high-end PC can easily support 6 to 10 SATA ports -- with enough channels to handle CDs certainly.
In your case, I'd focus my efforts not on finding a good ripper, but in configuring ten mediocre rippers. Your over-all speed with easily multiply.
> Nothing on my hard drive can be lost short of a fairly cataclysmic event that would simultaneous destroy
> all copies in existence, and frankly I'd probably be dead then too, so what would I care?
Don't be so sure.
I came TERRIFYINGLY close to losing 20+ years' worth of files permanently last year when my SSD, my Velociraptor-300, AND my 2TB Seagate hard drive all kicked the bucket within a 3-month window of time. At the time, I had the SSD backing itself up to the Velociraptor daily, was backing up the Velociraptor (including the SSD backup) to the 2TB drive weekly, and had the Seagate drive itself backed up to a 3TB external drive once a month or so (the Seagate drive was normally stored at my best friend's house ~15 miles away).
The problem was, as the drives failed and I replaced them, I ended up with multiple copies of recently-modified data, and ended up having a HELL of a time figuring out which was the new and which was the old copy. It took SO LONG to straighten out the resultant mess, that drive #3 ended up failing before I'd finished fully restoring everything from drive #2. And worse, because it took an eternity to do a full backup of the 2TB drive to the external drive (and 4-16 times eternity to restore it), I lost about a month's worth of stuff, and was in cold-sweat panic when I ran out to the store to buy yet another external drive to back up my last surviving copy of the data in case THAT drive failed, too.
Yeah, 2011 was a really, really bad year for my data. In addition to the two external drives, I now also have a complete backup of their contents on ~50 BD-R discs sitting at my parents' house. It took me about a week to burn, and a loss bad enough for me to ever NEED those discs would be devastating... but at least I can sleep at night now knowing that I still have one backup of last resort to fall back on if necessary.
After the crisis, I did a lot of soul-searching and research to find the most robust way to back up my data. What I learned (besides the fact that hard drive reliability has totally gone down the shithole over the past 5 years) was eye-opening.
I'd argue that the SAFEST media for long-term archival backup of files is probably non-LTH BD-R media. It's phase-change magneto-optical, unlike the organic dyes that were the norm for CD-R/RW and DVD+|-/R/RW.
For the record, "LTH" BD-R media uses organic dyes, just like older media, and anecdotal evidence suggests that data written to them has a half-life of approximately 6 months before they start getting correctable errors, and an estimated 18-30 months before they start getting their first uncorrectable errors.
In contrast, most of the phase-change magneto-optical media made by Matsushita and Sony ~15-20 years ago is still readable today (assuming you can find a working drive), and there's no real reason to think BD-R will be any worse (fundamentally, it's the same process now as it was back then... just smaller particles and tighter laser & magnetic fields). In case you're wondering what's magic about them, it's because MO drives use the laser to briefly liquefy the substrate so metallic particles within it can move, and use magnetism to align those particles while it's liquid. Once they re-solidify a moment later, your data is basically "cast in stone" and has no real expiration date.
Incidentally, Millenniata M-disc is basically a DVD-R that's built like a MO BD-R disc. It's one of those cool products that never existed in the format's golden era, but later became possible as a side effect of some newer technology. Kind of like some new gigabit ethernet cards & switches that can also be induced to do 100base-T4 (100mbps ethernet over 4 pairs of cat-3 cable). It was never widely supported back when 100baseT was the norm because it cost too much to add as a feature few cared about, but the technology behind it ended up being used to make gigabit ethernet. Once you have the hardware to do gigabit ethernet, adding retroactive support for 100baseT4 is basically an a
> Stop using cdparanoia - it isn't very good, at all. It tests poorly, we're sad to say.
Really! As the author, I'd love to hear hard specifics. or maybe a bug report.
> You want to use Secure Mode with NO C2, accurate stream, disable cache.
You can't disable the cache on a SATA/PATA ATAPI drive. The whole point of cdparanoia's extensive cache analysis is to figure out a way to defeat the cache because it can't be turned off. There is no FUA bit for optical drives in ATA or MMC.
The 'accurate stream' bit is similarly useless (every manufacturer interprets it differently) and C2 information is similarly untrustworthy.
Plextors are not recommended for error free or fast ripping. They try to implement their own paranoia-like retry algorithm in firmware and do a rather bad job about it. They also lie about error correcting information (you do not get raw data, you get what the drive thinks it has successfully reconstructed). Plextors often look OK on pristine disks, but if you hit a bit error (like on just about any burned disk), you don't know what it's going to do. Plextors are, overall, among the more troublesome drives _unless_ you're using a ripper that does no retry checking (ie, NOT cdparanoia and NOT EAC). If you use iTunes, you want a Plextor. Otherwise, avoid them.