CTDB stores only one record for all pressings.
This also answer the question of Greynol of how can I know that this rip is unlikely to be accurate.
for me it is logic as an AR1+a CD in CUERipper means that the submission in AR is not from the same guy
pressings can differ by more than just an offset.
Different pressings of the same CD are treated as the same disc by the database, it doesn't care.
Unless that guy previously ripped that disc with EAC or dBpoweramp and submitted that result to the database.
[Verification date: 11/05/2010 16:06:17][AccurateRip ID: 000e88eb-0066551d-6c10b009] found.CD-Extra data track length 18:07:07.[CTDB TOCID: zmFGQm66ZqbXROW4CQDK4zA7T0s-] found. [ CTDBID ] Status [8217dca2] (240/249) Accurately ripped [8217dca2] (009/249) , Accurately ripped
[Verification date: 11/05/2010 16:07:20][AccurateRip ID: 000f43d8-00696936-770f5a09] found.CD-Extra data track length 18:56:32.[CTDB TOCID: LUb_4tK_Z4HQ0HbzmnB2HcDeoIc-] found. [ CTDBID ] Status [0ea56824] (241/252) Accurately ripped [0ea56824] (011/252) , Accurately ripped
So anyway it seems CTDB knows how to avoid clash & deal with "pressings that differs by more than just an offset" inside the same CTDB TOCID.
I know it, pressings that differs by more than just offset often have another ID.
2: CTDB seems to be able to deal with "pressings that differs by more than just offset" by storing a 2nd checksum in case it detects a 2nd "pressings that differs by more than just offset"
QuoteUnless that guy previously ripped that disc with EAC or dBpoweramp and submitted that result to the database.If the scratch is real, the results are not supposed to match anyway.
CTDB knows the results in AR cannot be the same as the actual CD in CUERipper as CUERipper cannot submit to AR.
CUERipper has absolutely no way of knowing if that particular physical CD was previously ripped with EAC or dBpoweramp and the results were submitted to the AR database.
So to answer Skybrowser, the only possibility I see for his rip to be accurate & not match CTDB is that he owns a rare pressing that differs by more then just the offset & is not in AR database in the same time. It is possible but unlikely.
I am not sure how to interpret these numbers but from what I understand the huge difference between 337 & 39, seems to be a positive hint about the fact that you might have a different pressing that differs by more than the offset ... but again I am 100% unsure about how to read these numbers.
I agree with this but as CTDB knows that even in this case the result cannot be the same, it doesn't matter, if it matches with the AR1 result, then CTDB considers it as if it was AR2, if it doesn't match, then CTDB ignore it as noise.
I'm pretty sure this is not correct.
Ignoring that the result can actually be the same but yet still be in error
As I said you may disagree with the "unlikely" conclusion, here this is a feeling based on experience, I know this is irrationnal to you, but it is like poker: the more you play, the more you know the probability of your hand to win. I update a folder full of 140go of non accurate rips every months the numbers of rips which suddenly become accurate is very low.
Unless the guy is stupid & rerip with cueripper a scratched CDR he submitted to AR previously with EAC or dbpoweramp
the data cannot match because as I explained scratched data cannot match between two different rips.
When you rip a commercial CD you own with EAC & that you match with an AR1 submission that is not yours, you know that the CD is not scratched.
I don't understand why you don't admit that the same happens with cueripper & AR1.
After ripping the album it said rip in-accurate AR 0/13. CTDB not in database.
since yours does not match AR, then it will not add to CTDB
low and behold there was now a CTDB confidence of 1 for my album.
Discs don't have to pass AR before being added to the CTDB, AR is used only as a kind of proof that there is a physical CD with such content when adding with CUETools.CD Rippers can add CDs to CTDB even if AR doesn't know them. There is already a number of CDs in database submitted by CUERipper, some of them have confidence 1 - that means they didn't pass AR check or weren't found in AR.
I thought all this was obvious, I can't fathom that it took this long in the thread for someone to point it out.
It the same situation as accurate rip confidence of 1, when it was your own submission.