AccurateRip - can someone please tell me how it works?

[Gew]

Hi!

Yeah, I laid in my bed the other night, started wondering about the routines that are really used in AR. Basically, my cause of concern was this:

Say I extract a track for a CD. Then AR tells me I have CRC mismatch, it returns the hash sum that I've received, plus the "expected" hash sum for the desired track.

My question then lies in the actual routines for fetching the "expected" value. I'm not into getting to know the deal brick by brick, yet I'm sure there's a possibility for someone [with good intel] of giving a vague/understandable explanation here.

Given the fact that it's told that AR database does not contain actual songs, but just hash, I take it that the PCM/.wav bytesize is of great importance for fetching this "expected CRC" value. However, I bet that "Alice Cooper - Poison" _aswell as_ "Michael Jackson - Thriller" could both be of the exact same bytesize. Here is where the [to me] mystery begins. What's the deal when there are several tracks with same bytesize in AR database?

One [possible] explanation that I thought of, is that AR database does inded contain a very very tiny amount of actual song PCM data, ie. the first and last 4 bytes of each track. Hence, AFAIK, there should be a near zero probability for two audio tracks to contain *blooper*1) exact same bytesize *blooper*2) exact same first & last 4b of data.

Am I [somewhat] on the right track here? I'm greateful for all answers. I'm just curious, and can't let go on this mindmaze atm.


Regards~
G.

[Spoon]

Re: AccurateRip - can someone please tell me how it works?

Track size is not used for single tracks, rather all the track lengths from a cd, so there is little chance of a collision and if there was it would not matter as both results would sit side by side.

[Gew]

Re: AccurateRip - can someone please tell me how it works?

Oh, so it takes all track lengths and go from there, I see, I see. Probability-thesis is not my major, but I can imagine it's as you say -- a slight to none chance of collision then. However, I don't get "and if there was it would not matter as both results would sit side by side."

I mean, say Album A and Album B both contain three tracks w/ length as follows:

*blooper*1. 3.10m
*blooper*2. 3.20m
*blooper*3. 3.30m

The actual track data would [ofc] differ anyways, hence the CRC sums of the tracks.
This resulting in messy/faulty expected values, right?

Also, might I add/ask as a footnote, what's the minimum no. of tracks that must be on a CD record for AR to function? (as a matter of probability)

[Spoon]

Re: AccurateRip - can someone please tell me how it works?

1

[Gew]

Re: AccurateRip - can someone please tell me how it works?

But then.
There must be thousands of one-track-only CD's out there containing the same length on their one and only song, how does this match up with the database? There must be som further info it fetches to do the trick..?

[Spoon]

Re: AccurateRip - can someone please tell me how it works?

Say you had a one track CD and there were 100 same length (but different audio) cds. In AccurateRip there would be 100 CRCs, the list is simply walked until there is a match, the other discs to no interfere with your rip.

[Gew]

Re: AccurateRip - can someone please tell me how it works?

Thank you for the good explanation, makes sense.

However, it still fuzzes me. CRC's get totally(!) different with minor changes, right? Ie. just tried touched a.txt only containing character "a", ran fciv for crc32, gave e8b7be43, then modified the text document to only containing char "b", then crc32 hash was "71beeff9", eg. mad differently.

So, with this fact given, say I have a 1-track cd containing this 3m10s track that I want to extract. The cd is scratched so EAC fails on perfect rip. AR returns crc "foo1", and in parenthesis "Expected: foo2", just for example.

My question then, how come AR knows what hash to expect from a track that failed its checks? I mean, let's say there are (your example) 100 1track-cds w/ 3m10s songs in AR database, then (thanks to the damaged disc) it would not manage to get any match when "walking the list", right? Therefor it shouldn't be able to carry a "Expected" int to user?

Please let me know if I'm missing some great point that could explain it all, I'm good at overlooking vital elements of procedures therefor get confuzed on how things operate. Closure means everything to me!

Regards~
G.

[Spoon]

Re: AccurateRip - can someone please tell me how it works?

There can be no expected value, only positive matching, not negative.

[Gew]

Re: AccurateRip - can someone please tell me how it works?

Alright. But what does this mean then (para-requoted to English from my native language in EAC GUI):

"..Cannot be verified as correct (confidence 3) [8C6CF585], AccurateRip returned [2C936CB5]
Copy OK"

As I interpret this "return code", I have gotten crc 2C936CB5, whereas 8C6CF585 is "expected" as correct crc for this particular track.

However(!), I shall mention that this is not a single-track cd, but a full-length album. Is it conceivable that the reason that I [in this very case] get a expected(??) crc, is simply due to the fact that it here has "crowd data" to work from (all other tracks); thus guessing/assuming which album I'm processing, hence the ability to return a "expected" crc.

Furthermore, if(!) this is true, it would mean that I could never ever get this kind of status message when extracting a (scratched/bad) one-track-only cd, but only on ie. an album cd. True?

[Porcus]

Re: AccurateRip - can someone please tell me how it works?

I think you need to interchange the CRCs in the interpretation. I guess that the explanation is that there is one AR entry with CRC=2C936CB5.

Are the rest of the album tracks accurately ripped?

Also notice the offset issue. Two different pressings from the same digital master usually differ since they have different number of zeroes before the first one (i.e. one has a split second more silence before music begins than the other).

[Gew]

Re: AccurateRip - can someone please tell me how it works?

Thank you so much for your answer Porcus.

So you mean sort of the other way around? I still have two (different) figures though..

"..Cannot be verified as correct (confidence 3) [8C6CF585], AccurateRip returned [2C936CB5]
Copy OK"


The 'confidence' tells me how many (different) people whom has submitted AR results for the track, right? In this particular case, could it be that I am being told sort of that:

"CRC for your rip is 2C936CB5, whereas I [judging from the other 18 tracks on this cd] assume that the correct sum should be 8C6CF585 (which has been submitted/reported by 3 ppl)"

Am I all the way lost?

I shall point out that this particular CD is a full-length album with a bounce of other tracks, whereas about 4 is getting errors.

[Gew]

Re: AccurateRip - can someone please tell me how it works?

Oops, the other way around, of course.

What I ment was that if it tries to tell me:

"CRC for your rip is F9A27AA7, whereas I [judging from the other 18 tracks on this cd] assume that the correct checksum should be 2C936CB5, this has been submitted/reported by 3 ppl"

Now, this is interesting. Look at these snapshots, taken from two sequental rips on the very same track on the very same album.





As you can see, the second checksum is constant, whereas the first one differs. This obviously points at read errors, which is expected since the disc is badly scratched. However, I'm just trying to get someone to confirm this with the "2C936CB5" sum, eg. that AccurateRip actually has fetched this checksum as more or less assumed, juding from the other 18 tracks predicting the album to be exactly what it is. Is this correct? This means that if I had let's say a one-track-only CD that was just as badly scratched, returning the same differing checksums, I could never get a second value (eg. in my case "2C936CB5"), correct?

Ty in adv~

[Spoon]

Re: AccurateRip - can someone please tell me how it works?

>"2C936CB5"

Might not relate to your disc, it is just a number, as the CRCs are changing for sure there are errors in the rip, and if all the other tracks match accuraterip with a confidence of perhaps 5 and track 19 does not, then there is a ripping error, even if EAC says there is not.

[Gew]

Re: AccurateRip - can someone please tell me how it works?

Alright. Ty, again.

But, what about the confidence no. (3, in this case) reported every time I try to rip the track.

"CRC for your rip is F9A27AA7, whereas I [judging from the other 18 tracks on this cd] assume that the correct checksum should be 2C936CB5, this has been submitted/reported by 3 ppl"

Are we there yet? ;P

[Spoon]

Re: AccurateRip - can someone please tell me how it works?

Show the results please for Track 18.