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]

Greynol:
I know all this, but still I use AR2 for safety, because as far as I understund AR1 rip can vanish from the database due to the way it works ... I have noticed this several times ... AR1 seems to be pending rips ... starting at AR2 the rips never vanish from the database (well so far I haven't noticed any AR2+ vanishing from the database. Edit: Outside of purges indeed) ... also I use AR2 as a reference even more now as CTDB accept submission starting at AR2. If I ever find AR2 faulty be sure I'll complain to the boss !

So even if AR1 is enougth if you own the CD, in the end the fact that a rip can be AR1 in April & not in database in May makes you feel that AR1 is not enougth.

I am not sure but I think I already used this shorthand with Gregory & we did understund each other I think, maybe it would be harder with Spoon. But I thought the whole idea behind AR2 (the new database I mean here) was forgotten for now anyway.

Greynol:

independent of one another

Well CTDB is AR dependent.
There is not much to understand in CTDB. It's either the rip is in database or it's not. Once it is in database it's either it's fixable or not ...

This post has been edited by sauvage78: May 24 2010, 23:17

[greynol]

A confidence of one that vanished is really no better than a confidence of one that did not vanish, or any better than a confidence of two provided it was not your previous submission.

If I ever find AR2 faulty be sure I'll complain to the boss !

You might want to say something other than AR2 or you might confuse him.

So even if AR1 is enougth if you own the CD, in the end the fact that a rip can be AR1 in April & not in database in May makes you feel that AR1 is not enougth.

Speak for yourself, it doesn't make me feel that way.

CTDB is AR dependent.

How so exactly? Must there be a record in the AR database for something to be in the CT database?

This post has been edited by greynol: May 24 2010, 23:22