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]

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.

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

[greynol]

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?

This post has been edited by greynol: May 25 2010, 18:38