Skip to main content
Topic: CueTools/Accurip numbers different after burning? (Read 736 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

CueTools/Accurip numbers different after burning?

So, when testing a rip with CueTools, it returns this:
[AccurateRip ID: 001adea3-011eb7ec-e40ceb0f] found.
Track   [  CRC   |   V2   ] Status
 01     [bbbf8c36|60020b7b] (060+108/187) Accurately ripped
 02     [1182adb6|ecde2c0d] (060+107/186) Accurately ripped
 03     [591ab1da|1fa8b649] (060+110/189) Accurately ripped
 04     [09e6915b|8c73f985] (060+109/188) Accurately ripped
 05     [2465d80f|d5830218] (059+109/187) Accurately ripped
 06     [29848002|db5d692b] (061+110/190) Accurately ripped
 07     [3b29272f|429e2f04] (060+108/187) Accurately ripped
 08     [82b48506|f7b637fb] (060+108/187) Accurately ripped
 09     [1a7fc073|4b17cb3e] (060+109/188) Accurately ripped
 10     [22b49998|28a8c729] (060+110/189) Accurately ripped
 11     [94e2ca5b|ea2e54ea] (060+109/188) Accurately ripped
 12     [9fa24f0c|feabcf6d] (060+109/188) Accurately ripped
 13     [82ee0ceb|6dde67e2] (061+109/189) Accurately ripped
 14     [72e03391|4c0b02ea] (060+109/186) Accurately ripped

When I burn the rip to disk, returns this (see attached):

And when verifying again in CueTools, I get this:
[AccurateRip ID: 001a9797-011a8e38-d60bf80e] found.
Track   [  CRC   |   V2   ] Status
 01     [bbbf8c36|60020b7b] (02+06/11) Accurately ripped
 02     [1182adb6|ecde2c0d] (00+06/09) Accurately ripped
 03     [591ab1da|1fa8b649] (02+06/11) Accurately ripped
 04     [09e6915b|8c73f985] (02+06/11) Accurately ripped
 05     [2465d80f|d5830218] (02+06/11) Accurately ripped
 06     [29848002|db5d692b] (02+06/11) Accurately ripped
 07     [3b29272f|429e2f04] (02+06/11) Accurately ripped
 08     [82b48506|f7b637fb] (02+06/11) Accurately ripped
 09     [1a7fc073|4b17cb3e] (02+06/11) Accurately ripped
 10     [22b49998|28a8c729] (02+06/11) Accurately ripped
 11     [94e2ca5b|ea2e54ea] (02+06/11) Accurately ripped
 12     [9fa24f0c|feabcf6d] (02+06/11) Accurately ripped
 13     [82ee0ceb|6dde67e2] (02+06/11) Accurately ripped
 14     [72e03391|4c0b02ea] (02+06/11) Accurately ripped

What gives?
I know my offset in EAC is correct. Why the different Accurip return?
Thanks for any help.

Re: CueTools/Accurip numbers different after burning?

Reply #1
Both ripping and recording have their own offsets, which both depend on the drive model and firmware. Just because you got the rip offset correct, does not mean that you have gotten the recording offset correct.

To find your device's recording offset, if it isn't already in a database, you need a correct rip offset, and you need to record a test disk, so the ripping software can record it, then read it back, to determine the recording offset. It is important to know the rip offset in advance for this, as it will affect the result returned when reading it back in addition to the recording offset.

Re: CueTools/Accurip numbers different after burning?

Reply #2
AccurateRip IDs don't match
[AccurateRip ID: 001adea3-011eb7ec-e40ceb0f] 0f= 15 tracks
[AccurateRip ID: 001a9797-011a8e38-d60bf80e] 0e= 14 tracks

I'd like to see the CTDB TOCIDs
korth

Re: CueTools/Accurip numbers different after burning?

Reply #3
The "Essential Alison Krauss" CD has a data track.
High Voltage socket-nose-avatar


Re: CueTools/Accurip numbers different after burning?

Reply #5
Sorry for not getting back sooner. So is there any way to burn the tracks in example 1 (001adea3-011eb7ec-e40ceb0f) and be able to get the same result after burning? Don't have original cue or log file, unfortunately.

 

Re: CueTools/Accurip numbers different after burning?

Reply #6
Ripping software, e.g. EAC[1], will detect that the data track exists on the original CD but will only rip the audio portion so the CDR burned from that rip will only contain the audio portion. Even if you did create a multi-session CD to preserve the data track, the start position of the second session likely won't be the same as the original CD.
When EAC detects a data track, it is included in the calculation of the CDDB in the REM DISCID line of CUE and the TOC of the extracted CD in the extraction logfile. CUETools uses this info to calculate the correct AccurateRip ID.
When verifying the original rip with CUETools, the layout of the original TOC and AccurateRip ID can be preserved in the metadata so later if you no longer have the CUE and LOG, CUETools will be able to use the original layout when re-verifying the rip.
http://cue.tools/wiki/CUETools_Advanced_Settings:_AccurateRip#Verify
http://cue.tools/wiki/CUETools_Advanced_Settings:_Advanced#Tagging

You didn't post the full CUETools log for the original rip. There should be a line near the top that says something like
CD-Extra data track length 01:30:38

For CUETools to calculate the original AccurateRip ID when verifying the CDR rip
You can enter the data track length in the Extra: Data track box before you verify
or
You can change REM DISCID D60BF80E to REM DISCID E40CEb0F in the CUE.

Note: I'm running late. I'll pick this up later.
I refer to recent versions of EAC in this post and do not imply the same for all previous versions.
korth

Re: CueTools/Accurip numbers different after burning?

Reply #7
AccurateRip ID calculation requires more information than just changing the DISCID. Fortunately the CTDB stores AccurateRip IDs associated with rips in its database. So CUETools will need to contact the CTDB and a version of the CD must already exist in the database for the 'change DISCID' method to work.

If all you have is a burned CDR (no original files, no CUE, no LOGs and the original CD is packed away somewhere) and the AccurateRip result doesn't seem right, CUETools can let you know if other variants of the CD exist in the CTDB. You would need to enable the CTDB Detailed log. Note: There was an issue (caused by a bugfix for another issue) that blanked out the CD-Extra data track length information in some situations. Also the extra details can be confusing so I don't recommend leaving this setting enabled for everyday use.

Also be aware that the local database and settings can interfere with re-verifying rips. You may need to delete the previous entry before you'll get a new result.
korth

 
SimplePortal 1.0.0 RC1 © 2008-2019