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: Accuraterip confidence confusion. (Read 29502 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Accuraterip confidence confusion.

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.

Accuraterip confidence confusion.

Reply #1
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.

Accuraterip confidence confusion.

Reply #2
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).

Accuraterip confidence confusion.

Reply #3
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.

Accuraterip confidence confusion.

Reply #4
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.

Accuraterip confidence confusion.

Reply #5
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.

Accuraterip confidence confusion.

Reply #6
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.

Accuraterip confidence confusion.

Reply #7
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 ====

Accuraterip confidence confusion.

Reply #8
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.