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.
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.
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
The "Essential Alison Krauss" CD has a data track. (http://www.freedb.org/freedb/country/e40ceb0f)
CTDB TOCID for both uFLBt4S.1Zv8QFtJlgESSzUsi_o- (http://db.cuetools.net/?tocid=uFLBt4S.1Zv8QFtJlgESSzUsi_o-)
http://db.cuetools.net/cd/6586210 with data track length 1:30.38
http://db.cuetools.net/cd/1386650 without data track
Edit: Porcus beat me to the data track.
http://cue.tools/wiki/CUETools#Why_AccurateRip_database_lookups_sometimes_fail
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.
Ripping software, e.g. EAC, 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 (http://cue.tools/wiki/CUETools_Settings#.2811.29_Extra_.7Bsection.7D) 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.
AccurateRip ID calculation requires more information than just changing the DISCID. Fortunately the CTDB (http://cue.tools/wiki/CUETools_Database) 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 (http://cue.tools/wiki/CUETools_Advanced_Settings:_Advanced#CTDB). Note: There was an issue (caused by a bugfix for another issue) (https://hydrogenaud.io/index.php/topic,66233.msg837616.html#msg837616) 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 (http://cue.tools/wiki/CUETools_Settings#Local_database) and settings (http://cue.tools/wiki/CUETools_Settings#.288.29_Mode_.7Bsection.7D) can interfere with re-verifying rips. You may need to delete the previous entry before you'll get a new result.