CTDB question: Repair function
CTDB question: Repair function
May 24 2010, 22:19
Joined: 7-January 10
Member No.: 76815
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
May 25 2010, 11:05
Joined: 4-May 08
Member No.: 53282
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:
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".
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).
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.
[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
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.)
This post has been edited by sauvage78: May 25 2010, 11:46
|Lo-Fi Version||Time is now: 4th July 2015 - 02:42|