Totally confused by CueTools, Perfect Tunes and Accurate Rip

[Saul Bellow]

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.

[Spoon]

Re: Totally confused by CueTools, Perfect Tunes and Accurate Rip

Cuetools has its own database so the results shown here can be from that and not AccurateRip.

If you click export on PerfectTUNES accuraterip and grab the relevant disc from the list and post here, we can comment on that.

[Saul Bellow]

Re: Totally confused by CueTools, Perfect Tunes and Accurate Rip

Ok, how can I find out what the differs in samples thing means then?

With Perfect Tunes, it delivers a different checksum for the third track to the checksum recorded in the log file. It still says Accurately Ripped but the checksum isn't the same as was recorded in the log. Both are for AR2, incidentally.

Also, Perfect Tunes gives a separate pressing offset for that track compared to the other tracks on the same disc.

[Spoon]

Re: Totally confused by CueTools, Perfect Tunes and Accurate Rip

Samples is not related to AccurateRip, try the Cuetools support forum.

I would need to see the perfecttunes log to be certain.

[Saul Bellow]

Re: Totally confused by CueTools, Perfect Tunes and Accurate Rip

Samples is not related to AccurateRip, try the Cuetools support forum.

I would need to see the perfecttunes log to be certain.

First, the original report from EAC after ripping:


Read mode : Secure
Utilize accurate stream : Yes
Defeat audio cache : No
Make use of C2 pointers : No

Read offset correction : 103
Overread into Lead-In and Lead-Out : No
Fill up missing offset samples with silence : Yes
Delete leading and trailing silent blocks : No
Null samples used in CRC calculations : Yes
Used interface : Native Win32 interface for Win NT & 2000
Gap handling : Appended to previous track

Used output format : User Defined Encoder
Selected bitrate : 1024 kBit/s
Quality : High
Add ID3 tag : No
Command line compressor : C:\Program Files (x86)\Exact Audio Copy\Flac\flac.exe
Additional command line options : -V -5 -T "artist=%artist%" -T "title=%title%" -T "album=%albumtitle%" -T "date=%year%" -T "tracknumber=%tracknr%" -T "genre=%genre%" -T "ALBUMARTIST=%albuminterpret%" -T "COMMENT=%comment%" -T "COMPOSER=%composer%" %hascover%--picture="%coverfile%"%hascover% %source%


TOC of the extracted CD

Track | Start | Length | Start sector | End sector
---------------------------------------------------------
1 | 0:00.32 | 24:15.00 | 32 | 109156
2 | 24:15.32 | 14:49.00 | 109157 | 175831
3 | 39:04.32 | 12:39.00 | 175832 | 232756


Track 1

Pre-gap length 0:00:02.42

Peak level 99.9 %
Extraction speed 5.4 X
Track quality 100.0 %
Copy CRC 8E69BEBA
Accurately ripped (confidence 35) [B9462BE0] (AR v2)
Copy OK

Track 2

Peak level 96.1 %
Extraction speed 7.3 X
Track quality 100.0 %
Copy CRC 8DDFF2A8
Accurately ripped (confidence 35) [1A8F4B33] (AR v2)
Copy OK

Track 3

Peak level 99.9 %
Extraction speed 8.3 X
Track quality 100.0 %
Copy CRC 7392B727
Accurately ripped (confidence 35) [5B22DEB4] (AR v2)
Copy OK

All tracks accurately ripped

No errors occurred

End of status report

Now the same rip as analysed by PerfectTunes:

Track 1: AccurateRip Verified Confidence 39, Pressing Offset +0 [ARv2 CRC B9462BE0]
Track 2: AccurateRip Verified Confidence 39, Pressing Offset +0 [ARv2 CRC 1A8F4B33]
Track 3: AccurateRip Verified Confidence 39, Pressing Offset +1333 [ARv2 CRC 0D51D7F4]

Why has the third track been assigned a different checksum and why does this track have a different pressing offset to the other tracks from the same disc, ripped on the same drive?

[dbfan]

Re: Totally confused by CueTools, Perfect Tunes and Accurate Rip

It is likely that the pressing offset has the higher confidence hence why it was used.

[Saul Bellow]

Re: Totally confused by CueTools, Perfect Tunes and Accurate Rip

It is likely that the pressing offset has the higher confidence hence why it was used.

But can one track on a disc realistically have a different pressing offset to the other tracks?

Why has PerfectTunes deduced a different checksum to the original log produced by EAC?

[Spoon]

Re: Totally confused by CueTools, Perfect Tunes and Accurate Rip

It does not have a different pressing offset, what is being shown is that your copy is checked against a different pressing offset.

Different pressing offsets have different CRCs.

[Saul Bellow]

Re: Totally confused by CueTools, Perfect Tunes and Accurate Rip

It does not have a different pressing offset, what is being shown is that your copy is checked against a different pressing offset.

Different pressing offsets have different CRCs.

Does this mean that the CRC in the original log file created in EAC after ripping was wrong?

[Spoon]

Re: Totally confused by CueTools, Perfect Tunes and Accurate Rip

No, that CRC is for one pressing, the other CRC is for another pressing.

A pressing is simply data offseted by a few bytes.