Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Music Hardware

Slashdot Asks: SATA DVD Drives That Don't Suck for CD Ripping? 330

I recently retired my ancient AthlonMP rig for something a bit more modern, and in the upgrade got a new DVD±RW drive. Since I have the new rig and a lot more disk space, the time has come to re-rip my ~450 disc CD collection into FLAC (I trust active storage more than optical discs that may or may not last another twenty years). The optical drive I had in my old rig was one recommended by Hydrogen Audio or somewhere similar for ripping CDs, and can grab an hour long album in about five minutes. My new drive, unfortunately, takes about fifteen to do the same. With the number of discs I have to churn through and the near-instaneous encoding, it's somewhat annoying. After searching the Internet high and low for advice I came up empty handed, and so I ask Slashdot: are there any SATA DVD burners that don't suck at ripping CDs? Read on for more details if you wish.

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.

This discussion has been archived. No new comments can be posted.

Slashdot Asks: SATA DVD Drives That Don't Suck for CD Ripping?

Comments Filter:
  • HP DVD Drives (Score:5, Informative)

    by jnelson4765 ( 845296 ) on Sunday December 02, 2012 @04:37PM (#42162943) Journal
    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.
    • by Anonymous Coward on Sunday December 02, 2012 @04:48PM (#42163021)

      I work in the entertainment industry, and we have to rip about 100 albums a month at work for online promotions of various sorts.

      So, that's what you tell the judges?! And they believe it?!

      "Well, your honor, I'm not a pirate! I'm doing this for promotional purposes for these movies and bands. Torrents? Oh! That's how we get our promotional copies. It's really efficient!"

      • Re:HP DVD Drives (Score:5, Interesting)

        by AmiMoJo ( 196126 ) * on Sunday December 02, 2012 @07:45PM (#42164207) Homepage Journal

        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, Informative)

          by madprof ( 4723 ) on Sunday December 02, 2012 @08:00PM (#42164313)

          Just use something like Exact Audio Copy. It does all that for you. It is pretty good at mending issues with CDs and automatically uses accuraterip.comto check tracks. It'll tell you how many tracks were ripped "accurately" and, if none, it'll tell you that you may have a different pressing to the one in the database etc.

        • Re:HP DVD Drives (Score:4, Interesting)

          by lucm ( 889690 ) on Sunday December 02, 2012 @09:48PM (#42164985)

          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, Insightful)

      by DJRumpy ( 1345787 ) on Sunday December 02, 2012 @05:45PM (#42163441)

      If there isn't a requirement to put both types of drive in the same slot, I'd suggest you get a good ripper (read only) to rip (for mounting in your rig), and use a separate external burner (USB) for burning. You could never saturate a basic USB while for burning and the lighter heads (Read Only) for ripping will give you a longer life on your DVD-Rom.

      For drives, LiteOn used to be a great brand, but I think these days they only do OEM hardware. Dig around and see if you can find any and you should be golden.

      • by RMingin ( 985478 )

        So you didn't look at the links, eh? The new drive that he hates is an iHAS.... AKA a recent Liteon DVDRW.

        • Re:HP DVD Drives (Score:4, Insightful)

          by DJRumpy ( 1345787 ) on Sunday December 02, 2012 @06:27PM (#42163683)

          You do realize the model he's using isn't exactly what one would normally use for ripping? it's a lightscribe drive, which is why I suggest a proper drive for the job rather than trying to use a one-size-fits-all that does none of them well.

        • But his reference to "lighter heads" for readonly and his use of the term "DVDrom", suggest that a DVDRW is not what he was recommending.

    • Comment removed based on user account deletion
  • by Aggrajag ( 716041 ) on Sunday December 02, 2012 @04:41PM (#42162973)
    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 [dbpoweramp.com]
    • by jbridges ( 70118 ) on Sunday December 02, 2012 @05:12PM (#42163205)

      That Accuraterip list is horribly outdated for new purchases.

      Almost none of the models that do well in their stats are for sale anymore.

      Most are IDE as well.

      • by epyT-R ( 613989 )

        accuraterip grabs hashes of track data.. as long as you get the right number, you know (reasonably) that you have a good copy. The drive db is outdated, but all that's needed is to configure the read offset in the software for your drive. each is different.

  • Sound level.. (Score:5, Informative)

    by Anonymous Coward on Sunday December 02, 2012 @04:46PM (#42163003)

    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

  • USB CD rom (Score:5, Interesting)

    by Anonymous Coward on Sunday December 02, 2012 @04:47PM (#42163015)

    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.

    • There are problems with this proposal. IIRC, the accurate rippers need direct access to the hardware, or at least drives that do not buffer reads. I don't think there are USB bridges that will let this happen. Things could certainly have changed - I finished converting my CDs years ago.

      • Re:USB CD rom (Score:5, Informative)

        by greg1104 ( 461138 ) <gsmith@gregsmith.com> on Sunday December 02, 2012 @05:44PM (#42163431) Homepage

        If you care enough about quality that you're using AccurateRip and need to check how the drive is caching, a USB interface might not work. The sort of USB->SATA chipsets used in USB CD-ROMs, which are universally cheap devices nowadays, will likely not pass data through faithfully enough to be useful for accurate CD ripping.

        That said, it is possible to find useful models if you test carefully. The external drive I'm using is a LG "Portable Super Multi Drive", model GP10NB20. LG makes many of the best CD ripping DVD drives available, and the USB chipset in this model is transparent enough for accurate ripping. At around $35, it's not the cheapest model on the market, but it's not like that's expensive.

    • and over load the slow usb bus

      firewire and e-sata are better then that.

    • I do a lot of movement onto and off of compact flash media and such. I recently got a USB 3.0 card reader and woo-doggy is it faster.

      Similarly I would expect that paying the tiny extra sum for 3.0 drives would let you stack a couple CD/DVD read/write devices onto your system a lot more efficently.

      You really can bump your head into the 2.0 data limits pretty easily at times.

  • by Anonymous Coward on Sunday December 02, 2012 @05:01PM (#42163123)

    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).

    • Were the Plextor Premium drives still made by Plextor themselves? I purposely keep all my older Plextor SCSI CD-ROM and CD-RW drives laying around. The Ultraplex 32X and 40X can read just about everything written onto a CD. I always thought they were sellouts when they decided to release ATAPI CD recorders. The Plexwriter 8/20X was notorious for being able to master Playstation game CDs and other copy protected crap with ease. I also used it to create masters for a friend's album that he sent out to be pres
    • 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.

      Many modern drives are built in such a way that "Secure Mode" won't give you any different results from any other mode, but will slow you down a lot. In particular, neither of the drives I recommend in my other post require you to enable the EAC features that result in very slow reads, yet you will still get the same output.

    • 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.

      Hey, marketing your product on Slashdot is fine, but posting your ad as AC is poor form.

    • by PipianJ ( 574459 ) on Sunday December 02, 2012 @07:37PM (#42164153)

      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.

    • by xiphmont ( 80732 ) * on Monday December 03, 2012 @01:54AM (#42166105) Homepage

      > 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.

  • If you're happy with the performance of the optical drive from your old rig, why don't you just install that drive in your new rig and continue using it?
  • by QuasiSteve ( 2042606 ) on Sunday December 02, 2012 @05:09PM (#42163173)

    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/ [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.

    • by PNutts ( 199112 ) on Sunday December 02, 2012 @05:30PM (#42163313)

      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?

  • Mass ripping (Score:5, Interesting)

    by girlintraining ( 1395911 ) on Sunday December 02, 2012 @05:13PM (#42163211)

    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.

    • 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.

      Unless you are just storing the ISO images, I have found that all the other stuff that has to be done to the movie (cropping, filtering/color correction decisions, which audio tracks to keep and in what format, identifying which playlist corresponds to which TV episode, accurate chapter placement, etc.) take long enough compared to the 20-40 minutes it takes to get the Blu-Ray onto the hard drive that I have plenty of stuff to do on the last ripped disc while the current one rips in the background.

      If I am r

  • I know it's a bit late now, but instead of voiding the warranty on your new shiny, you could've just gotten an IDE to USB adapter. A raw CDRom drive may not be the prettiest thing sitting on the desk, but once you get all your CDs ripped, you won't be needing it again until you buy a new CD, if even then. 15 min. to rip a CD isn't much when you only have one. You can rip that out while catching up on the days /. and email.

  • by aussersterne ( 212916 ) on Sunday December 02, 2012 @05:31PM (#42163325) Homepage

    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.

  • by turkeyfeathers ( 843622 ) on Sunday December 02, 2012 @05:34PM (#42163345)
    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.
  • by eldepeche ( 854916 ) on Sunday December 02, 2012 @05:35PM (#42163359)

    Never had a single problem with this drive. Available here: http://www.newegg.com/Product/Product.aspx?Item=N82E16827135204 [newegg.com]

    Seek/read timing:
                    [53:27.17]: 18ms seek, 0.30ms/sec read [45.0x]
                    [50:00.32]: 17ms seek, 0.30ms/sec read [45.0x]
                    [40:00.32]: 20ms seek, 0.33ms/sec read [40.0x]
                    [30:00.32]: 16ms seek, 0.37ms/sec read [36.0x]
                    [20:00.32]: 21ms seek, 0.41ms/sec read [32.7x]
                    [10:00.32]: 25ms seek, 0.48ms/sec read [27.7x]
                    [00:00.32]: 50ms seek, 0.63ms/sec read [21.2x]

  • by TheRealGrogan ( 1660825 ) on Sunday December 02, 2012 @05:56PM (#42163513)

    I have a cheap, bog standard LG brand SATA drive that seems to do OK. I don't rip audio CDs very often, but last time I did (I just do "cdparanoia -B") it didn't seem to take long.

    Here's my output of "cdparanoia -A" (I did this three times with similar result)

    This is on Linux 3.6.5 on x86_64.

    grogan@getstuffed:~$ cdparanoia -A
    cdparanoia III release 10.2 (September 11, 2008)

    Using cdda library version: 10.2
    Using paranoia library version: 10.2
    Checking /dev/cdrom for cdrom...
                    Testing /dev/cdrom for SCSI/MMC interface
                                    SG_IO device: /dev/sr0

    CDROM model sensed sensed: HL-DT-ST DVDRAM GH24LS50 YP01

    Checking for SCSI emulation...
                    Drive is ATAPI (using SG_IO host adaptor emulation)

    Checking for MMC style command set...
                    Drive is MMC style
                    DMA scatter/gather table entries: 1
                    table entry size: 524288 bytes
                    maximum theoretical transfer: 222 sectors
                    Setting default read size to 27 sectors (63504 bytes).

    Verifying CDDA command set...
                    Expected command set reads OK.

    Attempting to set cdrom to full speed...
                    drive returned OK.

    =================== Checking drive cache/timing behavior ===================

    Seek/read timing:
                    [74:21.35]: 62ms seek, 0.32ms/sec read [41.8x]
                    [70:00.32]: 56ms seek, 0.32ms/sec read [41.5x]
                    [60:00.32]: 57ms seek, 0.35ms/sec read [37.9x]
                    [50:00.32]: 61ms seek, 0.37ms/sec read [35.7x]
                    [40:00.32]: 58ms seek, 0.41ms/sec read [32.8x]
                    [30:00.32]: 61ms seek, 0.45ms/sec read [29.7x]
                    [20:00.32]: 62ms seek, 0.51ms/sec read [26.2x]
                    [10:00.32]: 73ms seek, 0.58ms/sec read [22.9x]
                    [00:00.32]: 71ms seek, 0.74ms/sec read [18.1x]

    Analyzing cache behavior...
                    Approximate random access cache size: 16 sector(s)
                    Drive cache tests as contiguous
                    Drive readahead past read cursor: 234 sector(s)
                    Cache tail cursor tied to read cursor
                    Cache tail granularity: 1 sector(s)
                                    Cache read speed: 0.14ms/sector [94x]
                                    Access speed after backseek: 0.71ms/sector [18x]
                    Backseek flushes the cache as expected

    Drive tests OK with Paranoia.

  • I'm impressed (Score:5, Interesting)

    by AnotherAnonymousUser ( 972204 ) on Sunday December 02, 2012 @06:03PM (#42163553)
    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 =)!
    • by s7uar7 ( 746699 )
      Agreed. It also makes a nice change not having to wade through tons of '"funny'" comments before getting to the useful/interesting ones.
  • by julian67 ( 1022593 ) on Sunday December 02, 2012 @06:24PM (#42163663)

    I'm using a SATA connected Hitachi GH15F and cdparanoia. This drive, as far as I can tell, is, or was, an extemely common OEM item.

    It works absolutely fine with cdparanoia and, if correct offset is set, gives identical results to EAC in Windows (you need cdparanoia 10.2 or newer; older versions had real deficiencies). I checked this with multiple comparisons where I ripped various CDs, some in poor condition, both with cdparanoia in Debian and with EAC in XP and then md5 hashed the raw pcm output: non-different. I also did rips on different drives on different PCs and achieved bit identical results on those drives which passed cdparanoia -A. Obviously this wasn't a huge dataset and doesn't prove anything but it was good enough for me to stop caring any further.

    Here is the output of cdparanoia -A:

    CDROM model sensed sensed: HL-DT-ST DVDRAM GH15F EG00

    Checking for SCSI emulation...
    Drive is ATAPI (using SG_IO host adaptor emulation)

    Checking for MMC style command set...
    Drive is MMC style
    DMA scatter/gather table entries: 167
    table entry size: 524288 bytes
    maximum theoretical transfer: 37074 sectors
    Setting default read size to 27 sectors (63504 bytes).

    Verifying CDDA command set...
    Expected command set reads OK.

    Attempting to set cdrom to full speed...
    drive returned OK.

    =================== Checking drive cache/timing behavior ===================

    Seek/read timing:
    [47:10.36]: 55ms seek, 0.36ms/sec read [37.4x]
    [40:00.33]: 61ms seek, 0.39ms/sec read [34.6x]
    [30:00.33]: 51ms seek, 0.42ms/sec read [31.9x]
    [20:00.33]: 51ms seek, 0.48ms/sec read [27.7x]
    [10:00.33]: 63ms seek, 0.58ms/sec read [23.1x]
    [00:00.33]: 66ms seek, 0.74ms/sec read [18.0x]

    Analyzing cache behavior...
    Approximate random access cache size: 16 sector(s)
    Drive cache tests as contiguous
    Drive readahead past read cursor: 234 sector(s)
    Cache tail cursor tied to read cursor
    Cache tail granularity: 1 sector(s)
    Cache read speed: 0.16ms/sector [85x]
    Access speed after backseek: 0.71ms/sector [18x]
    Backseek flushes the cache as expected

    Drive tests OK with Paranoia.

    As you can see it isn't going to be quite as fast as your old IDE drive but it isn't exactly slow either.
    You can safely ignore fetishists who feel EAC is magically unique and that cdparanoia can't do secure ripping. It can, as long as the drive passes the cdparanoia -A test. If you feel the need to compare your rips with rips made by properly configured EAC or dbpoweramp or similar then you need to set the offset correctly.

    Almost all the cdparanoia GUI's ignore the offset and don't allow the user to set it, so their rips will have a different checksum than an offset corrected rip by other tools. This doesn't have any bearing on the quality of the rip, only on the ability to compare it. It hasn't done much for cdparanoia's reputation but if you use it with a fully configurable command line front end such as ripit or abcde, or just by itself, you can get 100% secure rips equally good as those produced by magic tools with proprietary voodoo and vociferous fanboys.

    ripit is a perl script front end to cdparanoia, it will:

    "do the following without user intervention:

    getting the audio

  • I have five LG brand USB drives which I found were much faster than IDE for BURNING. They may also be much faster for ripping. I use a little shell script which keeps them busy. All I do is swap disks once the job is started, I don't touch the keyboard or mouse.
  • I've done a lot of work on streamlining my own ripping process (I've got well over 900 CDs to be ripped and tagged) and in the process, I got involved in helping out with developing rubyripper, a wrapper for cdparanoia. In the process, I've learned a lot about doing accurate rips and figuring out the various intricacies of the CD format. One of the things I observed was the relatively slow speed of ripping on my LG Blu-ray drive: it behaved exactly like you described: It would take 15 minutes to rip somet

  • by holophrastic ( 221104 ) on Sunday December 02, 2012 @09:09PM (#42164763)

    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.

  • by DarkOx ( 621550 ) on Monday December 03, 2012 @09:02AM (#42167781) Journal

    I ripped + encoded + tagged my entire collection with some shell scripts, just using cdda2wav to get the data. It was all auto pilot after some initial testing. IE every time the disk tray ejected I just dropped the next disk off the stack in. Sometimes I was in front of the computer doing other things, other times the display was off I was just walking past it.

    I have since been listing to my collection for years on a variety of devices and never once heard an audible error I can reasonably attribute to the initial ripping/encoding. I used shorten at the time ( like I said years ago ), but have since converted to flac.

    Knowing what I know about the technology I am certain the rips were not error free, most errors should have been fixed, but the unrecoverable errors must therefore be preserved. My point is it really does not impact my ability to enjoy the material though. Even if someone did have golden ears, would a few bad frames spread across several moments for audio really distract? Seems hard to believe.

    I think the article poster should consider he might be solving the wrong problem. Rather than trying to get perfect rips done fast, maybe he should try to get very good rips done fast.

The use of money is all the advantage there is to having money. -- B. Franklin

Working...