Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: EAC says read offset is +667, but CUETools suggests 609; is EAC wrong? (Read 9339 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

EAC says read offset is +667, but CUETools suggests 609; is EAC wrong?

I am ripping some CD's to flac using EAC. When I setup EAC it detected the read offset of my drive based on the drive type as +667.
I had a rip with errors so I decided to try CUETools to fix it. My question is for anyone who knows about about the CUETools repair log.
It shows two sets of track lists.
The first says: Offsetted to 609. It appears to have matches in AC's database.
The second says: Offsetted to 667 but it has no matches.
Is that telling me the drive read offset as set to 667 in EAC is wrong and should be 609 instead? I looked for ways to check the offset manually but the only way I could find to do this is with accuraterip's reference CD database, my problem is although I have ten of the CD albums listed, none of them is the exact same catalogue as the ones in the database so they cant be used to test the offset value. I am in the US, I am thinking the database is made of CD's from another country. Is there any other way to determine the actual read offset of a drive ?

Here is the CUETools log file for that fix.
The CD is Etta James - Burnin' Down The House  01934-11633-2

[CUETools log; Date: 3/27/2013 9:55:14 PM; Version: 2.1.4]
CUETools DB: corrected 13 errors.
[AccurateRip ID: 001b4292-0109631f-9f110c0c] found.
Track  [  CRC  |  V2  ] Status
01    [278d9e28|411e90c1] (30+03/50) Accurately ripped
02    [8b91b62c|7f8d40ff] (31+03/51) Accurately ripped
03    [9efd7d6d|4f8fc277] (31+03/51) Accurately ripped
04    [fd8786f4|1acf4388] (30+02/49) Accurately ripped
05    [2fb9239a|79f6b6aa] (30+02/49) Accurately ripped
06    [3a16e301|3222b3c1] (30+02/49) Accurately ripped
07    [7f02e4cc|ddb7dce2] (31+02/50) Accurately ripped
08    [696bfd67|dfdb23ab] (30+02/49) Accurately ripped
09    [e300f366|24b47505] (30+02/49) Accurately ripped
10    [0879793f|d436488b] (31+03/51) Accurately ripped
11    [8bfa3a49|828d11da] (30+02/49) Accurately ripped
12    [5d4ccb2d|9a7f4991] (28+02/46) Accurately ripped
Offsetted by 609:
01    [3e7564ed] (15/50) Accurately ripped
02    [01d53230] (15/51) Accurately ripped
03    [eb2154e7] (15/51) Accurately ripped
04    [b11af343] (15/49) Accurately ripped
05    [57721b76] (15/49) Accurately ripped
06    [279704b0] (15/49) Accurately ripped
07    [dab7b242] (15/50) Accurately ripped
08    [ca990941] (15/49) Accurately ripped
09    [f6585d78] (15/49) Accurately ripped
10    [e1c7c8e0] (15/51) Accurately ripped
11    [2499e418] (15/49) Accurately ripped
12    [4eaa80a3] (14/46) Accurately ripped
Offsetted by 667:
01    [9a8433b3] (00/50) No match (V2 was not tested)
02    [040a5379] (00/51) No match (V2 was not tested)
03    [906431e8] (00/51) No match (V2 was not tested)
04    [6eb08194] (00/49) No match (V2 was not tested)
05    [c5e1542e] (00/49) No match (V2 was not tested)
06    [96c62d9d] (00/49) No match (V2 was not tested)
07    [20cb3451] (00/50) No match (V2 was not tested)
08    [487ab24f] (00/49) No match (V2 was not tested)
09    [5705b394] (00/49) No match (V2 was not tested)
10    [d1006be8] (00/51) No match (V2 was not tested)
11    [3d838461] (00/49) No match (V2 was not tested)
12    [67d33cb9] (00/46) No match (V2 was not tested)

Track Peak [ CRC32  ] [W/O NULL] [  LOG  ]
--  99.9 [2641F4CB] [7606D9E4] [CBAC9E79]
01  68.5 [406D02D0] [6C0A6493]         
02  99.9 [843179EB] [598B74D0]         
03  99.9 [1CBACC11] [D35BB47C]         
04  91.5 [058350F2] [8AA9E6C4]         
05  91.8 [0B84EFAC] [6EEC06DE]         
06  86.6 [8C09EC05] [B5B4F600]         
07  99.4 [F594BDD0] [9999F6A9]         
08  99.9 [C1EA0228] [F2FB8563]         
09  85.5 [8091671C] [3288D5AC]         
10  96.4 [48B9D3F9] [E65B8DA8]         
11  94.4 [5BF54673] [4A7CE9D0]         
12  87.0 [F3A69BD0] [CB7DEBDB]

EAC says read offset is +667, but CUETools suggests 609; is EAC wrong?

Reply #1
It shows two sets of track lists.


No, it shows THREE sets of track lists. And the first set shows that your rip is accurate and that you have set the correct offset for your drive:

[AccurateRip ID: 001b4292-0109631f-9f110c0c] found.
Track  [  CRC  |  V2  ] Status
01    [278d9e28|411e90c1] (30+03/50) Accurately ripped
02    [8b91b62c|7f8d40ff] (31+03/51) Accurately ripped
03    [9efd7d6d|4f8fc277] (31+03/51) Accurately ripped
04    [fd8786f4|1acf4388] (30+02/49) Accurately ripped
05    [2fb9239a|79f6b6aa] (30+02/49) Accurately ripped
06    [3a16e301|3222b3c1] (30+02/49) Accurately ripped
07    [7f02e4cc|ddb7dce2] (31+02/50) Accurately ripped
08    [696bfd67|dfdb23ab] (30+02/49) Accurately ripped
09    [e300f366|24b47505] (30+02/49) Accurately ripped
10    [0879793f|d436488b] (31+03/51) Accurately ripped
11    [8bfa3a49|828d11da] (30+02/49) Accurately ripped
12    [5d4ccb2d|9a7f4991] (28+02/46) Accurately ripped



EAC says read offset is +667, but CUETools suggests 609; is EAC wrong?

Reply #2
Ok I thought the first set was the result after it was fixed by CUETools, so what do the other sets of tracks in the log represent ?

EAC says read offset is +667, but CUETools suggests 609; is EAC wrong?

Reply #3
Different pressings.

+667 is an offset you see common across multiple drives. You should try another CD and see if you get a match with 667.

EAC says read offset is +667, but CUETools suggests 609; is EAC wrong?

Reply #4
Ok I thought the first set was the result after it was fixed by CUETools, so what do the other sets of tracks in the log represent ?

http://www.cuetools.net/wiki/CUETools_log

Quote
No match (V2 was not tested)[blockquote]Track starts at correct position (for that offset) but CRC doesn't match, possible ARv2 CRC matches[/blockquote] Offsetted by xxx[blockquote]ARv1 database records found under alternate offsets
Likely different pressings of the same disc [/blockquote](ARv2 is only tested at zero offset)
Note: CUETools is currently not fully compatible with AccurateRip v2.
See Pressings

korth

EAC says read offset is +667, but CUETools suggests 609; is EAC wrong?

Reply #5
Different pressings.

+667 is an offset you see common across multiple drives. You should try another CD and see if you get a match with 667.


Hmmm ok I did rip some other cd's which reported no errors, accuraterip reported confidence 2 or 3 for those ones, this means only 2 or 3 matches in the database right ? They included were some Whitney Houston CD's which I would imagine should have plenty of uploads to the database  That is another reason why I am wondering if 667 is not the correct offset, do you know how can I test to find out for sure what is the correct read offset for my drive ?

EAC says read offset is +667, but CUETools suggests 609; is EAC wrong?

Reply #6
+667 is the correct read samples offset correction for your drive.

Use EAC or dBpoweramp in conjunction with AccurateRip to determine the offset of your drive.  Do NOT rely on CUETools to determine this for you without additional confirmation.  Do NOT even attempt to use CUETools to determine or verify the offset of your drive if you don't understand how AR deals with different pressings/versions of a CD title.

EAC says read offset is +667, but CUETools suggests 609; is EAC wrong?

Reply #7
If the EAC log is showing you ARv2 confidence levels, this might explain the lower numbers. ARv1 has been around longer than ARv2.

AccurateRip will not report confidence in the EAC log until a key disc is inserted and AccurateRip is setup. During this setup, AccurateRip would have set the read offset to +667.
korth

EAC says read offset is +667, but CUETools suggests 609; is EAC wrong?

Reply #8
+667 is the correct read samples offset correction for your drive.

Use EAC or dBpoweramp in conjunction with AccurateRip.  Do NOT rely on CUETools to determine this for you without additional confirmation.  Do NOT use CUETools if you don't understand how AR deals with different pressings/versions of a CD title.


How do you know +667 is the correct read offset ? You must believe it is accurate to say all CD drives of the same make and model have the exact same read offset. Why are you so sure that is the case, are they really manufactured to such high tolerances ?

EAC says read offset is +667, but CUETools suggests 609; is EAC wrong?

Reply #9
The offset is determined by the specific chipset used (rather than the make and model).  It may be possible for different firmware versions to give different values, but this rarely happens (if ever!).

Feel free to do a little research on the subject if you don't wish to simply take my word for it.

In an alternate reality where the same make and model drive would have a different offset, AccurateRip, as it exists today, may never have gotten off the ground.

EAC says read offset is +667, but CUETools suggests 609; is EAC wrong?

Reply #10
How do you know +667 is the correct read offset ? You must believe it is accurate to say all CD drives of the same make and model have the exact same read offset. Why are you so sure that is the case, are they really manufactured to such high tolerances ?
Why are you being so incredulous specifically towards greynol as an individual? A small amount of background research on your part would show you that these figures are arrived at through multiple users submitting results of tests from their drives and collating those data with numerous other users. The same research would reveal hundreds of users who use offset correction in the various programs that support it and have no problems whatsoever with their individual drives having offsets contrary to those of others. There is plenty of information available to explain and corroborate these statements.

Besides, greynol has spent much of his time on this website discussing CD-ripping technology and is one of the most knowledgeable on the subject. You can afford to take his word for it if you don’t feel like reading up on the subject yourself.

EAC says read offset is +667, but CUETools suggests 609; is EAC wrong?

Reply #11
How do you know +667 is the correct read offset ? You must believe it is accurate to say all CD drives of the same make and model have the exact same read offset. Why are you so sure that is the case, are they really manufactured to such high tolerances ?
Why are you being so incredulous specifically towards greynol as an individual? A small amount of background research on your part would show you that these figures are arrived at through multiple users submitting results of tests from their drives and collating those data with numerous other users. The same research would reveal hundreds of users who use offset correction in the various programs that support it and have no problems whatsoever with their individual drives having offsets contrary to those of others. There is plenty of information available to explain and corroborate these statements.

Besides, greynol has spent much of his time on this website discussing CD-ripping technology and is one of the most knowledgeable on the subject. You can afford to take his word for it if you don’t feel like reading up on the subject yourself.


Because I dont take anyones word for anything without a plausible explanation, so in my reply I asked him why he believed that to be the case and he explained because the chipset defines the offset as an absolute value which sounds like a reasonable explanation that I am prepared to accept and therfore act acordingly. If you really think it proper to just take someones word for it without question, consider the NASA scientists who worked on the milti billion dollar hubble space telescope mirror, when it came to the settings on the machine that shaped the mirror, that is exactly what they all did, they all took someone elses word for it.

EAC says read offset is +667, but CUETools suggests 609; is EAC wrong?

Reply #12
I really didn't need to provide that as a reason.  What EAC detected plus a little research on your part should have been enough.

EAC says read offset is +667, but CUETools suggests 609; is EAC wrong?

Reply #13
I really didn't need to provide that as a reason.  What EAC detected plus a little research on your part should have been enough.


ok Ill explain further my reasons for asking.

The other day amongst several others I ripped a Whitney Houston Greatest hits album, EAC reported 100% No errors. Accuraterip reported the CD was accurately ripped confidence 2.

Now I find it very hard to believe, over all these years only 2 people have ripped that album in EAC without errors. Whitney Houstons greatest hits has probably been ripped thousands if not tens of thousands of times over the years by people all around the world, so when the checksum of my rip only matches 2 in the database combined with the fact CUETools offered matching rips to another CD with a different read offset correction, my way of reasoning tells me:

1) There is something not quite right about this. so maybe I should investigate if there were errors in the CD that my drives C2 error checking and EAC secure mode both missed or the read offset correction is incorrect.

2) I currently have no other way to find out if the CD does have errors,  so by a process of elimination I will investigate the other possibility first, that the read offset correction could be wrong.

3) If the read offset correction could be incorrect I could maybe find out how accurate the read offset detection is by looking up information online and asking questions about it on forums.

4) Everything I read about read offset correction and accuraterip online points back to one small list of specific CD's which are probably difficult to obtain by anyone outside the country where those CD's were manufactured. I have several of the Albums listed but none of them are recognized in the database so that leaves open the possibility, what if the assumption that all drives of the same make and model have the same offset is wrong ?

5) If that were the case what would happen in the accuraterip database ? There would be thousands of difference checksums created for every album ripped because there would be lots of people using the wrong offset to varying degrees, therfore it would be highly possible for a rip with errors to find a matching checksum amongst all those in the database. Therfore that would be a possible explanation as to how I could get only 2 matches with a rip of a very popular album so it seemed a good idea at the time to ask about that in more detail on this forum and maybe get an explanation which would allow me to discount the possibility the read offset correction could be incorrect.

EAC says read offset is +667, but CUETools suggests 609; is EAC wrong?

Reply #14
>Everything I read about read offset correction and accuraterip online points back to one small list of specific CD's which are probably difficult to obtain by anyone outside the country where those CD's were manufactured.

http://www.accuraterip.com/
Quote
Key Discs: over 1 Million

This one too:
http://www.accuraterip.com/driveoffsets.htm

You were already given the correct explanation for your findings here and in subsequent posts.

EAC says read offset is +667, but CUETools suggests 609; is EAC wrong?

Reply #15
I did already do as he suggested and try other CD's and I did get matches but like the Whitney one I mentioned, they all had a very low count of confidence matches, all less than 10,  many of them less than 5
Thanks for that link, the list I was using must be an Old List it doesnt have very many cd's on it.

Having said that, since I enabled the CUETools plugin, I'm not sure how I did that, CUETools report wasnt in my earlier logs but now it is anyway.. I get very different results from the CUETools database.
Confidence only 3 from accuraterip while CUETools reports 227 matches out of 229 entries, I think thats what it means, any idea why accuraterip reports only 3 or have I got it all wrong and the lower the number the better the confidence ? Maybe it means only 3 did not match ?

    Filename H:\Music\Annie Lennox\Diva\Annie Lennox - Diva.wav

    Peak level 99.2 %
    Extraction speed 15.9 X
    Range quality 100.0 %
    Test CRC 8E2117E7
    Copy CRC 8E2117E7
    Copy OK

No errors occurred


AccurateRip summary

Track  1  accurately ripped (confidence 3)  [BB21645C]  (AR v2)
Track  2  accurately ripped (confidence 3)  [7177EC54]  (AR v2)
Track  3  accurately ripped (confidence 3)  [36D52515]  (AR v2)
Track  4  accurately ripped (confidence 3)  [02CAD076]  (AR v2)
Track  5  accurately ripped (confidence 3)  [7274B2B9]  (AR v2)
Track  6  accurately ripped (confidence 3)  [D748F204]  (AR v2)
Track  7  accurately ripped (confidence 3)  [A73FEA3E]  (AR v2)
Track  8  accurately ripped (confidence 3)  [8CF54809]  (AR v2)
Track  9  accurately ripped (confidence 3)  [1401B48C]  (AR v2)
Track 10  accurately ripped (confidence 3)  [88988611]  (AR v2)
Track 11  accurately ripped (confidence 3)  [3EEB0325]  (AR v2)

All tracks accurately ripped

End of status report

---- CUETools DB Plugin V2.1.3

[CTDB TOCID: 6VtW7uXjcxDhpLAtZ8DwGHQi440-] found, Submit result: 6VtW7uXjcxDhpLAtZ8DwGHQi440- has been confirmed
[91a93889] (227/229) Accurately ripped
[961ad5ac] (001/229) No match
[71bf71ae] (001/229) No match

EAC says read offset is +667, but CUETools suggests 609; is EAC wrong?

Reply #16
Yes that is a very old list.

That method of determining your drive's read samples offset correction was made obsolete some 10 years ago.

Besides the suggestion of finding agreeing results (which in hindsight was probably not good advice for you), there was some mention about pressings which was echoed in additional posts.  Research into this would hopefully have steered you away from the idea that drives cannot be relied upon to rip with a constant and consistent offset.

 

EAC says read offset is +667, but CUETools suggests 609; is EAC wrong?

Reply #17
Confidence only 3 from accuraterip while CUETools reports 227 matches out of 229 entries, I think thats what it means, any idea why accuraterip reports only 3 or have I got it all wrong and the lower the number the better the confidence ? Maybe it means only 3 did not match ?

These questions are no longer on-topic.

Before starting a new topic asking questions that have been answered literally scores of times, please review the links given by korth and search the forum.

This thread will now close.