Are reliably perfect audio rips impossible?

I was planning on ripping my CD collection to perfect FLAC files, but I’m starting to think this is an impossibility. I was thinking a secure ripping program like EAC or rubyripper along with a disabled drive cache, correct offset, and any necessary overreading abilities would do the trick, but now it doesn’t look like it.

According to a thread on hydrogenaudio.org:

“The idea that a re-read of a scratch will return random results is not from an understanding of how CD drives work (with various error recovery layers and possible interpolation) there is a good chance that an error will return the same each rip.”

“Drive specific issues (firmware bugs, build quality, bad design, hours in use, etc.), disc surface quality, and secure-ripping strategy all can cause you to get incorrect data read repeatedly with non-caching drives, which means that traditional “secure” rippers can be fooled.”

Is this true? If so, something like AccurateRip is actually necessary to validate a rip and it’s kind of a drag that their offset system is not quite right.

I would just use EAC with AccurateRip and use the best rip method possible.

This way you can compaire your rip to others to see if there are errors and the best extraction method will reduce the chance of errors getting into the rip meaning you have to re-rip.

Using the above you will get as perfect as is possible on a PC setup.

The problem with that is AR’s offset detection method produces the wrong offset. Even AR’s author “spoon” will readily admit this.

It’s no problem for AR’s database. The error is consistent across the database so everyone can still compare their rips. It’s also no real problem for the music because you only lose 30 samples at the end of the disc, which are almost definitely silence. The problem is that each of the ripped FLAC files are 30 samples off compared to what’s on the CD. Every FLAC file contains a checksum and I’m hoping that in the future there will be a way to compare these checksums to a database to keep track of your music collection. This has been discussed a bit on the Musicbrainz list. If the wrong offset is used, the ripped FLAC files won’t have the correct checksum.

It seems I have to make a choice between offset accuracy and AR rip verification.

I’d really like to know what anyone thinks about the above quoted portions. Is it likely that a non-caching drive will make the exact same error over two passes? I’d always read before that it was nearly impossible.

AR produced the same offset as the calculated values I have on an EAC reference disc here (made the disc using a Plextor drive because of its known offset and then used that as reference for my other drives as well as at least 6 known offset audio discs and all produce the same offset value for my drives), so for my Lite-on and Benq DW1655 AR and EAC are using the same values.

The problem with AR is that if everyone ripped using no offset then the database is wrong however most of the rips I have done (some were ripped on both drives to compaire) I have obtained the same checksum as alot of other people which seems to indicate my rip is fine and the offset AR uses is correct.

I think you are analysing things to far. Once you have obtained a correct offset rip the FLAC file should match everyone else, AR should only really be used as a guide. As long as you know the offset of your drive then the rip will be perfect for you. If you want to get all the audio you will need a drive that can overread into the lead-in and lead-out which are very rare.

EAC gets around the caching drive by reading in blocks. Each block is bigger than the cache size so that the data is not read back from the cache each time and is actually read from the disc.

Believe it or not (I was very surprised), PlexTools uses the same incorrect offset calculating method that EAC/AR does. That’s why they matched in your test. AR’s author “spoon” confirmed this recently on hydrogenaudio.com. I can find the post if you’d like to see it.

Don’t Plextor drives overread as necessary?

Welcome to the forum :)[QUOTE=ggking7;2080843]“The idea that a re-read of a scratch will return random results is not from an understanding of how CD drives work (with various error recovery layers and possible interpolation) there is a good chance that an error will return the same each rip.”

“Drive specific issues (firmware bugs, build quality, bad design, hours in use, etc.), disc surface quality, and secure-ripping strategy all can cause you to get incorrect data read repeatedly with non-caching drives, which means that traditional “secure” rippers can be fooled.”[/quote]This is correct, in theory. Now the thing is, it hasn’t been proven (AFAIK) that a test & copy can fool you by returning twice the same error thus making you believe the rip is good though it’s not. I mean, I want an actual case, and a proof. People like to theorize a lot for the sake of it.

And I don’t understand this irrational fear about “possibly non 100% perfect” audio rips. The funny thing is, most people can’t even hear the vast majority of ripping errors that are not from huge disc defects. Picky ears will notice small artifacts, but many EAC users have trained ears, and the most picky of us are perfectly happy with the “test & copy” method. Two passes with matching CRCs, while not 100% secure in theory (as in the explanation you quote), still offers such peace of mind that I don’t ask for more. Those who are not happy with this method “because an error could still happen in theory” are IMO so obsessive that it’s close to paranoia.

Find me someone who demonstrated that a “test & copy” with EAC lead to an audible error despite correct CRC check, and I’ll start (maybe) to give the topic some attention. Until then, I treat it as useless conjectures.

So to your original question: are reliably perfect audio rips impossible? I guess the answer is yes, they’re impossible if you ask for perfection 100% of the time. That’s a limitation of the audio CD format and its error correction method. But who cares, since the odds of a glitch are so small, so close to null, when using proper methods like test & copy, good reader, no disc cache? :confused:

About offsets: what’s wrong with the online offset databases? :slight_smile:

Relax, enjoy the music. :cool: