Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: CTDB question: Repair function (Read 33785 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

CTDB question: Repair function

Reply #25 –
Ah, at first i didnt really realize why you were putting emphasis on different pressings, but I think i understand now. Just because that specific pressing is in AR and the album is in CTDB doesnt mean that specific pressing of the album is in CTDB even though it is in AR. Ok so because CTDB is quite new, i guess i'll have to wait alot longer for it to become more populated. Maybe if someone made a tool that could tell you the number of errors on an album and we could get an error count on what CTDB is able to repair then we could know whether we can fix an album or not.

Alright thanks for all the info guys, i guess i'll just wait it out for now.

CTDB question: Repair function

Reply #26 –
No, as far as I understund how CTDB works, it is designed to be "cross-pressing" or "offset independent" if you prefer, so even if your rip/pressing is not in the AR database, the fact that it doesn't match with CTDB means that you will never be able to fix it with the actual amount of data/strenght of CTDB. In other word your rip can suddenly appear in AR database & it should still not be fixable in CTDB.

In other words, because CTDB doesn't recognize your rip, it is very unlikely that your rip is accurate because the fact that CTDB doesn't recognize your rip cannot be due to a simple offset difference.

This also answer the question of Greynol of how can I know that this rip is unlikely to be accurate.

Warning: All the above rely on the fact that my understanding of CTDB is right, actually I am not 100% sure that CTDB is offset independent. Read this post & the whole discussion around (read down to the conclusion post #55) to be sure that you understand it like me.

Gregory: (from the linked discussion)
Quote
CTDB stores only one record for all pressings.


As far as I understund CTDB ignore a "big" (by "big" read bigger than any offsets) part of the beginning & end (10 frames) of the CD in order to be offset independent by focusing on the "heart of the CD". That's how I understund it, if I am wrong then the above is wrong.

CTDB question: Repair function

Reply #27 –
Quote from: sauvage78 on
This also answer the question of Greynol of how can I know that this rip is unlikely to be accurate.

The fact of the matter is that you don't know; pressings can differ by more than just an offset.

Besides what I explained in my previous post (click removal/EQ/level change/compression/etc.), data can change between pressings as the result of corrupted data.

CTDB question: Repair function

Reply #28 –
Quote from: sauvage78 on
for me it is logic as an AR1+a CD in CUERipper means that the submission in AR is not from the same guy

Unless that guy previously ripped that disc with EAC or dBpoweramp and submitted that result to the database.

By that logic, the same goes with non-CUERipper extractions as well.  Your AR results aren't instantly sent to the database, so if you get a confidence of one and you aren't the same guy, your submission would make two, but only after it is incorporated into the database.  This is precisely why a confidence of one is all that matters unless it's your own previous submission.  Now even if it was your own previous submission, the fact that you got the same result a second time gives you the same level of security as if you had used test and copy and got matching checksums.

CTDB question: Repair function

Reply #29 –
Quote
pressings can differ by more than just an offset.

I know it, pressings that differs by more than just offset often have another ID.

But even if it has the same ID:
I don't know exactly how the CTDB TOCID is calculated compared to the AccurateRip ID but I know that
1: Greg stated several times that:
Quote
Different pressings of the same CD are treated as the same disc by the database, it doesn't care.
from CTDB's about.
He doesn't seems to make any difference between pressing that differs by just offset & others.

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"

I may be completely wrong on 2, but I recall I already saw a rip with 2 CTDBID for 1 CTDB TOCID.
I don't recall exactly but I think I saw this on an enhanced CD.

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. As far as I understund CTDB uses two ID specially to deal with "pressings that differs by more than just an offset".

Quote
Unless 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. By accepting AR1 rips from CUERipper, Greg only exploits this. CTDB knows the results in AR cannot be the same as the actual CD in CUERipper as CUERipper cannot submit to AR. CTDB also knows that if there were a real scratch it shouldn't match with the AR1 results anyway. So it concludes the rip is AR2 even if not actually AR2 in the AR database. It's a trick but it's logic.

I never said that AR1 wasn't enought in some case, I said that personnaly I don't want to bother with keeping record of rip that were already AR1 when I ripped them. Specially as I don't check AR while ripping (I delete EAC logs) but afterward (by keeping cuetools logs).

Edit:
I searched my enhanced CD for an example of two CTDBID inside the same CTDB TOCID, but I noticed that the CTDBID is in fact same ... so I don't have any example that would proves my claim, but I suspect it works this way.

All I could find are examples like this. Which doesn't really illustrate what I suspect.
Code: [Select]
[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


Code: [Select]
[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


Still a mix of CTDBID+the numbers in parenthesis seems to be used as an additionnal ID, to keep record of both the enhanced & non enhanced pressings. I am only guessing that the same kind of trick is used in case of pressings that differs by more than just offset.

Actually I think that the CTDB is too small for me to find an exemple, but time will tell if my intuition is right. I don't deny that I can be wrong, CTDB is still very young & it's hard to get some reliable knowledge about it as it is spreaded among plenty of posts (& personnaly also as I am not a native english speaker.)

CTDB question: Repair function

Reply #30 –
As I couldn't found any rip with 2 CTDBID for 1 CTDB TOCID in my own collection, I had the idea of searching within the most popular releases in the CTDB homepage by sorting CTDB TOCID, I quickly found this link & this link & many more, so unless someone disagree, it seems to back up what I think.

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.

The only thing that remains to be analysed are the numbers in parenthesis, (337/337) in CTDB vs. (039/540) in AR ... I am not very familiar with the CTDB numbers but I will have a look.

Edit:
The explanation of these CTDB numbers is here

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.

CTDB question: Repair function

Reply #31 –
Quote from: sauvage78 on
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 think the point is escaping you.  This is about knowing for certain whether a rip with tracks that don't match are not accurate.

Quote from: sauvage78 on
I know it, pressings that differs by more than just offset often have another ID.
I never said it didn't.  I just said that there can be differences between different pressings of the same title that differ by more than just an offset.  The differences can actually be so minor that the the database might fix one to match the other, despite the fact that both are accurate and it could be that what was being fixed might be the one that is more desirable.

Quote from: sauvage78 on
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"
Sure, and I see no reason why it can't or why it shouldn't.  AR had this ability already, in the case of CT, there's the the additional data for correction.

Quote from: sauvage78 on
Quote
Unless 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.
Why even care about AR since test and copy would handle results that do not match because of a scratch?  The fact of the matter is that errors resulting from a scratch (or some other problem that might not be due to a scratch!) can be consistent.

Quote from: sauvage78 on
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.  If it does, please tell me how.

CTDB question: Repair function

Reply #32 –
Quote
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.

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.

CTDB question: Repair function

Reply #33 –
Quote from: sauvage78 on
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 want to see how you arrived at the unlikely part, sauvage78.  The pressing may only be "rare" in the context of AR, which as plenty of people tell you does not contain information about every disc ever produced.  When U2 releases a CD and sells millions of copies on the first day, would you call it rare because there are no results in the AR database the next day if not the next week?

Quote from: sauvage78 on
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'm pretty sure this is not correct.

CTDB question: Repair function

Reply #34 –
Quote from: sauvage78 on
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.

Ignoring that the result can actually be the same but yet still be in error, can you provide a link to where you learned this "fact" about what CTDB considers and what it ignores?

CTDB question: Repair function

Reply #35 –
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.

Quote
I'm pretty sure this is not correct.

Me too but I specially posted this for people to teach me what to do with these numbers !

Quote
Ignoring that the result can actually be the same but yet still be in error

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. No I don't have a link sorry. I don't know how to explain better.

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 know you know this. I don't understand why you don't admit that the same happens with cueripper & AR1. It's the same.

Again it seems only Greg can save my soul

CTDB question: Repair function

Reply #36 –
Quote from: sauvage78 on
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.

This is not so much about rationality.  As I said to you before, you don't seem to be aware of the bigger picture when you're presenting something as if it were a fact.

Backing off from this, I would simply say if I were in the OP's situation, rips without a log, especially those from CD-R to me would be suspected bad unless proven otherwise.

CTDB question: Repair function

Reply #37 –
Quote from: sauvage78 on
Unless the guy is stupid & rerip with cueripper a scratched CDR he submitted to AR previously with EAC or dbpoweramp
or the data used to burn the CD-R was in error.

Quote
the data cannot match because as I explained scratched data cannot match between two different rips.
Provided you mean rips from two different physical CDs, the odds of the same exact error from a unique scratch IMO cannot possibly be significant, I suspect they're even lower than the odds of an AR hash collision which, assuming the analysis that is often presented is correct, is on the order of one in a few billion.

Quote
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 know if a CD is scratched by looking at it, not by what the AR numbers are.  As I've tried to tell you there are more reasons for errors than just a scratch, but I digress.

Quote
I don't understand why you don't admit that the same happens with cueripper & AR1.
Actually what I'm asking of you is where you're getting this impression that CUERipper does something unique with results with an AR confidence of one.  I also want to revisit whether CUERipper submits information to CTDB when there is no AR record, there is an AR record but it does not provide a match unless an offset is applied within a given range, and when there is an AR record but it doesn't provide a match and cannot provide a match when an offset is applied within a given range.

CTDB question: Repair function

Reply #38 –
Ok, I think i've finally gotten lost in you guys' discussion. My original question was basically about why CTDB wouldnt repair certain CDs, and how do i know if a CD is beyond repair or if something else is wrong and CTDB is confused by my CDRs.

But I picked up on something one of you said in an earlier reply and just today i came across an example of it. I think one of you said that cueripper automatically adds albums to the CTDB or something to that effect. 
    - Well just today i decided to try using cueripper to rip an album and just play around with it. After ripping the album it said rip in-accurate AR 0/13. CTDB not in database. Now i've had this same result for this album using EAC. Track 1 simply won't verify. This IS NOT a CDR. The Test and Copy CRC's matched, and the tracked quality showed 100% ... which doesnt necessarily mean anything because cueripper was on paranoid mode and will do ALOT of retries.  Cueripper said it submitted my data to CTDB...... even though my rip was in-accurate according to AR confidence 13. I thought this odd so i went into cuetools and did a verify ... and low and behold there was now a CTDB confidence of 1 for my album. Now maybe CTDB is smarter than I am, and I really do have a different pressing of this album. I actually burned this album years ago, and I cant get the first track on the burn to verify either.... so that could be evidence for a different pressing.... unless the original was damaged before i burned it.

I'm thinking of trying the same thing with a couple of other albums i'm having problems with. I'll let you know what happens if i do.

CTDB question: Repair function

Reply #39 –
Quote from: Skybrowser on
After ripping the album it said rip in-accurate AR 0/13. CTDB not in database.



what this means is very simple.

there are 13 entries in accurate rip
your rip does not match any them
there are no entries in the CTDB
since yours does not match AR, then it will not add to CTDB

that is all.

CTDB question: Repair function

Reply #40 –
Quote from: Teknojnky on
since yours does not match AR, then it will not add to CTDB

Quote from: Skybrowser on
low and behold there was now a CTDB confidence of 1 for my album.

Teknojnky, sauvage78:
Please post evidence for your conclusions about what gets added to CTDB.  It would appear that your assumptions are erroneous.

CTDB question: Repair function

Reply #41 –
cuetools ripper can add to CTDB without the aid of AR

in order for cuetools to add to CTDB, it requires accurate rip to have a confidence of 2, and your rip has to match 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.

CTDB question: Repair function

Reply #42 –
There is a reasonnable chance that this new rip is ok. Just wait for it to appear in AR.

As for why this non-accuraterip was accepted in CTDB, I dunno. I thought this kind of rip would have been rejected so maybe Greynol is right.

In case CTDB accept non accurate rip (I never tried by myself), my guess is that Greg store the necessary info in order to re-test the accuracy of your rip later. My guess is that maybe Greg does that in order to help populate the database as long as it is small & easy to backup. Later when the database will become too big, Greg will re-check these rip against the AR database & purge those which are definitely not AR. In the process some CTDB submissions that would otherwise have been rejected might be saved. This is the only clever explanation I see.

If it doesn't work like that then Greg is polluting his own database. Ask Greg, I think he is the only one who can answer what he is doing with his non accurate CTDB entry.

CTDB question: Repair function

Reply #43 –
Since neither of you could be bothered to look up some facts and have instead decided to fabricate your own, I've done some legwork for you:
Quote from: Gregory S. Chudov on
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.

In case it isn't obvious, I am quite annoyed by the misinformation!

CTDB question: Repair function

Reply #44 –

It the same situation as accurate rip confidence of 1, when it was your own submission.

CTDB question: Repair function

Reply #45 –
Quote from: Teknojnky on
I thought all this was obvious, I can't fathom that it took this long in the thread for someone to point it out.

Yes and it was I who pointed it out in the ninth post in this discussion.

CTDB question: Repair function

Reply #46 –
like I said,

cue ripper can add to CTDB without AR

cue tools will not add to CTDB unless a) the rip is in AR, b) there is more than 1 confidence, c) your rip matches AR

CTDB question: Repair function

Reply #47 –
Yes, thank you.  Unfortunately you failed to provide the correct information in your first reply to this discussion.  Skybrowser was talking about CUERipper, not CUETools.

CTDB question: Repair function

Reply #48 –
Well then this is a flaw of CTDB, I thought Greg wouldn't have made this misstake.

Quote
It the same situation as accurate rip confidence of 1, when it was your own submission.


Yes, the problem is that an AR1 rip is in fact not accurate if it's your own submission. I keep a folder of 100go of AR1 rips, every months some of them become "not present in database". This seems to be due to the way AR works if the second submitter disagree with the first, then both disapear as long as a 3rd one come up & agree with one of the 2 first, then it becomes AR2. If it's your own AR1 submission then you know nothing ...

Keeping those AR1 rips which may not be accurate is not the behavior I would have expected from CTDB, it only creates noise. Some of this noise may be good but some will certainly be bad.

I'd like Greg to purge these entries from CTDB  just like Spoon purged virtual drive from AR.

CTDB question: Repair function

Reply #49 –
I suggest you reference them as AR (1) and AR (2) to avoid confusion between accuraterip version 1 and version 2.