"Confidence:1" after _second_ submitted result, yes?

[Gew]

Re: "Confidence:1" after _second_ submitted result, yes?

Hehe. Well, those examples (see question a+b) were actually just posted to shed some light on how the AR routines really work. To be sure I have accuraterip, I would prolly just re-rip locally and check for matching crc's in log, which would be fulfilling/confident enough for me. But like I said, not the issue, more like, erhm, the questions! :P

[pjc2]

Re: "Confidence:1" after _second_ submitted result, yes?

Looking at the latest database code, it will keep Conf: 1 if no other submissions, so I was right in the first instance (the code did drop conf 1 at one time, but the recent rewrite restored it).

Thanks for clearing that up!

I wanted to make sure I was interpreting my AR results correctly, since the discs where I got Conf: 1 always listed all tracks, and a few discs with Conf:2 omitted some tracks. That seemed to line up with your original explanation.

(I'm glad for the Conf: 1 data, by the way, since it gives me a good deal of confidence for all the tracks that match, and lets me focus my quality efforts on the few that don't.)

[Gew]

Re: "Confidence:1" after _second_ submitted result, yes?

...since the discs where I got Conf: 1 always listed all tracks, and a few discs with Conf:2 omitted some tracks.

Please if you have just a few minutes (and have understood what Spoon means) could you please elaborate on the routine at its whole..? 'cuz his one-liners aren't really cutting the deal to me. Perhaps I'm too dumb. Why is conf:2 disc omitting tracks where conf:1 discs aren't?

I've tried this hypothesis, can you verify it?

Here goes:

A certain DiscID is completely blank in database. No entries in neither raw nor published db. User then rips one or several tracks and submitts it. These goes instantly (let's overlook that ~month that goes before update, for simplicity here) --> published db with conf:1, correct?

Then -- naturally -- for each backing submission on same crcs the conf: is increased by one.


However.

Scenario 2)

A certain DiscID is completely blank in database. No entries in neither raw nor published db. User then rips one or several tracks and submitts it. These goes instantly (let's overlook that ~month that goes before update, for simplicity here) --> published db with conf:1. THEN, another user rips same tracks but with different crcs. This [new_crc] does not not go straight into published db, but to raw db. Also, the [old_crc] is no longer in published db, but revoked and pulled into raw db, where now both of these crcs are awaiting further verification. Correct?

[pjc2]

Re: "Confidence:1" after _second_ submitted result, yes?

As I understand it, I think you've got the directions backwards. Everything goes into the raw DB. Whether it's then promoted to the published DB is the question.

A certain DiscID is completely blank in database. No entries in neither raw nor published db. User then rips one or several tracks and submitts it. These goes instantly (let's overlook that ~month that goes before update, for simplicity here) --> published db with conf:1, correct?

It always goes into the raw DB. Then, if the database update process deems a rip reliable, it publishes the CRC.

So if you get a disc with conf:1, it's just a single user's submission (all ripped tracks), and it may or may not be "accurate" (since it's just a single data point that hasn't been independently confirmed). Where you agree with that single submission, it's likely accurate (which is why conf:1 is useful and why it gets published). Where you disagree with conf:1, there's no telling which of the two of you is right.

These goes instantly ... --> published db with conf:1. THEN, another user rips same tracks but with different crcs. This [new_crc] does not not go straight into published db, but to raw db. Also, the [old_crc] is no longer in published db, but revoked and pulled into raw db, where now both of these crcs are awaiting further verification. Correct?

Again, everything does into the raw DB first.

So in this second case, when the raw DB notices a conflicting CRC, each with conf:1, it can't tell which one is accurate, so it considers them both unreliable until one of them is further confirmed. So at the next update to the published DB, the track with mismatched CRCs won't show up at all. This is why a second user's rip will result in lots of conf:2 (where the CRCs match) and a few not-in-database (where the CRCs didn't match).

But everything is still in the raw DB, so when a third user submits rip results, if his CRC matches one of the two previously submitted, that track's confidence will suddenly jump from 0 (nobody agrees) to 2 (2 independent rips agree). (And all the other tracks would bump from 2 to 3, as expected.)

[Gew]

Re: "Confidence:1" after _second_ submitted result, yes?

Ty alot pjc2, very good explanation.

The part about "..(which is why conf:1 is useful and why it gets published).." was indeed developing my perspective. I was just too narrow-headed to see, I suppose.

One question only, and I will find closure.

Scenario 3) Blank discID, no submissions whatsoever to begin with. User rips conf:1, another user verifies and bumps to conf:2, third, forth, etc. Say that discID/track has got one crc only, and a very well verified for that matter, say conf:10.

Then, another user submits [another_crc]. Will the routines you described earlier still go in the same matter, ie. would this [another_crc] _be made available_ as conf:1 as in the fact that it "may or may not be 'accurate'..", or does the rule that only single conf:1 submissions is made available really go as __when there is only one pressing__.


Boolean this / TLDR / In short:

So if you get a disc with conf:1, it's just a single user's submission (all ripped tracks), and it may or may not be "accurate" (since it's just a single data point that hasn't been independently confirmed). Where you agree with that single submission, it's likely accurate (which is why conf:1 is useful and why it gets published). Where you disagree with conf:1, there's no telling which of the two of you is right.

Will a single submission be published the way described in quote above only if it is the very first (and only) submission for discID/specificTrackNo..?

If the answer to this is Yes then I will finally have found peace

[pjc2]

Re: "Confidence:1" after _second_ submitted result, yes?

Will a single submission be published the way described in quote above only if it is the very first (and only) submission for discID/specificTrackNo..?

I believe so -- that one odd submission is "inaccurate" because 10 others agree with each other, so there's no question about who's right. The CRCs remain at conf:10 and the odd submission is ignored by the published DB.

This is, of course, ignoring the multiple pressings issue. I'm not exactly sure how AR handles that, but I suspect a different pressing has different CRCs for all of the tracks. (If some CRCs match, that suggests that it's the known pressing and the mismatched CRCs are indeed errors.)

I think what happens here that (1) AR notices all the CRCs are different and (2) waits for confirmation. I haven't confirmed this, but I suspect the first submission of an alternate pressing is considered unreliable (conf:0) until confirmed by another submission. This is much like the case where the first two submissions disagree -- all the tracks on the alternate pressing are considered conf:0. (However, the tracks on the known good pressing would retain their confidence levels.) Once a second submission comes in to confirm the alternate pressing, the alternate pressing's tracks bump up to conf:2. This is all conjecture at this point, but it follows from the AR design Spoon has described.

I don't yet fully understand how the R14 alternate-pressing-verification system works. I hope to figure that out in the coming weeks.

[Gew]

Re: "Confidence:1" after _second_ submitted result, yes?

Ty again, so very much!

I think I finally got the entire concept, brick by brick. The way you describe a track's sudden bump from "Track not found in database" (eg. what you refer to as 'conf:0') to confidence:2 is brilliant, it leaves little room for misunderstanding of the actual routine.

I believe what got me confuzed in the first place was this:

> "Confidence:1" it means that 2 unique users/computers has ripped the track in particular

Not always, if there is only one pressing of a CD then a single submission would be made available.

I believe Spoon misunderstood me. I was asking if (for instance) "confidence:5" could mean that 6 (and so on) unique users hade submitted the track crc, eg. that the "count offset" was 1 to begin with. Thus when his answer contained "Not always" I was still wondering on in which scenario the count offset was really 1 so that ie. conf:2 ment that 3 different users had gotten the result, which is really _never_ the case. This sort made my whole perspective a bit fuzzy there, just as I didn't have enough pieces of the puzzle to put in order!

Anyways.

Golden rule is that one discID/trackNo will have one chance only on getting "the benefit of the doubt", and this is when its first crc is submitted. This one checksum goes directly (after update) to published db as conf:1, whereas it gets "pulled back" as soon as any other/conflicting crc's occur on the specific discID/trackNo.

Furthermore..

When I think deep and hard on all this, the -- as you call it -- "multiple pressing issue" is really naturally solved this way. In easy terms, it starts with a conflicting crc, which is -- at its first submit -- pulled back to raw db / not published, but as soon as another user submits it, it goes in a sort of own thread or channel on the same discID/trackNo.

@pjc2,
Please let us know when you've figured out the new -- R14isch -- system, and feel free to publish the routines in the easy language you've done so far. You've been great help. Also Spoon has been of much great help, disregarding that one quote high above that got me dazed & confuzed!


Regards~
Over 'n out~