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

[Gew]

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

Correct

Marvelous! I think what made me confuzed earlier was how I read in some thread that "tracks that give C:1 cannot be trusted, since it could pretty much just be your own rip that has entered db". Then of course, you've earlier explained how published db is updated once a ~month, so it would me then still be pretty far out the edge, but I guess I pretty much brooded my head into that, which complicated to understand concept. Getting to know the distinct difference in raw db and published db was a great relief, making everything so much easier. Ofc, if I'd found this thread (http://www.hydrogenaudio.org/forums/...howtopic=53150) earlier, I would have known about this wo/ having to ask.

Anyways, one last thing. Confidence:1. I could pretty much swear that I have gotten Confidence:1 on some of the CDs that I have ripped. How does this add upp with -- quoting from that old thread -- "..When two or more results for individual track match, the data is moved into 'confirmed' database.." ?¿

Do you understand my mind flow right now? :P

We've concluded that at least two submissions must be for a crc to go to published db. Then getting the rip result "Confidence:1" must be.. impossible? I might add I'm not 110% sure that I've gotten this result, but I _think_ that I got it once when I was ripping. Just to be clear.

Theoretical idea:
Is it so that when a track is being submitted for the very first time (discID has no previous track crcs in db), the crc will go directly into published db (as C:1)..? And then that process of wiping both _if_ the next one submitted doesn't match eg.)..?

This would explain everything.
But I'm not entirely sure.
Only you know Spoon.
Am I close?

[Spoon]

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

Correct

[Gew]

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

Aaah. That explains a lot. So, it is also so that ripped track results are never displayed as Confidence:1 (in published database) until they are verified by at least one other (so that given checksum has had a total of 2 submissions)...?

In short:
Is it -- without exception? -- so that a track is required to have more than one submission to move from raw db to published db?

[Gew]

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

There is the published database and raw database, the raw database contains all submissions.

Aaah. That explains a lot. So, it is also so that ripped track results are never displayed as Confidence:1 (in published database) until they are verified by at least one other (so that given checksum has had a total of 2 submissions)...?

[Spoon]

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

There is the published database and raw database, the raw database contains all submissions.

[Gew]

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

Perhaps not completely out in the blue.

Is it so that AccurateRip somehow "remembers" no. 1 & 3 (eg. the fact that they have been submitted one time each), so that they won't have to appear in (two) subsequent rips/submits to come..? That would change the fact that AR consistently looks for subsequent crcs.

[Gew]

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

1 and 3 would only appear after another person verifies.

But it is there, somwhere in db, although it doesn't appear. It just waits for a second submitter, right?

However, I've ripped some disc that gave me only "Track ripped OK! [CRC] (Condience:1". How do I know when Confidence:1 means that only one person has submitted the track, or that it has in fact been verified by another?

Sigh, it's still pretty confuzing. Just as I thought I had it right, this wonder-cloud..

In what case (any at all??) does Confidence:1 mean that only one person has submitted a track? Or does tracks submitted by one person only (no 2nd submit/verification) "hide" from ppl ripping other crc in AR db?

[Spoon]

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

1 and 3 would only appear after another person verifies.

[Gew]

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

Forget different pressings for now, it complicates:

A guy rips a disc and gets an incorrect rip as [BBBBBBB] (because of scratch), it submits and this result is in the db. You rip correctly get [AAAAAAAA], submit, now neither results are in the db, 3rd guy rips and submits [AAAAAAAA], now only [AAAAAAAA] appears.

This will -- seriously -- be the last piece of this -- much neurotic (I know) -- "scenario puzzle" that has been bugging me. Your process rendering above is very good. However, you verified that C:1 results are in a hang-loose state, whereas results of any higher confidence level is kinda stuck like glue in db.

Let's assume your scenario above, but let's include (another) rip crc with a Confidence of 100 or so, in between [A..] and [B..], call this one [C..] for simplicity.

Is this "ignored" (but just added: Confidence:101) in between the process of wiping subsequent 1-submit-only crc's?


Example:

1. A guy rips a disc and gets an incorrect rip as [BBBBBBB] (because of scratch), it submits and this result is in the db (Confidence:1).

2. A guy rips a disc and gets a correct rip as [CCCCCCCC] (Confidence:100), it submits and this result in the db (Confidence:101).

3. You rip correctly get [AAAAAAAA], submit (Condidence:1).

Now, will -- still -- C:1 rips (no. 1 & 3) get wiped after submitting no. 3? Even though there has come a well validated rip crc in between..?

[Spoon]

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

Correct.

[Gew]

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

Nice!

So, you could say that, not only that it's not of very high reliability, but tracks you get "Confidence:1" on is always in sort of a "hang-loose state", meaning they could be wiped at anytime. Whereas tracks from which you get Confidence:2,3,4,5... is more or less "permanent" in database. Correct?

[Spoon]

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

100% correct, it is a simple concept which works well.

[Gew]

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

Okey!

...now only [AAAAAAAA] appears.

It appears with Confidence:1 then? Or does it somehow go directly from complete db absence to Confidence:2?


Also, just so that I've gotten it right.
Assuming complete blank sheet in db now..
If a guy rips [AAAAAAAA], and the next guy rips [AAAAAAAA] aswell, Confidence leaps from 1 to 2, simple as that.

_whereas_

If a guy rips [AAAAAAAA], and the next guy gets a different checksum (i.e. [BBBBBBBB]), then [AAAAAAAA] (and [BBBBBBBBB]) is wiped. In short, database is always looking for -- subsequent -- similar checksums, and to prevent garbage sums it keeps wiping only-once-occurring sums.

Correct?

[Spoon]

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

Forget different pressings for now, it complicates:

A guy rips a disc and gets an incorrect rip as [BBBBBBB] (because of scratch), it submits and this result is in the db. You rip correctly get [AAAAAAAA], submit, now neither results are in the db, 3rd guy rips and submits [AAAAAAAA], now only [AAAAAAAA] appears.

[Gew]

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

Scratches are removed from the database when two people verify the rip, the 3rd scratch result would not make to the database.

I'm reading the line over and over, trying to visualize the process. I think I may be complicating it to myself. Examples are nice though, so here goes.

I rip a track from a disc, EAC gives me the "OK [1234ABCD]" but also states that "track is not in database". Then, is the track now added to database "queue", so that when I rip the track (submit it) with the same system roughly a month later, I get Confidence:1 after ripping, after only one single submission..?

Then, say I have another pressing of the same album (belonging to the same cuesheet "folder" in database). I pop the disc and rip the same track. Now, I assume I would get a notice with i.e. "Track could not be validated [4321DCBA]" plus "AR returns: [1234ABCD]".

It's really around here my confusion starts.Say I then rip the second pressing again from another computer. A month later, any ripping of this disc track would give me "Track validated [4321DCBA]".

This is where you tell me that the original crc (1234ABCD) is wiped out of database, due to only Confidence:1. So, from here on, that second pressing is the only one in database for "cuesheet folder" in db, yes?

Then, let's say I rip that original disc track again, from another computer than before, then you tell me that the Confidence:1 was wiped out of db as two people (computers*) verified the ECBA4321 pressing.

So, even though the earlier submission of ABCD1234's, it's now back on Confidence:1. However, now both ABCD1234 & DCBA4321 checksums exist, side by side, in that [my own term of expression] "cuesheet folder" in database.

So, have I gotten it right this far?

Now, finally.

Take the possibility that I get a hold of a 3rd pressing of the album. I rip it aswell. After ripping I get i.e. "Could not be verified [11223344], AR returned [either 1234ABCD or DCBA4321]". I submit my rip.

Also, one thing that seems a bit mysterious.
Picture this, from scratch; e.g. blank sheet for TOC in database.

ABCD1234 is ripped and submitted. (1x)
DCBA4321 is ripped and submitted. (1x)
11223344 is ripped and submitted (1x).

All three pressings are ripped but none of them are (yet) verified. Will all three be present with Confidence:1, until..? Say I submitt one of them, for example DCBA4321 a second time (weee; validation!). Will this validation then "knock out" both ABCD1234 and 11223344 completely?

Ty for your patience.
Regards~