Odds of getting a 'false-positive' reading?

[Gew]

Hiya!

I've been thinking on AccurateRip a lot lately. So, now, I simply need a boolean (true or false) on the following statement:

The risk of getting a "false positive" on a ripped track (eg. it returns "Verified OK, confidence x" even tho it's not right) is 4,294,967,296 to 1 (the number of possible combinations in a 32-bit hexa-number).

Is this correct?


Footnote. I was thinking, I've noticed that there are two sorts of checksums given for a ripped track (using EAC). First, after ripping, the popup tells me ie. "Verified as OK [checksum], confidence x", but it then shows _another_ checksum in the "Test CRC" aswell as "CRC" row in EAC. Some simple explanation to this? Like that one of the checksums is including(!) the .WAV header, whereas the other is CRC for the raw PCM, or something similar?

Then, I was also wondering if I have overlooked some important piece of the puzzle, like ie. if these two -- different -- checksums could make the odds even better than 1/4294967296? ..or is that end of the story?


Thank for for all answers~
Regards~
Ty in adv~

[Spoon]

Re: Odds of getting a 'false-positive' reading?

Indeed, there are other helpers (which can be used in addition to AR):

Rereading with CRC32 which uses a different calculation
c2 pointers

I may self am comfortable with X billions to 1 chance, after all I only have < 500 CDs to rip

[Porcus]

Re: Odds of getting a 'false-positive' reading?

So, now, I simply need a boolean (true or false) on the following statement:

The risk of getting a "false positive" on a ripped track (eg. it returns "Verified OK, confidence x" even tho it's not right) is 4,294,967,296 to 1 (the number of possible combinations in a 32-bit hexa-number).

Is this correct?

Not really. AFAIK, there are some samples that are cropped off before calculation, for practical purposes.

Besides, as Spoon mentions, there might be some censoring of data in your ripping application. Indeed, there is some error correction in the CDDA format.
--> Consequence: you are not comparing to the reference a uniformly independently drawn sequence of bits.

Then, what is the error in the ripped track? Your rip has the vast majority of the bits in common with the reference (violating the independence used implicitely to calculate the above odds. For example, if the error is only a single bit (which I think is grossly improbable for the red book CD error correction not to capture), then the risk should be zero.)

And, did you buy your CD second hand? I guess the odds that one or more CDs in my collection having been ripped with EAC or dBp by a previous owner is far greater than 4e+09 to one.

And then there are manufactoring errors, but that is something AR cannot be expected to cope with.