weird accuraterip thing

[Dude]

hi,

I have ripped a CD that is in the accuraterip database and i have read on the site there must be 3 or more persons who have the same CRC of the track for your track to be accurate.

Now I'm using dbpoweramp reference 12.1 and I get the indication 'Accurate (2)'.
Why can accuraterip even with only 2 CRC matches tell if the track is accurate, while on the website is written it has to be 3 or more users?

update: with another CD I even get 'Accurate (1)', so only 1 matching CRC of other users.

is this a bug?

thx

[Teknojnky]

Re: weird accuraterip thing

Accurate rip simply means your rip matched some one elses.

The more matches simply increases the odds that all rips are good.

If there were any errors detected during the rip, it would indicate and not be 'accurate'.

So there are 2 parts, no errors detected in the rip = SECURE, and rip matching other rips = ACCURATE RIP. They are independent functions, together they tell you that its a good rip.

Since you didn't get any errors, and you matched someone else, you should pretty sure that your safe. If you matched more than 1 one other, then the odds increased greatly that all the matched tracks are good.

[Spoon]

Re: weird accuraterip thing

With Accurate (1) there is 1 in 4 Billion chance there is an error in accurate rip.
With Accurate (2) there is 1 in (4 Billion x 4 Billion) chance there is an error in accurate rip.

[Dude]

Re: weird accuraterip thing

With Accurate (1) there is 1 in 4 Billion chance there is an error in accurate rip.
With Accurate (2) there is 1 in (4 Billion x 4 Billion) chance there is an error in accurate rip.

hi

thanks for the info, but where do the numbers come from: for example how do you know it's 1 in 4 Billion ?

thx

[Spoon]

Re: weird accuraterip thing

That is the odds of a 32 bit number being wrong.

[Dude]

Re: weird accuraterip thing

That is the odds of a 32 bit number being wrong.

i still don't understand the logic behind it. can you explain me please what a 32 bit number has to do with the chance your track matches someone else's, it's not clear for me

thx

[Tigerman]

Re: weird accuraterip thing

It has something to do with statistics. As you know there are lies, damn lies and there are statistics

sorry couldn't resist :D

[Dude]

Re: weird accuraterip thing

maybe Spoon can explain me how it works?

thanks!

[Spoon]

Re: weird accuraterip thing

It is a CRC32 (slightly changed), 4 billion posibilites.

[Dude]

Re: weird accuraterip thing

It is a CRC32 (slightly changed), 4 billion posibilites.

so if I understand it well:
there is a chance of 1/4 billion that the CRC32 of your own track is calculated wrong and does not match the CRC32 of the track of somebody else, if you have Accurate (1)?

Spoon, please confirm if I'm understanding this right

thx in advance!

[Teknojnky]

Re: weird accuraterip thing

so if I understand it well:
there is a chance of 1/4 billion that the CRC32 of your own track is calculated wrong and does not match the CRC32 of the track of somebody else, if you have Accurate (1)?

No.

There is the chance of 1/4 billion that the CRC32 of your own track that matches another CRC32 of someone elses track, is wrong.

In other words, if 2 different people generate the same crc32 for the same track, one of 2 things are correct: A) they are both correct (very likely), B) they are both wrong but match (very unlikely due to how often would 2 different discs have the exact same error(s) when ripped by 2 different people on 2 different drives).

Now, expand that out to 3 or more people... the odds of 3 or more people generating the exact same crc32 for the same track, would mean that all 3 people's discs have the exact same error(s) and that their drives ripped the error(s) exactly the same.

[Dude]

Re: weird accuraterip thing

There is the chance of 1/4 billion that the CRC32 of your own track that matches another CRC32 of someone elses track, is wrong.

but what has the number bits (32) of a CRC32 to do with the chance (1/4 billion) it's wrong?
I don't see the logic behind this.
Can you explain me (this was originally my question)

thanks in advance!

[Teknojnky]

Re: weird accuraterip thing

http://en.wikipedia.org/wiki/32-bit

The range of integer values that can be stored in 32 bits is 0 through 4,294,967,295 or −2,147,483,648 through 2,147,483,647 using two's complement encoding. Hence, a processor with 32-bit memory addresses can directly access 4 GiB of byte-addressable memory.

What this means is, that there are 4 billion possiblities for a given track. If someone has a track and it's crc is the same as yours, then odds are its the same.

Really, the only thing you have to understand is that if accurate rip has the disc id and matching crc's to your rip, then it is accurate.

Read this over until you understand it.

http://www.dbpoweramp.com/secure-ripper.htm

AccurateRip

Overtime AccurateRip can become like a wise-friend, someone you can rely on and trust. It works by storing peoples ripping results and comparing your result with theirs. For example 100 people rip Madonnas latest CD, of those 100 twenty have errors, the other 80 all have identical rips. If you were to rip your Madonna CD there are 2 possibilities, AccurateRip would report that 80 other people agree with your rip (confidence of 80), or that 80 disagree if your had errors. What are the odds of 80 people agreeing with your rip, but they really had a bad rip (ie those 80 people had bad rips which happened to give the same check code)? the odds are 4 billion x 4 billion (repeated 80 times), an astronomical number. If more than 3 people agree with your rip, it is 100% certainty it is accurate.

[bhoar]

Re: weird accuraterip thing

but what has the number bits (32) of a CRC32 to do with the chance (1/4 billion) it's wrong?
I don't see the logic behind this.
Can you explain me (this was originally my question)

thanks in advance!

CRC32 is essentially a hash algorithm. It generates a "sufficiently unique" value, 32-bits long for any given input data, no matter how large.

A single bit error causes the computed hash to be vastly different. Like most hash algorithms, given sufficient input data, it does a rather nice job of evenly spreading computed values across the 2^32 possible resultant hash values.

If you don't understand what a hash algorithm is, you should really go read up on them.

Under extremely unlikely circumstances*, a special sequence of random bit errors might just match to the same hash. However, since 2^32 is a large number of potential matching hashes (~4 billion), this situation is statistically unlikely.

So, when you receive an Accurate (1) report, that means that at least one other user who ripped this track got the same hash result. For large datasets like these (the track data is a large # of bits, typically 100s of millions of bits), the math leads to the conclusion that there is only an approximately 1 in 4 billion chance that the fact you two got the same result was not due to having the exact same data but, instead, due to having *different data* compute to the same hash.

[One assumption here is that if two or more people rip the exact same data presumably using different physical discs (of the same artist/album) and drives, then it is extremely likely that data exactly represents what was on the disc.]

Every time you add another matching person (found via a matching hash), the right side of the "1 in 4 billion" is multiplied by another 4 billion. So, if two other people match (Accurate (2) = a total of 3 people, including you), the likelyhood that the matches are not due to duplicate data is on the order of "1 in 16 quadrillion".

Since lives don't depend on these numbers, I'll stick to being happy with Accurate (1).

-brendan

* note that it is rather easy to *construct* unique streams of data that would match the same CRC32 value using several approaches, which is one reason that security software has moved on to newer hashing algorithms; however, with CRC32, random noise is the least efficient way to try to create a duplicate hash...you'd most likely have to try billions of different bit changes...

[Dude]

Re: weird accuraterip thing

A single bit error causes the computed hash to be vastly different. Like most hash algorithms, given sufficient input data, it does a rather nice job of evenly spreading computed values across the 2^32 possible resultant hash values.

Ok I understand it now, but why is it 1 chance in 2^32 possibilities and not for example 2 chances in 2^32 possibilities? So where does the "1" come from, so how do you know exactly there is only 1 chance (and not more chances) out of 2^32 possibilities that both hash codes are the same even if the original data that was used to generate the hash code was different? Why could this not be 2/2^32 for example or some other number?

thx