Re-Rip From Copy Inaccurate In Spite Of Same CRC

[flacflac]

Hey there,

I am having some trouble understanding ACCURATE RIP's method of detecting ACCURATE and INACCURATE Rips.

My purchased CD of a movie soundtrack was ripped accurately using EAC in secure mode with correct drive offsets. I burned the CD using a CUE created in EAC in "noncompliant" mode, i.e. gaps are appended to the previous track.

Using BURRRN, I created an identical copy for my car. When ripping this disc in EAC now, I get the exact same CRCs, but the ripped files are no longer ACCURATE in the AR database. Why not???

Log from Original-Rip:


Track 2

Filename C:\music\5 X 2 (2004)\5 X 2_-_02_-_Paolo Conte- Sparring Partner_-_Paolo Conte- Sparring Partner.wav

Peak level 98.8 %
Track quality 100.0 %
Test CRC 8C6545F0
Copy CRC 8C6545F0
Accurately ripped (confidence 1) [B02DF7F8]
Copy OK


Log from Copy-Rip:

Track 2

Filename C:\music\5 X 2 (2004)\5 X 2_-_02_-_Paolo Conte- Sparring Partner_-_Paolo Conte- Sparring Partner.wav

Peak level 98.8 %
Track quality 100.0 %
Test CRC 8C6545F0
Copy CRC 8C6545F0
Cannot be verified as accurate (confidence 1) [23F2A12A], AccurateRip returned [B02DF7F8]
Copy OK




Any help is gladly appreciated!

Thanks,

flacflac

[Spoon]

Re: Re-Rip From Copy Inaccurate In Spite Of Same CRC

When burning a CD you need to specify the correct write offset.

[flacflac]

Re: Re-Rip From Copy Inaccurate In Spite Of Same CRC

Hi Spoon,

thanks for your reply.


Why is it that the offset is relevant to AR? What data does the hash encompass that AR checks? (as it clearly is not equal to the one EAC goes by)

Also, do you know how I can set the offset in BURRRN?

Thank you.

flacflac

[Spoon]

Re: Re-Rip From Copy Inaccurate In Spite Of Same CRC

When you read from a CD you have a read offset, when writing you have a different offset, both have to be 100% correct for a disc to rip correctly in accurate rip.

[flacflac]

Re: Re-Rip From Copy Inaccurate In Spite Of Same CRC

Thanks, I would just like to understand why this is the case. How does AR calculate its checksum? Clearly, the ripped audio file is bit-identical to the one from the original disc.

[Spoon]

Re: Re-Rip From Copy Inaccurate In Spite Of Same CRC

>Clearly, the ripped audio file is bit-identical to the one from the original disc.

Not if it is burnt with the wrong offset, bits of data are missing.

[flacflac]

Re: Re-Rip From Copy Inaccurate In Spite Of Same CRC

>Not if it is burnt with the wrong offset, bits of data are missing

Well, these 'bits' seem to only affect AR, as the CRC is identical in both rips in EAC's logs. It is apparently not AUDIO information that's missing. If you don't know how AR calculates its checksum, please let me know, and I will look elsewhere - maybe you have an idea who could know.

Thank you.

[Spoon]

Re: Re-Rip From Copy Inaccurate In Spite Of Same CRC

EAC by default does not use NULL samples for calculating the CRC, so it is not a true CRC of the audio data.

[Rollo]

Re: Re-Rip From Copy Inaccurate In Spite Of Same CRC

When burning a CD you need to specify the correct write offset.

...and Burrrn does not support write offsets. So when burning the disc, everything is shifted a few microseconds. The resultant rip will not pass AR. However, if the disc is burned in EAC and you have the write offset properly set, the resultant rip will pass AR just fine, i.e., it is an exact copy.

And when R13 is released, with cue support, I expect the same will be able to be said regarding dBpA, at least I hope so.