title
Products            Buy            Support Forum            Professional            About            Codec Central
 
Results 1 to 10 of 10

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

  1. #1

    Totally confused by CueTools, Perfect Tunes and Accurate Rip

    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.

  2. #2
    Administrator
    Join Date
    Apr 2002
    Posts
    40,616

    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.

  3. #3

    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.

  4. #4
    Administrator
    Join Date
    Apr 2002
    Posts
    40,616

    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.

  5. #5

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

    Quote Originally Posted by Spoon View Post
    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?
    Last edited by Saul Bellow; 10-14-2015 at 01:50 PM.

  6. #6
    dBpoweramp Guru
    Join Date
    Jan 2011
    Posts
    937

    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.

  7. #7

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

    Quote Originally Posted by ********* View Post
    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?

  8. #8
    Administrator
    Join Date
    Apr 2002
    Posts
    40,616

    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.

  9. #9

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

    Quote Originally Posted by Spoon View Post
    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?

  10. #10
    Administrator
    Join Date
    Apr 2002
    Posts
    40,616

    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •