Poor AdcurateRip Ratings

[ShutterShock]

I use dbPowerAmp to rip my CDs to FLAC. The vast majority of the time they fail AccurateRip. I had never paid much attention to it because I was under the impression the “accuracy” in AccurateRip related to metadata (e.g.: tags) and not to the actual integrity of the audio file. Now after doing some reading, I think I’m mistaken.

Should I be concerned? There doesn’t seem to be any perceptible impact on the audio quality when I play the "failed" FLAC files.

I keep my CDs in very good condition. I’m surprised I’m getting such a high failure rate.

[Hercules]

What sort of failure messages do you get? Any sort of log you can post?

I don't use dbpoweramp but any messages/logs may be revealing...

[bigfool1956]

Did you use a key disc to set up your drive offset. If you don't do this you will have problems matching the CRCs

[Timothy Stockman]

AccurateRip checks the 32-bit CRC of what you ripped against what others have reported on a track-by-track basis. The metadata (tags) are not ripped from the CD, but usually obtained from an online database like freedb.

In order for the CRC to match AccurateRip, it is best not only to use secure data extraction mode, but to use the proper secure gap-detection algorithm so that the file size matches exactly. This is better anyway for gapless playback of tracks which are joined on the disc. Anyway, getting the track length exactly right, to the byte, is required in order for the AccurateRip CRC to match, but the sound of the track will not be degraded if the beginning or end is not exactly in the right place. Usually the first 0.2 seconds (~10K samples, ~40K bytes) and the end of a track is silence, anyway.

I've actually EXTENSIVELY altered the Rhino "Have a Nice Day" CDs as I've ripped them, actually truncating garbage from the end of the tracks. In all cases, the song fades out to dither (-90 dBFS hiss) but many tracks have a little bit of the much higher noise floor that precedes the next track tacked onto the end of the previous track; I chop it off in the dither so I don't get this minute noise blip after the song has faded. Certainly the "cleaned up" versions would not match the AccurateRip CRC!

After getting the EAC options set right on my system, AccurateRip reported much higher success. Still not perfect, but I feel that the "different pressing" message may refer to the 1630 at the pressing plant did not play back exactly the same bits when a subsequent glass master was cut. So CDs from different glass masters may in fact not be exactly the same even though they came from the same 1630 format digital master tape. I don't think they use 1630s much anymore. One engineer who used to work at Atlantic records has said "1630 and reliable are not words I would use in the same sentence".

Bottom line, if EAC reports "no errors" in secure mode, in just about all cases it does mean that there were no errors which would affect the audio quality, but if AccurateRip then complains the file is most likely different in some insignificant way. I believe EAC; to me AccurateRip is just "icing on the cake" because it shows the file is identical even in insignificant ways.

[ShutterShock]

I did some quick reading on EAC (hadn't heard of it before). From a workflow perspective I'm not sure how EAC fits in. Is it a replacement for dbPowerAmp, or is it a plug-in?

Also, as I mentioned, there's no perceptible sound quality degradation. Am I worrying over nothing?

Thanks for all the helpful posts.

[bigfool1956]

If you are using secure mode in dBpoweramp, and it reports a difference to to Accuraterip, then I wouldn't worry too much about it, especially if the confidence level (i.e. the number shown on the screen) is one.

Also, if you have a different pressing it often will not match the entries in Accuraterip. CDR copies of CDs frequently don't rip to the same CRC as stored in Accuraterip too.

What I like about dBp is the way it will abort secure mode if it finds a match with AR in any pass, without the user having to think about it. This means that often a disc will rip at burst speed, and you are sure that the quality of the rip is good.

You can do this with EAC too, but to my mind it is more of a faff.

[Mark Lanctot]

I did some quick reading on EAC (hadn't heard of it before). From a workflow perspective I'm not sure how EAC fits in. Is it a replacement for dbPowerAmp, or is it a plug-in?

It's another ripper like dBpowerAMP. I'm starting to see two diehard camps - EAC and dBpowerAMP. It's the beginning of a new religious war. :-)

Personally I'm in the EAC camp.

Oh and keep in mind that the majority of CDs in the AccurateRip database are from US pressing plants. If you live outside of the US, laws may dictate that CDs have to be pressed locally (this is the case in Canada) and the pressing may not match the one in the AR database.

You can tell this if *every single* track on a CD doesn't match. Even on a damaged disc, the odds are one of them will if the CD is in the AR database. The AR software usually indicates this with a "Your CD appears to be a different pressing" comment or something similar.

[bigfool1956]

The ripper wars! Could even be a movie.

Actually I think both EAC and dBpoweramp are excellent programs. I have a personal preference for dBp having tried both, enough that I was prepared to pay for it. I wouldn't sacrifice a goat to it though!

[maggior]

It's interesting to see this new religeous war starting. I recently purchased dbPowerAmp for its transcoding prowess. I like that fact that it will allow me to delete the source file once trancoding has been done on a file. I don't know of any other general purpose transcoders that will do this. The GUI is also extremely intuitive. I like the batch mode and how it reports errors on input files.

I'm an EAC user and have been using it for the last 7 years (wow, it's been that long!). I tried the dbPowerAmp ripper and it looks really good. The AMG integration is pretty cool. But, I've been using EAC for so long and it works for me, so I'm continuing to use it.

One area of difference that I noticed was with ripping to non-WAV formats. If you rip directly to something other than WAV (e.g. FLAC), EAC has a great mechanism for encoding on the fly. It will encode in the background while conintuing to rip the disc. You can even put in a new disc while encoding of the previous one completes. Even if the PC crashes (which has happened to me), EAC remembers what it was doing and will pick up where it left off when the machine comes back up.

I think it basically comes down to personal preference.