AccurateRip - can someone please tell me how it works?

[Gew]

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

I just re-ripped the whole album, again w/ some crc errors.
I've upped the log. Here goes.

http://gew.pastebin.com/m4657ebb6

As you can see, in a "OK" situation the verbose log gives something like:

Peak level 98.8 %
Copy CRC 755EF772
Accurately ripped (confidence 3) [8975BC4E]
Copy OK

Whereas in a non validate rip (w/ crc error), it could look more like this:

Peak level 98.8 %
Copy CRC 16268050
Cannot be verified as accurate (confidence 3) [9BB6E79B], AccurateRip returned [3FB11739]
Copy OK

Now, to sum up my deep down question in all this, I understand that the value given in square bracket (in error free rips) are the checksum, along with "confidence" (no. of verifications/unique submitted results for track). I hope I follow, this far!

Then, in the latter example, I have two different values given inside square brackets.
So, my real questions is:

1) which of these two checksums is the [faulty] one that I've gotten?
2) [more important] what's the other checksum??

As shown in my screenshots in previous posts, I got differing checksum values in the _first_ square bracket field, therefor I will be daring and conclude that this is my present [faulty track 19] checksum, since the second [sum] is consistent over re-rips.

That really leaves only question *blooper*2 to be solved. What is that other value? Perhaps I got a bit confuzed earlier when you (Spook) told me that there's no such thing as "expected" value in AR, but you ment it in another sentence, sort of.

Here's my hypothesis/theory.

While having ripped an whole album, AR has actually ,judging from album tracks length, assumed/proposed this album to be D12 - Devil's Night (which it is), hence dictating the [existing in AR database] OK (confidence=3) crc for this album's track no. 19.

Is this conceivable?

I feel like such a clown dropping such nail-post on the subject, but I've tried explaining myself as firmly as possible, to avoid any misunderstandings. I would so much like to come to clarity with this mysterious [ie.] 2C936CB5 checksum!


---
Regards~
And ty in adv for being so helpful.

[Gew]

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

Interesting as it may seem, I finally managed to extract track no. 19 with proper checksum in return (2C936CB5). Therefor, I can now say I know for sure that the two hash sums 1) the shifty one given at the moment of faulty ripping 2) the "expected" sum, taken from the in-database matching TOC of disc album.

Now, I'm pretty pleased, but there are still some thing that I cannot get out of my head. Theories, if we could call it that.

So, say I have two different pressings of the same disc album (eg. same lengths in TOC). Both of these presses _are_ in fact in AR database.

Now, suppose I bring up a new disc compilation, and say there are a total of 20 tracks. I take the first 10 tracks from pressing no 1; then the remaining 10 tracks from pressing no 2. Now, how would AccurateRip react on this?

The two albums would share TOC/track lengths, thus reading/searching from same db entries. However, it will only match half on half, so to speak. Will this cause one of the halfs to get crc mismatch (ie. the one with the least confidence count; oh, and in that case what about if confidence count are equal, first occurance in db would get to go then, right?).

Or, we could totally disregard the whole paragraph above if it would really take crc's for 10 of the 20 tracks from pressing A in db; thus the remaining 10 tracks from pressing B. This makes most sense, really, don't you think?

Ty in adv~
Best Regards~

[Gew]

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

Interesting, again.

Now, after using logical sense I've come to the conclusion that it's most obvious that in the scenario described in my previous post; eg. "splitting" 2 CDs (with similar TOC) into two new CD compilationsm, using same TOC, but taking ½ of the tracks from cd. no. 1 and other ½ of the tracks from cd no. 2.

In this case, AccurateRip would most definitely consider all tracks OK, seeing that AR from what I understand works "on a per track basis" -- eg. track data crc against disc TOC.

Now, finally, what still keeps me awake during nights. Now I know this is unlikely to happen, but say there are two different pressings of an album (same TOC/track lengths/eg. AR db entry). Both of these two pressings exist in AccurateRip database.


Nb. TLDR goes from here!

Let's say I have a scratched disc that will not validate. Now, would AR then display only _one_ "known" (notice how I now chose to use that term instead of "expected", hehe) value under "AccurateRip returned [known_crc]", say for instance (which would be likely then) the one with highest count of confidence

Or, will it return both existing crc's, ie. "AccurateRip returned [123F123B & 321B321F]"..?

[Spoon]

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

For a miss-match the shown confidence and crc can be from any of the pressings.

[Gew]

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

Thank you for you answer.

So, only one confidence crc, never several. But any? You mean it's all by random? Or ie. by first confidence match found -- in alphabetical order -- in db?

[Gew]

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

Also, how often is AR db updated? It's not in real-time mode, right? There's some sort of manual phase of confirming all newly-gotten submits?

The reason that I ask is because I ripped a disc that wasn't in AR database, I wanted to see with my eyes how it entered database, so I submitted my results and re-ripped it. However, there was still no hit. I figured, "there's probable cause for it to need at least 2 equal checksums for a pressing; being submitted from unique users, prolly secluded by IP's". I therefor went to a friend of mine, and ripped the disc at his place aswell. Submitted the results there also. Then I went back home, and tried ripping it -- for a 3rd time. However, still "Not found in AccurateRip database".

So, this is why I ask. Is it a matter of time? You update the database say once a week, once a month, something like that? Or any other major fact that I've overlooked in this..?

Regards~

[Spoon]

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

Updated once a month.

AR is track based, when the database is created there is no order to the pressings.

[Gew]

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

Updated once a month.
Ty. Fair enough!

AR is track based, when the database is created there is no order to the pressings.

True. But just so I'm clear, the track entries in db are still based upon pressings track lenght(s), right? I mean, say track no. 9 on a disc (let's call it "A") are 3:35m long. There would be billions(?) of tracks with that length, and would prolly take database-searching a h*ll of a long time.

In simple, in this particular case, it does search crc matches for a track with no. "9" on a pressing with TOC ie. 1/1:05 2/2:40 3/3:49 ..... 9/3.35, correct, right?

With "AR is track based, when the database is created there is no order to the pressings.", you just mean that entries are not "categorized" by pressing in the database, right? Just so that I'm not misunderstanding it.

[Spoon]

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

I meant its verification is track based, where its identification is disc based. (ie someone might only rip 1 track from a CD, and submit it).

[Gew]

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

Aaah, I see.

So, basically, when I've ripped a track and sends AccurateRip an instruction to verify, it will only search its database for matches in discs of correspondent length as the one I've just ripped. Correct?

[Teknojnky]

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

when you stick your cd in, accurate rip checks the database for track crvs with the same disc id.

your track(s) are ripped, and then compared to the other submitted crvs and if it matches then it says the track is accurate and gives you a confidence number which is the number of other submissions that match yours.

it does not matter if there are other cds with the same number of tracks or timings, only how many match yours.

sometimes there are cds that are different pressings, these may be shown as the not verifyable by accurate rip and how many other submissions disagree with yours.

until someone(s) else submits the same pressing, you won't get an accurate rip comparison on those cds.

[Gew]

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

Thanks for your answers. To avoid being repudiated as a retard, I shall throw in that I'm having some personal issues that I'm taking "workflow-suppressing" medication for. However, yesterday night I skipped my pills, and I kept lying in bed thinking about all this. It suddenly made clear sense. It wasn't up until this moment I felt that I had a clear sight on what Spoon really ment with "I meant its verification is track based, where its identification is disc based."

I kept slicing it, and I do believe I finally came up with a proper view on the "handshake" for AR submitting respectively AR lookup. It suddenly felt really simple, and I felt like being such a clown who've just been mixing the puzzle pieces around in my head earlier. I mean, when I have managed to understand the whole TLS/SSL handshake protocol (among others), this shouldn't be that much of a big deal, right? Anyways, here goes my interpretation:

1. Scenario where client is submitting 1 track from CD
When submitting the results, client sends %DiscID% (TOC info) and more specific that %TrackNo% is supposed to have %TrackCRC%.

2. Scenario where client is performing lookup on 1 ripped track on CD
After ripping, client sends a query with %DiscID% (of the cd in the drive) to database, which then looks for any present %TrackCRC% for specific %TrackNo%, only(!) on %DiscID% section (eg. not looking through whole of database; which would be time wasting).

In case of match; database tells this to the client. In case of mismatch, database returns %TrackCRC% of %DiscID%->%TrackNo%-match in database, plus the "confidence"-number for this (mis)match.

Wow, it feels so good right now. Like I'm going to get inner peace on this subject, which I cannot well enough express the - to me - importance of. Spoon and others who've helped me along my way, please reply to this only if I've gotten something wrong in my "routine summary" above.

In other case, happy new year.