Ok. I'm bewildered and don't understand anything anymore.
If anyone can help me regain my sanity, please do!
1. First confusing thing (this is all with the same disc).
Rip A from dbpoweramp on drive A. All tracks at the time were returned as accurately ripped. I don't have a report for this but they definitely all were accurately ripped with a double figures confidence at the time.
CueTools says this about this rip:
[CTDB TOCID: CXFVr5tMgJ6KCl893bHXTXimp7Y-] found.
Track | CTDB Status
1 | (31/32) Accurately ripped, or (1/32) differs in 24599 samples @24:14:53-24:15:01
2 | (31/32) Accurately ripped, or (1/32) differs in 2232 samples @00:00:00-00:00:01,14:48:74-14:49:01
3 | (31/32) Accurately ripped, or (1/32) differs in 1779 samples @00:00:00-00:00:01
[AccurateRip ID: 0007e612-00199507-220c1f03] found.
Track [ CRC | V2 ] Status
01 [3e91bb8d|b9462be0] (0+0/5) No match
02 [49dd905e|1a8f4b33] (0+0/5) No match
03 [dfc24563|5b22deb4] (0+0/5) No match
Offsetted by 1405:
01 [7c0371d2] (0/5) No match (V2 was not tested)
02 [e457961d] (0/5) No match (V2 was not tested)
03 [1c473e49] (0/5) No match (V2 was not tested)
Track Peak [ CRC32 ] [W/O NULL]
-- 99.9 [520536D0] [D9C8E473]
01 99.9 [8E69BEBA] [18F9A10D]
02 96.1 [8DDFF2A8] [6D782BCB]
03 99.9 [7392B727] [CFFD4079]
Now, Rip B on drive B this time using EAC. This time I have the log - all tracks accurately ripped with a confidence of 35.
CueTools says this about this rip:
[CTDB TOCID: CXFVr5tMgJ6KCl893bHXTXimp7Y-] found.
Track | CTDB Status
1 | (32/32) Accurately ripped
2 | (31/32) Accurately ripped, or (1/32) differs in 26510 samples @00:00:10-00:00:33
3 | (31/32) Accurately ripped, or (1/32) differs in 2100 samples @00:00:31-00:00:33
[AccurateRip ID: 0007e692-00199646-220c1f03] found.
Track [ CRC | V2 ] Status
01 [3e91bb8d|b9462be0] (023+039/201) Accurately ripped
02 [49dd905e|1a8f4b33] (023+039/203) Accurately ripped
03 [dfc24563|5b22deb4] (023+039/205) Accurately ripped
Offsetted by 664:
01 [dc7cb212] (010/201) Accurately ripped
02 [e17e5b26] (011/203) Accurately ripped
03 [d083c8aa] (012/205) Accurately ripped
Offsetted by 1098:
01 [d83ceb7a] (018/201) Accurately ripped
02 [225e03fe] (018/203) Accurately ripped
03 [177a6236] (018/205) Accurately ripped
Offsetted by 1333:
01 [a97fb373] (021/201) Accurately ripped
02 [d9a66c85] (021/203) Accurately ripped
03 [bc4c962c] (021/205) Accurately ripped
Offsetted by 566:
01 [bb163349] (000/201) No match (V2 was not tested)
02 [49cc0a1f] (000/203) No match (V2 was not tested)
03 [b9d0fb7e] (000/205) No match (V2 was not tested)
Offsetted by 1033:
01 [3da6d339] (000/201) No match (V2 was not tested)
02 [bb59c4a7] (000/203) No match (V2 was not tested)
03 [f7fcaae4] (000/205) No match (V2 was not tested)
Track Peak [ CRC32 ] [W/O NULL] [ LOG ]
-- 99.9 [5F1E4633] [D9C8E473]
01 99.9 [8E69BEBA] [18F9A10D] CRC32
02 96.1 [8DDFF2A8] [6D782BCB] CRC32
03 99.9 [7392B727] [CFFD4079] CRC32
The checksums CueTools has found for each rip (of the same disc, of course) are the same, but the results are different. Most weirdly, the first track of Rip B gets 32/32 from CueTools, but the first track in Rip A only gets 31/32 with 1/32 differing in samples.
How can Rip B match all 32 in the database while Rip A only matches 31 because the 32nd is slightly different?
How can the software recognise the same Accurate Rip checksums for Rip A and Rip B but differ in the number of matches?
Another weird thing is that, for Rip B, Perfect Tunes finds a completely different offset for the third track to the first two and comes up with a different AR2 checksum to the original log's AR2 checksum.
What does this mean?
I would have assumed that if you get a confident AccurateRip result for a disc in dbpoweramp or EAC that means you have an accurate rip, but when other software returns different results, I'm not so sure.