CTDB question: Repair function Options

[Skybrowser]

First off, i'd like to say that CTDB is probably the most useful and amazing tool i've seen since i started doing DAE a few months ago. Thankyou so much for creating something that can repair bad rips or essentially .. damaged CDs.

I've started using the CTDB repair function and i'm absolutely loving it. I'm struggling with a certain feature of it right now though.

Some of the albums I want to repair are showing up in the CTDB but when I attempt to verify them, it says for example " AR: offset 112, rip not accurate (0/116), CTDB: could not be verified ".

Now this seems to be happening pretty much only for albums where the accuraterip log shows matches for multiple offsets and the CTDB repair function won't activate and encode my files because it doesnt know which offset to use. I tried telling cuetools what offset to use in order to force the encode, but it wouldnt do it. I tried fixing the offset of the files just incase that was causing it, but that wouldnt do it either. Now I know the repair function can only repair a certain amount of errors, but for these albums i dont think the error count would be that high. I think the CTDB just gets stuck when it doesnt know which offset to use..... which is weird, because if you look at the bold text above, cuetools + AR is able to figure out the right offset. Is there a way of telling the CTDB to use the offset that AR is seeing and then repairing the damaged tracks? This situation doesnt happen in all cases with multiple offsets, but just mostly when there is a large number of offsets or the confidence for track matches are quite similar for each of the offsets
Again, this DB is awsome. If you have the time to populate it with your verified albums then please do so, because everyone benefits in the end.

This post has been edited by Skybrowser: May 24 2010, 22:27

[sauvage78]

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.

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 !

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

This post has been edited by sauvage78: May 25 2010, 18:49

[greynol]

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.

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.

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.

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.