IPB

Welcome Guest ( Log In | Register )

CTDB question: Repair function
Skybrowser
post May 24 2010, 22:19
Post #1





Group: Members
Posts: 52
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
Go to the top of the page
+Quote Post
 
Start new topic
Replies
sauvage78
post May 25 2010, 11:05
Post #2





Group: Members
Posts: 677
Joined: 4-May 08
Member No.: 53282



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
[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
[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


--------------------
CDImage+CUE
Secure [Low/C2/AR(2)]
Flac -4
Go to the top of the page
+Quote Post
greynol
post May 25 2010, 18:20
Post #3





Group: Super Moderator
Posts: 10025
Joined: 1-April 04
From: San Francisco
Member No.: 13167



QUOTE (sauvage78 @ May 25 2010, 03:05) *
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 (sauvage78 @ May 25 2010, 03:05) *
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 (sauvage78 @ May 25 2010, 03:05) *
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 (sauvage78 @ May 25 2010, 03:05) *
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 (sauvage78 @ May 25 2010, 03:05) *
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.

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


--------------------
Your eyes cannot hear.
Go to the top of the page
+Quote Post

Posts in this topic
- Skybrowser   CTDB question: Repair function   May 24 2010, 22:19
- - sauvage78   Plz post the complete cuetools log so that we can ...   May 24 2010, 22:31
- - greynol   AR2?   May 24 2010, 22:44
- - sauvage78   Short for Accurate with confidency confidence 2. ...   May 24 2010, 22:46
- - greynol   Some sort of shorthand you've made up, I suppo...   May 24 2010, 22:50
- - sauvage78   Greynol: I know all this, but still I use AR2 for ...   May 24 2010, 23:02
|- - greynol   A confidence of one that vanished is really no bet...   May 24 2010, 23:17
- - sauvage78   QUOTE How so exactly? Just like you said Greg uses...   May 24 2010, 23:24
|- - greynol   QUOTE (sauvage78 @ May 24 2010, 15:24) Ju...   May 24 2010, 23:27
|- - greynol   QUOTE (sauvage78 @ May 24 2010, 15:24) Ye...   May 24 2010, 23:28
- - sauvage78   Yes you're right, but I think this is temporar...   May 24 2010, 23:36
- - greynol   I think Gregory would take exception to the idea t...   May 24 2010, 23:40
- - sauvage78   He never said that, it was just obvious to me. In...   May 25 2010, 00:18
- - greynol   So is the answer as simple as the OP's disc no...   May 25 2010, 00:39
- - sauvage78   Yes, as far as I understund, it can be as simple a...   May 25 2010, 00:50
- - Skybrowser   Ok.... well following that massive discussion betw...   May 25 2010, 02:08
|- - greynol   QUOTE (Skybrowser @ May 24 2010, 18:08) -...   May 25 2010, 02:46
- - sauvage78   With your last cuetools log: this rip is not accur...   May 25 2010, 02:39
|- - greynol   QUOTE (sauvage78 @ May 24 2010, 18:39) Wi...   May 25 2010, 02:50
|- - Skybrowser   - My drive offset in logfiles for ripping is 667. ...   May 25 2010, 03:00
- - sauvage78   I may be wrong but I think that CTDB still require...   May 25 2010, 02:53
|- - greynol   QUOTE (sauvage78 @ May 24 2010, 18:53) fo...   May 25 2010, 08:57
- - sauvage78   Well what is likely or not is only a question of p...   May 25 2010, 03:01
- - sauvage78   Ok I completely forgot that it was a CDR, well for...   May 25 2010, 03:03
|- - Skybrowser   I already have a few encountering this situation. ...   May 25 2010, 03:41
- - sauvage78   The ability of CTDB to repair damaged rips is rand...   May 25 2010, 03:48
|- - Skybrowser   Ah, at first i didnt really realize why you were p...   May 25 2010, 04:18
- - sauvage78   No, as far as I understund how CTDB works, it is d...   May 25 2010, 04:37
|- - greynol   QUOTE (sauvage78 @ May 24 2010, 20:37) Th...   May 25 2010, 08:45
- - sauvage78   QUOTE pressings can differ by more than just an of...   May 25 2010, 11:05
|- - greynol   QUOTE (sauvage78 @ May 25 2010, 03:05) So...   May 25 2010, 18:20
- - sauvage78   As I couldn't found any rip with 2 CTDBID for ...   May 25 2010, 17:53
|- - greynol   QUOTE (sauvage78 @ May 25 2010, 09:53) So...   May 25 2010, 18:30
- - sauvage78   QUOTE CUERipper has absolutely no way of knowing i...   May 25 2010, 18:28
|- - greynol   QUOTE (sauvage78 @ May 25 2010, 10:28) I ...   May 25 2010, 18:32
- - sauvage78   As I said you may disagree with the "unlikely...   May 25 2010, 18:37
|- - greynol   QUOTE (sauvage78 @ May 25 2010, 10:37) As...   May 25 2010, 18:50
|- - greynol   QUOTE (sauvage78 @ May 25 2010, 10:37) Un...   May 25 2010, 19:08
|- - Skybrowser   Ok, I think i've finally gotten lost in you gu...   May 26 2010, 22:55
|- - Teknojnky   QUOTE (Skybrowser @ May 26 2010, 15:55) A...   May 26 2010, 23:04
- - greynol   QUOTE (Teknojnky @ May 26 2010, 15:04) si...   May 26 2010, 23:14
- - Teknojnky   cuetools ripper can add to CTDB without the aid of...   May 26 2010, 23:18
|- - greynol   QUOTE (Teknojnky @ May 26 2010, 15:18) I ...   May 26 2010, 23:25
- - sauvage78   There is a reasonnable chance that this new rip is...   May 26 2010, 23:20
- - greynol   Since neither of you could be bothered to look up ...   May 26 2010, 23:24
- - Teknojnky   It the same situation as accurate rip confidence o...   May 26 2010, 23:24
- - Teknojnky   like I said, cue ripper can add to CTDB without A...   May 26 2010, 23:28
- - greynol   Yes, thank you. Unfortunately you failed to provi...   May 26 2010, 23:34
- - sauvage78   Well then this is a flaw of CTDB, I thought Greg w...   May 26 2010, 23:38
|- - greynol   QUOTE (sauvage78 @ May 26 2010, 15:38) Ye...   May 26 2010, 23:46
- - Teknojnky   I suggest you reference them as AR (1) and AR (2) ...   May 26 2010, 23:42
|- - Skybrowser   Greynol, I wasn't attempting to fabricate any ...   May 26 2010, 23:56
- - sauvage78   I like the idea I will use AR(2) from now on. Edi...   May 26 2010, 23:46
|- - greynol   QUOTE (sauvage78 @ May 26 2010, 15:46) we...   May 27 2010, 00:05
- - greynol   My comment wasn't directed at you. It was at ...   May 26 2010, 23:58
- - Gregory S. Chudov   Back to original topic: QUOTE (Skybrowser @ ...   May 27 2010, 21:22


Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 21st October 2014 - 17:30