I neglected the bit which admitted that EAC is closed-source, but did want to emphasize that cdparanoia is just about as good as EAC... as long as your goal is simply determining if you have a bad rip. What you can't do is rely on cdparanoia to properly correct your data. I've encountered at least one disc which was deterministically "mis-corrected" on one of my drives but ripped without any errors (corrected or otherwise) on the other. But I know for a fact that of the 288 CDs in my collection that I believe to have been ripped accurately so far, I have yet to come across a CD which cdparanoia claimed ripped completely cleanly (i.e. with not even a single "corrected" error) which failed to match AccurateRip hashes generated by the same disc on a Windows machine.

Even ignoring the occasional "your CD matches no known pressing" hits I get with AccurateRip, I've come across only two discs which ripped cleanly and failed to match any known hash stored in AccurateRip, but even in those cases, the same "non-matching" hashes were generated on Windows with a completely different CD drive. The discs in question only had one and two hashes stored in the AccurateRip database, raising the more probable possibility that the hashes in the AccurateRip database were wrong rather than my rips.

Which is Windows-only and makes use of cdparanoia. If you want an open-source solution on Windows, it's an option I suppose, but the OP noted that he was using Linux to do his ripping. In that case, CDex isn't any better than using cdparanoia straight-out.

I noted that morituri supported AccurateRip when I was doing some research on whether it would be possible to implement AccurateRip in rubyripper, and, when I found the licensing issue, I concluded that you might not have noticed it, as it's rather subtle (my apologies in not bringing it up to you directly before now). In short, it's basically the same issue that resulted in VLC being removed from Apple's App Store

The basis for my interpretation was the fact that the AccurateRip database is, according to their website, "free for non-commercial usage, [while] commercial usage is restricted to prior agreement". This imposes an "additional restriction" under the terms of section 7 of GPLv3. As such, any end-user is permitted to "remove that term" (i.e. the restriction on commercial usage) from their license of your GPL program and thus make commercial use of morituri. But as this violates the terms of agreement to use the AccurateRip database, it becomes effectively impossible to meet both the requirements of both the GPL and the AccurateRip license (since you don't have the right to add the commercial restriction to the GPL for your end-users, per section 10 of GPLv3 (section 6 of GPLv2)). As such, you are not legally permitted to distribute any object or source code licensed under the GPL that also makes use of the AccurateRip database.

Now of course as the author of morituri, you could relicense your code under an alternative license that was compatible with AccurateRip's commercial-use restrictions such as the BSD or MIT licenses (caveat: any contributors would also have to relicense their code under said license), but you could not use (or for that matter modify) the GPL to do so.

I suppose I should add (with respect to your FSF-based definition of free software) that icedax in cdrkit (GPLv2) would probably suffice as well as cdda2wav in cdrtools (CDDL) for the purpose of warming up the drive, seeing as the former is forked from an earlier, GPL'd, codebase of the latter. The -Z flag of cdparanoia may also suffice to do warmup if you want to avoid the cdrkit vs. cdrtools issue altogether, but I haven't tested it to be sure.

Also, please don't rely on cdparanoia to correctly handle AccurateRip sample offsets equal to or greater than 512 samples in either direction (due to how it handles sample offsets). Rubyripper (or at least the version on the master branch) handles this correctly by correcting the sector offset for sample offsets greater than or equal to 512 samples. (If you have an offset of +667, for example, adjusting for this requires that you actually add one sector to the start and ending offsets of the track (i.e. you'll need to use sector-based ripping rather than track-based ripping), and then assume an offset of +667 % 512 = +155 samples). cdparanoia also can't read into the lead-out of a CD even if the drive ostensibly supports it, so you'll have to manually add some empty samples to the end of your file if you have a positive offset.

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

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 something (effectively ripping at 2x, 4x at BEST).

Now these drives do have something called "RipLock" to limit the ripping speed of DVDs and Blu-Rays, but this feature ostensibly doesn't affect CD ripping. What I eventually learned, however, is that the LG/Hitachi (HL-ST-DT) drives which make up the majority of DVD drives out on the market today actually do not have a firmware which plays well with the way that cdparanoia does its ripping and error checking. It turns out that HL-ST-DT drives actually read at a slower speed until they have read enough sequential sectors (about 30 seconds of audio), at which point they will actually speed up to full speed and stay at that speed.

Thus, my solution to the slow-ripping problem was to actually use cdda2wav in non-paranoia mode (so as to read sequential sectors) to read the first 30 seconds of the CD audio so as to warm up the drive speed. Once this is done, I can then run cdparanoia as before, and actually can rip at a reasonable rate.

Of course this isn't to say that the HL-ST-DT drives are very good. They've got a pretty big sample offset (+667) and actually have a pretty bad successful rip rate (closer to 90% instead of 97 or 98%). The best investment I've made so far is to buy a Plextor PX-716UF, which I use to rerip CDs that don't rip right on the HL-ST-DT drive. By doing this, I've probably managed to eliminate 4 out of every 5 "bad" rips; the only remaining "bad" rips are from obviously physically damaged discs (cracks, pitting, etc.), which I consider a pretty good hit rate. Of course the only downside of these drives is that they don't play well with the DVD-side of dual-discs.

Yep, you heard me right: old Plextor drives STILL can't be beat in rip quality with practically any drive out today. (But make sure you get an old one, not one of the newer ones that's just a rebranded Hitachi that claims to be a Plextor. Basically, any Plextor with a rip offset of +30 is good, but you might also want to refer to the Plextors on this list)

That's pretty much my interpretation of the issue. I've never seen anything that said that the Commission could be ordered around by the Parliament, and since the Commission is the only EU governing body with legislative initiative, all they have to do is keep proposing the ratification of ACTA until the Parliament caves. And even then, the individual member states could ratify ACTA without the EU doing so anyway...

Having been a student at BOTH in the past couple of years, I safely say that they now no longer seem to explicitly use SSN as student ID. Which isn't to say that they don't hold it in storage in some Bursars/Registrars Office database, but both now appear to use proprietary 9 digit numbers instead of SSNs for most purposes.

That's nothing new with Verizon. Heck, they've been crippling Bluetooth for ages.

It's a heck of a lot easier to shout non-unique names to identify someone though in most situations... I mean, I'm pretty sure no one wants to have to yell at their kid "76995cdc-9825-4b13-b66a-a60b26b6cc41! Stop drawing on the wall!"