AccurateRip confidence - what does it really say? Options

[OliP]

I have a CD RIP with EAC V1.0 beta3
Checked with CUETools 2.1.4

CUETools gives me here:
.
.
03 [f41e2a14|bc31a59f] (39+08/88) Accurately ripped

So thats means, this track matches with 39 in AR V1 and with 8 in AR V2.
Makes 47 matches alltogether. But there are 88 entries!
Are these 41 other rips, rips with errors? Or maybe different pressings?


Well !
My logical thinking tells me that read errors always occure on different places on CDs right?
So erroneous rips do always have different checksums and none of them matches another, right?
So if I have a confidence 1, its most likely that I have a bit-identical copy. Otherwise me and the other user, we both must have a read error at exactly the same place, so that our checksums are identical, and this is very unlikely right ??
So when I have AR confidence 1 and the database also has many other results I do not match with, its most likely that my rip is correct, and all the others are wrong, (or different pressings) right ???


I´ve never really understood this...
But:
If I have a confidence of only 1, my rip is at 99,9999999999999999999999 % a Bit-identical copy, right?


This post has been edited by OliP: Jan 7 2013, 02:09

[greynol]

In addition, defective drives and issues with the ripping software can result and, in all reasonable certainly, have resulted in the population of the AR database with active* hashes for errant rips.

(*) active meaning confidence two or greater; confidence of one if there are no other validated submissions for any particular disc ID.

This post has been edited by greynol: Jan 9 2013, 02:00

[OliP]

Another possibility, though I don't know how likely this is: If there is a flaw in the glass master for a CD such that multiple copies have exactly the same incorrect data, then the rips will be verified by AR.

So thats a production mistake at a certain CD charge, meant so?
But will happen only on rare occassions, right?

Ok, now I´m going to understand the kidding-like sentence of spoon - "anything is possible"

In addition, defective drives and issues with the ripping software can result and in all reasonable certainly have resulted in the population of the AR database with hashes for errant rips.

yes, but that falls in the category erroneous rips, where it´s so much unlikely to have exactly the same error on another machine, and get a confidence for that.
OK