Yes. Something is wrong with XLD's automatic AccurateRip check.
Here is a rip at the correct drive offset of 48:
X Lossless Decoder version 20080916b (91.2)
XLD extraction logfile from 2008-09-16 05:45:58 -0500
CAN / Ege Bamyasi
Used drive : PIONEER DVD-RW DVR-108 (revision 1.17)
Use cdparanoia mode : YES (CDParanoia III 10.2 engine)
Disable audio cache : YES (1/14)
Read offset correction : 48
Max retry count : 100
TOC of the extracted CD
Track | Start | Length | Start sector | End sector
---------------------------------------------------------
1 | 00:00:32 | 09:29:38 | 32 | 42744
2 | 09:29:70 | 04:47:37 | 42745 | 64306
3 | 14:17:32 | 05:35:50 | 64307 | 89481
4 | 19:53:07 | 03:32:13 | 89482 | 105394
5 | 23:25:20 | 10:31:62 | 105395 | 152781
6 | 33:57:07 | 03:05:38 | 152782 | 166694
7 | 37:02:45 | 03:04:25 | 166695 | 180519
List of suggested offset correction values
# | Absolute | Relative | Confidence
------------------------------------------
1 | -100 | -148 | 7
Track 02
Filename : /Test 6/02 - Sing Swan Song.wav
CRC32 hash : 32D7B7E7
CRC32 hash (skip zero) : 3B74814B
AccurateRip signature : 4F050E3A
->Accurately ripped! (confidence 15)
Statistics
Read error : 0
Skipped (treated as error) : 0
Edge jitter error (maybe fixed) : 0
Atom jitter error (maybe fixed) : 0
Drift error (maybe fixed) : 0
Dropped bytes error (maybe fixed) : 0
Duplicated bytes error (maybe fixed) : 0
Track 03
Filename : /Test 6/03 - One More Night.wav
CRC32 hash : 34A884D2
CRC32 hash (skip zero) : C5E3B2DF
AccurateRip signature : 8CFAAF7B
->Accurately ripped! (confidence 16)
Statistics
Read error : 0
Skipped (treated as error) : 0
Edge jitter error (maybe fixed) : 0
Atom jitter error (maybe fixed) : 0
Drift error (maybe fixed) : 0
Dropped bytes error (maybe fixed) : 0
Duplicated bytes error (maybe fixed) : 0
No errors occurred
End of status report
Here I changed the drive offset to 49 and re-ripped, to see if the AccurateRip check feature is working:
X Lossless Decoder version 20080916b (91.2)
XLD extraction logfile from 2008-09-16 05:48:32 -0500
CAN / Ege Bamyasi
Used drive : PIONEER DVD-RW DVR-108 (revision 1.17)
Use cdparanoia mode : YES (CDParanoia III 10.2 engine)
Disable audio cache : YES (1/14)
Read offset correction : 49
Max retry count : 100
TOC of the extracted CD
Track | Start | Length | Start sector | End sector
---------------------------------------------------------
1 | 00:00:32 | 09:29:38 | 32 | 42744
2 | 09:29:70 | 04:47:37 | 42745 | 64306
3 | 14:17:32 | 05:35:50 | 64307 | 89481
4 | 19:53:07 | 03:32:13 | 89482 | 105394
5 | 23:25:20 | 10:31:62 | 105395 | 152781
6 | 33:57:07 | 03:05:38 | 152782 | 166694
7 | 37:02:45 | 03:04:25 | 166695 | 180519
List of suggested offset correction values
# | Absolute | Relative | Confidence
------------------------------------------
1 | 48 | -1 | 16
2 | -100 | -149 | 7
Track 02
Filename : /Test 5/02 - Sing Swan Song.wav
CRC32 hash : CEAE0E0C
CRC32 hash (skip zero) : 77CD99FF
AccurateRip signature : 7AB73CDF
->Accurately ripped! (confidence 15)
(matched with the different offset correction value;
calculated using an additional offset of -1)
Statistics
Read error : 0
Skipped (treated as error) : 0
Edge jitter error (maybe fixed) : 0
Atom jitter error (maybe fixed) : 0
Drift error (maybe fixed) : 0
Dropped bytes error (maybe fixed) : 0
Duplicated bytes error (maybe fixed) : 0
Track 03
Filename : /Test 5/03 - One More Night.wav
CRC32 hash : 06E2DC29
CRC32 hash (skip zero) : 79098D2F
AccurateRip signature : 5D7A2D6E
->Accurately ripped! (confidence 16)
(matched with the different offset correction value;
calculated using an additional offset of -1)
Statistics
Read error : 0
Skipped (treated as error) : 0
Edge jitter error (maybe fixed) : 0
Atom jitter error (maybe fixed) : 0
Drift error (maybe fixed) : 0
Dropped bytes error (maybe fixed) : 0
Duplicated bytes error (maybe fixed) : 0
No errors occurred
End of status report
The CRCs are different because the tracks were ripped using different offsets. This part is correct.
Here's the problem: the second log says that the tracks "matched with the different offset correction value; calculated using an additional offset of -1." This seems correct, but the AccurateRip signatures in the second log are completely different from the ones in the first log. They should be the same.
What causes the different AccurateRip signatures in the second log? This makes no sense.
First log:
Track 02 - AccurateRip signature : 4F050E3A
Track 03 - AccurateRip signature : 8CFAAF7B
Second log:
Track 02 - AccurateRip signature : 7AB73CDF
Track 03 - AccurateRip signature : 5D7A2D6E