My question is simply "What, specifically does the confidence level in a rip log mean?" I have searched the FAQ exhaustively, but have been unable to find the solution. I've seen some logs posted with, for example, 3/35, and others with just a single number such as 7. My logs only give me a single number. So do I want a high number or a low number. How do I know if everyone else's results agree with mine. When I tried the Accuraterip link from the FAQ it takes me to the page listing drive offsets. Is there a help menu for Accuraterip? Thanks for any help.
My question is simply "What, specifically does the confidence level in a rip log mean?" I have searched the FAQ exhaustively, but have been unable to find the solution. I've seen some logs posted with, for example, 3/35, and others with just a single number such as 7. My logs only give me a single number. So do I want a high number or a low number. How do I know if everyone else's results agree with mine. When I tried the Accuraterip link from the FAQ it takes me to the page listing drive offsets. Is there a help menu for Accuraterip? Thanks for any help.
I am not an Accuraterip expert by any means but my understanding is that the (single) number is the count of entries in the Accuraterip database that had the same checksum your ripping program computed. So a higher number would mean that more people have the same checksum that you got giving you a "higher" confidence. Though you might also get a low number which could mean that not many people have ripped the same tracks yet. The count itself isn't the primary indicator. It is of interest when your checksum doesn't agree with the one returned by Accuraterip. For example, if your checksum doesn't agree and the accuraterip count is high you can have a high(er) confidence that yours is wrong.
My question is simply "What, specifically does the confidence level in a rip log mean?" I have searched the FAQ exhaustively, but have been unable to find the solution. I've seen some logs posted with, for example, 3/35, and others with just a single number such as 7. My logs only give me a single number. So do I want a high number or a low number. How do I know if everyone else's results agree with mine. When I tried the Accuraterip link from the FAQ it takes me to the page listing drive offsets. Is there a help menu for Accuraterip? Thanks for any help.
The first number shows the number of submissions in the database that have matching data to your rip. The second number shows the total number of entries for that track that are in the database. CUETools shows both numbers, the foo_verifier component for foobar2000 shows only the first one. So for example 3/35 means three entries out of 35 in the database are matching your rip. The most common reason for this discrepancy between the two numbers are entries with different offsets, so you could get something like:
your rip:
3/35
with offset 664:
30/35
with offset -6:
2/35
in short, the higher the first number, the better.
and btw, your rip is accurate even if you get something like 0/35, as long as there are matches with a different offset. so for example this:
your rip:
0/35
with offset 664:
35/35
means that your rip is accurate, and you just have a different pressing with a different offset (but the data is the same).
For example, if your checksum doesn't agree and the accuraterip count is high you can have a high(er) confidence that yours is wrong.
This is absolutely incorrect! a1striker, please ignore this statement by mpuckett.
Unless you know that you have the same pressing as the one with the hash values being returned, the returned hash value and confidence is meaningless and should be ignored.
in short, the higher the first number, the better.
This is misleading as well. So long as you aren't the one making the submission, a confidence of 1 is all that is necessary to be reasonably assured that your rip is error free.
your rip:
0/35
with offset 664:
35/35
means that your rip is accurate, and you just have a different pressing with a different offset (but the data is the same).
Well the data is offset, but yes, otherwise it is the same. Care really needs to be taken when comparing against results from other pressings. If you get a match for all tracks with the same offset then there is no question that your rip is error-free. Any deviation from this and things are not so clear.
For example, if your checksum doesn't agree and the accuraterip count is high you can have a high(er) confidence that yours is wrong.
This is absolutely incorrect! a1striker, please ignore this statement by mpuckett.
Unless you know that you have the same pressing as the one with the hash values being returned, the returned hash value and confidence is meaningless and should be ignored.
Oh yes, sorry, forgot to mention this case and completely agree, if you have a different pressing. Let me try rephrasing it then. If you have the
same pressing and most of your tracks have matching hash values but a couple don't, you can be pretty sure that yours is wrong.
I also agree that in general the "confidence" value is meaningless and if it returns a matching hash value even with a count of 1 that is a sufficient indication your rip is good.
Thanks for the clarification and sorry for any confusion.
Much better.
If the confidence returned for the track that cannot be verified is within the range of confidence values given for tracks that can be verified, then it is reasonable to think that it is from the same pressing. The rest of your point is probably best shown in an example, like what Goratrix did.
Let's say you rip your disc and most of the tracks have a confidence of, say 50, then tracks then you can be reasonably sure that tracks that can't be verified are probably ripped in error. If the confidence of the verified tracks is only something like 1 or 2, then the tracks that were not verified could easily be error-free, unless there was some other indication that they may not be, such as a test checksum that doesn't match or the EAC log reporting suspicious positions. When looking at it this way, it should be clear that you can completely ignore the confidence returned for tracks that cannot be verified. AR has always worked on the basis of positive matches.
If you're not checking your own rips then all bets are off. I can very easily forge information or upload information to the database for bad rips making them appear as if they are good.
Thanks for all of the assistance. I think I'm clear on the following points: 1) I'm only seeing a single confidence number (rather than x/y) because I'm not using CUETools.
2) I can be confident my rip is accurate with even a confidence of 1 because the chances of even one person getting the
same checksum as mine from a bad rip would be highly unlikely.
Something I'm still not clear on is how i can get an error from only one track when they are all ripped at the same time from the same cd. Ive posted the log below to illustrate the point. In all but the first track I get a confidence level of 8. In track one EAC reports the copy as ok (99.9% quality) followed by "Cannot be verified as accurate (confidence 24)". Should I disregard this as greynol said, assuming mine to be a different pressing. Does ths report literally mean that accuraterip has 24 sets of data that do not match mine? I dont't think it can relate to offsets being incorrect or all of the tracks would be inaccurate. Could the discrepancy on this single track be because I've got an incorrect EAC setting (perhaps not overreading the lead-in and lead-out?
Hmmm?
One final question - what does the very long checksum at the very bottom of the log indicate?
Exact Audio Copy V1.0 beta 1 from 15. November 2010
EAC extraction logfile from 2. April 2011, 21:09
Leonard Cohen / Songs from the Road
Used drive : HL-DT-STDVD-RW_GSA-H41N Adapter: 0 ID: 0
Read mode : Secure
Utilize accurate stream : Yes
Defeat audio cache : No
Make use of C2 pointers : Yes
Read offset correction : 667
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 : Not detected, thus appended to previous track
Used output format : Internal WAV Routines
Sample format : 44.100 Hz; 16 Bit; Stereo
TOC of the extracted CD
Track | Start | Length | Start sector | End sector
---------------------------------------------------------
1 | 0:00.00 | 7:43.63 | 0 | 34787
2 | 7:43.63 | 6:09.25 | 34788 | 62487
3 | 13:53.13 | 3:31.38 | 62488 | 78350
4 | 17:24.51 | 5:06.38 | 78351 | 101338
5 | 22:31.14 | 4:22.65 | 101339 | 121053
6 | 26:54.04 | 8:01.59 | 121054 | 157187
7 | 34:55.63 | 4:17.25 | 157188 | 176487
8 | 39:13.13 | 3:41.20 | 176488 | 193082
9 | 42:54.33 | 5:18.48 | 193083 | 216980
10 | 48:13.06 | 5:23.66 | 216981 | 241271
11 | 53:36.72 | 7:32.03 | 241272 | 275174
12 | 61:09.00 | 6:07.23 | 275175 | 302722
Track 1
Filename C:\Users\Charles\Music\EAC Extractions\(01) - Lover, Lover, Lover.wav
Peak level 99.7 %
Extraction speed 16.7 X
Track quality 99.9 %
Test CRC 1A8D0897
Copy CRC 1A8D0897
Cannot be verified as accurate (confidence 24) [234C6417], AccurateRip returned [2E066EDD]
Copy OK
Track 2
Filename C:\Users\Charles\Music\EAC Extractions\(02) - Bird on the Wire.wav
Peak level 99.7 %
Extraction speed 21.0 X
Track quality 100.0 %
Test CRC 551230D0
Copy CRC 551230D0
Accurately ripped (confidence 8) [C89A12A6]
Copy OK
Track 3
Filename C:\Users\Charles\Music\EAC Extractions\(03) - Chelsea Hotel.wav
Peak level 99.7 %
Extraction speed 21.7 X
Track quality 100.0 %
Test CRC 2F66F1D8
Copy CRC 2F66F1D8
Accurately ripped (confidence 8) [DDC68D63]
Copy OK
Track 4
Filename C:\Users\Charles\Music\EAC Extractions\(04) - Heart with No Companion.wav
Peak level 99.7 %
Extraction speed 23.9 X
Track quality 100.0 %
Test CRC 257F7A2C
Copy CRC 257F7A2C
Accurately ripped (confidence 8) [D8E572FC]
Copy OK
Track 5
Filename C:\Users\Charles\Music\EAC Extractions\(05) - That Don't Make It Junk.wav
Peak level 99.7 %
Extraction speed 25.0 X
Track quality 100.0 %
Test CRC 5955837F
Copy CRC 5955837F
Accurately ripped (confidence 8) [CBE65015]
Copy OK
Track 6
Filename C:\Users\Charles\Music\EAC Extractions\(06) - Waiting for the Miracle.wav
Peak level 99.7 %
Extraction speed 28.2 X
Track quality 100.0 %
Test CRC 5AF42887
Copy CRC 5AF42887
Accurately ripped (confidence 8) [40512C4D]
Copy OK
Track 7
Filename C:\Users\Charles\Music\EAC Extractions\(07) - Avalanche.wav
Peak level 74.8 %
Extraction speed 31.6 X
Track quality 100.0 %
Test CRC 9C6EACFA
Copy CRC 9C6EACFA
Accurately ripped (confidence 8) [1881A27B]
Copy OK
Track 8
Filename C:\Users\Charles\Music\EAC Extractions\(08) - Suzanne.wav
Peak level 99.7 %
Extraction speed 32.7 X
Track quality 100.0 %
Test CRC 5998E954
Copy CRC 5998E954
Accurately ripped (confidence 8) [CC4B213A]
Copy OK
Track 9
Filename C:\Users\Charles\Music\EAC Extractions\(09) - The Partisan.wav
Peak level 99.7 %
Extraction speed 31.0 X
Track quality 100.0 %
Test CRC 1C7E6FD8
Copy CRC 1C7E6FD8
Accurately ripped (confidence 8) [32389DC0]
Copy OK
Track 10
Filename C:\Users\Charles\Music\EAC Extractions\(10) - Famous Blue Raincoat.wav
Peak level 99.7 %
Extraction speed 35.6 X
Track quality 100.0 %
Test CRC 14CF48FE
Copy CRC 14CF48FE
Accurately ripped (confidence 8) [0C0FB6C1]
Copy OK
Track 11
Filename C:\Users\Charles\Music\EAC Extractions\(11) - Hallelujah.wav
Peak level 99.7 %
Extraction speed 37.5 X
Track quality 100.0 %
Test CRC 3011C656
Copy CRC 3011C656
Accurately ripped (confidence 8) [5E168B9C]
Copy OK
Track 12
Filename C:\Users\Charles\Music\EAC Extractions\(12) - Closing Time.wav
Peak level 99.7 %
Extraction speed 39.0 X
Track quality 100.0 %
Test CRC B3EB81B2
Copy CRC B3EB81B2
Accurately ripped (confidence 8) [90EA2F7C]
Copy OK
11 track(s) accurately ripped
1 track(s) could not be verified as accurate
Some tracks could not be verified as accurate
No errors occurred
End of status report
==== Log checksum 084B2ECA7C2EEAB6CD9E304DEB0819EDB9B50B6AE64A2B2B4EA9D31E59F75C0A ====
Could the discrepancy on this single track be because I've got an incorrect EAC setting (perhaps not overreading the lead-in and lead-out?
Yes, i think so. If your CD-drive does not support this feature, you must deactivate it or the first or last track is allways (or most) not accurate --> Please test it and post your results here.