Slashdot Mirror

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

There is no such thing as a "direct digital rip". The CD standard doesn't provide one, there are no boundaries on the CD for one to work against, and as stated rip jitter is inevitable. The only question is how the software and hardware involved handle it. The post you were objecting to talks about one of the pieces of the magic used to help with this fundamental problem that you're not aware of, and there are some others too.

Drives that support what's called AccurateStream will guarantee you that they always pick the same spot every time you ask it to seek somewhere, which is the first part of the problem. If you drive doesn't do that, you end up needing to do the overlapping read shuffle described above to figure that out. See EAC Drive Options for more about all that.

Even if you have AccurateStream, there's a second problem: the spot will be the same every time, but exactly where that is can't be guaranteed--it varies based on the drive model. The way AccurateRip copes with this problem to collect a database of CD Drive Offsets. If your drive isn't in their database, what you can do is use a known music CD that AccurateRip has good data on, then calibrate your drive using it to figure out how much you're off by. People submitting those test results is how they compiled the database.

If you have AccurateStream hardware, and you know your drive offset, you can get the same rip every time and match against the checksums that AccurateRip provides. But this is only happening because several pieces of the chain know how to compensate for the limitations of audio CDs encoding, there is no way to get digital data straight off of them usefully.

It's because he didn't use a proper ripping program like EAC. Who else is http://www.accuraterip.com/ able to verify my rips with other users if they are all different then? The hashes for my rips match the ones in that database when the CD is ripped properly.

Not if you use EAC (exact audio copy) in secure mode. The whole point of using EAC in secure is to rip a bit-perfect copy. This is also what databases like http://www.accuraterip.com/ are for. To see if your CD was clean enough to indeed get a prefect rip. The only way it's not going to be perfect is if your disk is too scratched.

I my friend and I both buy the same pressing of a CD and rip using EAC in secure mode its almost guaranteed we will have bit-identical copies.

Different drives have a different read offset. I'd assume release groups would compensate for this properly, but if you haven't configured your ripping software correctly the hash might be enough to identify the drive it was ripped on:

http://www.accuraterip.com/driveoffsets.htm

Check out this wiki for more info on Secure Ripping, how EAC works and how to use it correctly. In conjunction with AccurateRip, you can confirm if a rip was perfect.

Must it be so?

The cheap-shit CCD in my $6 optical mouse seems to do quite well enough at what it is intended to do that I simply cannot assume that it is impossible to build a CCD suitable for reading vinyl records when given a substantially larger budget. Reading a vinyl groove to a specified resolution is a process composed of difficult but obvious and finite problems, and therefore the hardware to do so must be possible to produce at some point.

Also, in this age of very inexpensive and vast storage, there is no particularly pressing need to have the device operate in real-time, which would permit the software side of things to spend more time dealing with surface contamination or damage.

There's still a lot of material out there that only exists on vinyl and acetate platters. The easier it is to transfer and archive that material, the more likely it is that someone at some point might actually take the time to do it.

(I write this as EAC patiently rips a slightly-abused, 15-year-old CD at a leisurely 0.5x, carefully producing verified accurate data without any help from me. But my CD collection is relatively small and mostly replaceable. The world's analog recordings are a different story...)

Actualy, you can reliably checksum the audio data on redbook.. you do need to do a little more work.. but this could easily be automated.

Unfortunately, I have not found a linux implementation of this yet.

http://www.accuraterip.com/

I encode in FLAC when I borrow CDs, or have a beat-up CD I can get a good extraction from (I use Exact Audio Copy with AccurateRip).

Most modern optical drives have AccurateStream, which afaik nullifies this problem. What you're left with is the offset to start reading from, which you need to check with key disks who's offsets are known if you don't know the offset for your drive. Not doing this *will* result in your ripped tracks having parts truncated or prepended, whether you can tell or not. AccurateRip is a good tool to do this, since it checks checksums from your ripped data with those other users have uploaded.

In quality terms, it doesn't get any better than EAC. (Unfortunate, and some of us are working on bringing CDex up to that standard.)

There's a Standard for using that to make very, very good rips that should be indistinguishable from the original to just about anyone's ears and beat the pants off anything from Kazaa or even 192kbps FastEnc CBR "scene releases" from Usenet or IRC. I won't tell you the exact name of the standard. Rumour has it there are least three private networks, probably more, dedicated to it, but I don't know the details - only how you can get your own rips to sound great so you can put your CDs away safely and never have to get them out again:

• Rip with Exact Audio Copy 0.9 beta 4 (not the prebetas, they're broken). We've tested and nothing else as good, even cdparanoia. (Sorry, it's Windows. Either try Wine or add Secure Mode to a Free Software ripper and let Hydrogen Audio (the doom9 of audio) et al test it for a few months before you even consider using it.)
• Use Secure Mode, accurate stream, with NO C2 (even if your drive can do it), and disable the cache. (That's Secure Mode, Accurate Stream, Drive Caches Audio Data but NOT Drive is capable of retreiving C2.) Resync on track boundaries. Error Recovery Quality: High. Gap Detection Secure, Strategy any of A, B or C (try changing if you get a "protected" CD that won't rip). Speed Actual (which is usually max), allow speed reduction during extraction as many drives are more reliable reading scratched bits at lower speeds (this way it'll slow down only if it needs to, trying to read through a scratch). You may find spinning up first helps reading some CDs.
• Skip tracks on read or sync errors. You'll get clicks if you don't and you're better off cleaning the CDs than that.
• Do NOT normalise. Ever. (If you want replay gaining, let your Vorbis decoder do that on decoding, but NEVER do it before encoding!)
• On Unknown CDs, automatically access online freedb database. There are sometimes errors, so crosscheck the titles with the case - for correct year and genre, use Allmusic - it's right more often than you are.
• Create an m3u on extraction, and start 1 compressor queued in the background (with no window, after you've got it working) for each processor in your machine, plus 1 if you're hyperthreaded (I use 5). Remember not to close EAC until after there are no files queued for encoding!
• For the naming scheme, use: %A - %C\%A - %C - %N - %T for normal albums. Use a Various Artists scheme too: %C\%C - %N - %A - %T - on CDs with Various Artists, check the Various box in the info at the top and make sure the track titles have a form Artist / Title, so, let's say, Madonna / What The Fuck Do You Think You're Doing :-). This way the names will all come out right. It also ensures that peer-to-peer programs which don't grok directories (most of them) will get the artist, album, and track number.
• Always write a log file. It'll be named after the album, that's the only drawback. Move it into the folder and use a script to rename it or something (I know of three competing ones but won't name them here).
• If you're feeling daring, calibrate your drive's read offset with AccurateRip (don't use that for ripping, though), and enter that offset into EAC (mine is a +12). If your drive can overread leadin AND leadout (get EAC to test that with detect read offset - you can get the read offset with that too, but it is more likely to give false readings than AccurateRip due to an inferior reference CD database), use that, if it can't overread BOTH, do NOT select that option (you'll get garbage). If you calibrate your read offset, use it, otherwise set it to 0. Don't use a combined offset.
• Encode to EITHER FLAC (for lossless, generation-copy free rips) OR Ogg Vorbis 20020717 (1.0) using quality 6.0 or greater (192kbps nominal), 8.0 highly