Two rips from same CD, AR signatures match, CRC32 hashes don't

[GoogleCodeExporter]

What steps will reproduce the problem?
1. I've ripped the same CD twice
2. All tracks accurately ripped in both rips (so I get the same AR signatures 
for all tracks)
3. CRC32 hashes from only the last track are different

How about the reproducibility (always, sometimes, rarely, ...)?
always

What is the expected output? What do you see instead?
I expect the AR signatures to be different, if the CRC32 hashes are different.

What version of the product are you using? On what operating system?
XLD version 20141129 (148.1) on Mac OS X Mountain Lion

Please provide any additional information below.
When ripping the same CD twice I get identical results, except the last track 
has different CRC32 hashes, while the AR signatures (both v1 and v2) are the 
same! Does the AR algorithm take into account a different part of the audio 
data?
FYI: I've also converted both last tracks to PCM (little endian) using XLD to 
get the raw audio data for both, then compared both files using HexFiend and it 
finds a difference all the way at the end of the file.

Original issue reported on code.google.com by lennartg...@gmail.com on 8 Mar 2015 at 4:19

[GoogleCodeExporter]

Different CD drive has a different offset value, so it always makes a 
difference at the beginning or end of the resulting file. To avoid this, 
calculation of the AR hash ignores first and last 5 sectors.

In other word, AccurateRip cannot detect errors in the first/last 5 sectors.

Original comment by tmkkmac on 8 Mar 2015 at 4:32

[GoogleCodeExporter]

Both rips were indeed done with different drives. Does this mean that the CRC32 
of the last track will always be different between different drives? Even when 
both are correctly offset corrected in XLD settings?

Original comment by lennartg...@gmail.com on 8 Mar 2015 at 4:57

[GoogleCodeExporter]

A positive offset correction value adds zero padding at the end. A negative 
offset correction value adds zero padding at the beginning.

Your result means that both drives have positive, but different offset 
correction values.

Original comment by tmkkmac on 8 Mar 2015 at 5:35

[GoogleCodeExporter]

Drive 1: offset +102
Drive 2: offset +667

So if I understand it correctly it goes like this:
Drive 1 was able to read a portion of the disc that Drive 2 couldn't read 
(unable to overread) because its offset is too large.
The non-zero data Drive 1 was able to read (but Drive 2 wasn't) was then filled 
in with zeros by XLD when Drive 2 read the track.

If the data Drive 1 was able to read (but Drive 2 wasn't) would have been zeros 
in the first place, there would be no difference in the CRC32 hash.
So it depends on the disc if there's a difference or not.

Anyway, thanks for helping me understand this peculiarity.

Original comment by lennartg...@gmail.com on 8 Mar 2015 at 6:24

[GoogleCodeExporter]

Correct.

Original comment by tmkkmac on 8 Mar 2015 at 6:46

• Changed state: WontFix