Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: CTDB question: Repair function (Read 33785 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

CTDB question: Repair function

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.

CTDB question: Repair function

Reply #1 –
Plz post the complete cuetools log so that we can understand you with "your offset fixing thing" ... which is chineese to me right now

As far as I understund what you meant: If the rip doesn't get accurate result for all tracks within the same offset it cannot be AR2 hence it cannot be repaired no matter if the tracks are all accurate separately on several different offsets (which happens sometimes). In this case it can be repaired but only if it is really damaged not if the fact that it is not AR2 is due to holes in the AR database.

Without any additionnal clue that there is a real scratch (a bad EAC log) you rip could be perfect & yet not in the AR database ...

I dunno if what I said matches your case but all I say is that you didn't provided enougth information to conclude anything.

CTDB question: Repair function

Reply #3 –
Short for Accurate with confidency confidence 2.

Myself:
Quote
If the rip doesn't get accurate result for all tracks within the same offset it cannot be AR2 hence it cannot be repaired no matter if the tracks are all accurate separately on several different offsets (which happens sometimes).

This whole sentence is not really worded correctly anyway ... I say it cannot be repaired & then I say it can  ...

Skybrowser:
Quote
CTDB repair function won't activate and encode my files because it doesnt know which offset to use.

As I tried to explained with bad words, CTDB knows that it knows nothing, so it does nothing.

CTDB question: Repair function

Reply #4 –
Some sort of shorthand you've made up, I suppose.  AR2 has already been taken for the next generation of AccurateRip, so I think you might want to come up with something else.

Regardless, we already know that a confidence of one is all you need provided it wasn't your previous submission, barring consistent errors due to manufacturing defect, software bug or firmware bug; in which case a confidence of two is still no guarantee.

EDIT:
The reason I asked is that you gave me the impression that spoon has somehow adopted CTDB as part of AR.  Knowing now that this is not the case, I think I should point out to the OP that AR and CTDB are two different databases, independent of one another.  Just because you might get a hit against the AR database does not mean you'll be able to fix the title with CTDB.  Perhaps this is already known to the OP; I'm not all that familiar with the new lingo since CTDB has not yet been able to help me with a bad rip and because I have very few titles that need to be fixed, I have very little experience with it.

CTDB question: Repair function

Reply #5 –
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:
Quote
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 ...

CTDB question: Repair function

Reply #6 –
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.

Quote
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.

Quote
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.

Quote
CTDB is AR dependent.
How so exactly?  Must there be a record in the AR database for something to be in the CT database?

CTDB question: Repair function

Reply #7 –
Quote
How so exactly?

Just like you said Greg uses AR2 to accept submission, so no AR no CTDB simply.
Without AR2 there would be no way to dismiss noise (scratched submission) from CTDB.

I think it would technically be possible to create an independent CTDB, by comparing submissions, but it would be hard for Gregory for no gain as AR already does that. To be short if Greg would have made CTDB independent he would have needed to reinvent the wheel ... the wheel being AR.

Edit:
You were faster:
Quote
Must there be a record in the AR database for something to be in the CT database?

Yes AR2 in AR database before being accepted in CTDB ... I learned something to Greynol ! unbelievable

Quote
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.

I am not sure that I get what you meant but a confidence of 2 no matter if one is your own "precious" submission is better than a confidence of 1 because a confidence of 1 is almost like no confidence at all for me ... as it can disapear. To trust AR1 you have to keep records of what you submitted to the database which is insane in the long time.

CTDB question: Repair function

Reply #8 –
Quote from: sauvage78 on
Just like you said Greg uses AR2 to accept submission, so no AR no CTDB simply.

I either didn't say this or have given you the wrong impression as this is not true.  CUEripper will submit to the CT database without an AR entry.

CTDB question: Repair function

Reply #9 –
Quote from: sauvage78 on
Yes AR2 in AR database before being accepted in CTDB

Actually, no, this is not right; the intention of my question was rhetorical. See my previous response.

Quote from: sauvage78 on
I am not sure that I get what you meant but a confidence of 2 no matter if one is your own "precious" submission is better than a confidence of 1 because a confidence of 1 is almost like no confidence at all for me ... as it can disapear. To trust AR1 you have to keep records of what you submitted to the database which is insane in the long time.

It is just a snapshot at any particular moment.  In the long run, a confidence of one that disappeared will eventually re-appear if it was right.  If it was right it was no less right when it disappeared.  If it wasn't your previous submission then it definitely was right.

If you suffered from a drive failure or had some other reason to re-rip your collection after a submission, then I understand.  Otherwise if you know you haven't previously submitted a disc (which is a question that is probably very easy to answer for most people) then there is no reason to throw away a log with a confidence of one to later test it to make sure it got bigger.  In my case it's simple:  I don't believe I've ever submitted to AR.  Furthermore, if I have I can pretty well guarantee that my submissions never made it to the database because I've been banned for a long time now.

So what if you've submitted more than once to the database with a different AR user ID?  Can you still trust a confidence of two? This is a rhetorical question (the answer is no). It's also a legitimate concern as I know at least one person who has and I have to agree with you: keeping a record of what you've submitted and how many times is insanity.

CTDB question: Repair function

Reply #10 –
Yes you're right, but I think this is temporary (Edit: Should have been). CTDB only accept CUEripper because Spoon doesn't accept CUEripper results in AR database. Once CUEripper will be mature enougth to be accepted in AR database then AR2 should be the norm.

Maybe Greg will always accept CUEripper results because he trust his own works, but overall the truth is that accepting CUEripper is a sort of trick. An acceptable trick.

CTDB question: Repair function

Reply #11 –
I think Gregory would take exception to the idea that it's a trick.

Perhaps you can provide a link to him saying it's just a trick and that he'll make the CT database dependent on the AR database once CUERipper is allowed to submit to the AR database?

CTDB question: Repair function

Reply #12 –
He never said that, it was just obvious to me.

In this post I argue that the CTDB confidence is an artificial number that shouldn't exist if CUERipper results were accepted in the AR database.

Greg didn't reacted to this so I assumed my assumption was right.

I may be completely wrong & Greg may disagree, it wouldn't be the first time that I would be wrong about AR & CTDB.

From a human point of view it is just logic that CTDB accepts CUERipper results, CTDB & CUERipper are time greedy for Greg & the possibility that accepting CUERipper in CTDB might help him to find bugs or even just help him improve CUERipper is the least that we can accept as a sort of "reward" for his job.

If we trust CTDB then we trust Greg's work so trusting him for CUERipper too is the least that we can do, to show him our trust.

CTDB question: Repair function

Reply #13 –
So is the answer as simple as the OP's disc not being in the database, or is it likely something else?  Again, I'm not really all that familiar with all the new logs and whatnot.

CTDB question: Repair function

Reply #14 –
Yes, as far as I understund, it can be as simple as that  As long as he doesn't provide a full cuetools log, I dunno.

I think that he has a log where all tracks are accurate separately somewhere but not on the same offset, so he thinks he can fix it. (When I was an AR beginner I tried to fix manually a rip like that (by applying offset/splitting/joining) which is a strange & funny idea to think about now  Like what the hell was I thinking of !!! Indeed it didn't work & I created a monster) If that's it ... his rip is maybe perfect, but the pressing simply not in the database. Cuetools doesn't want to fix it, as there is no evidence that it is broken.

Maybe it is something else, I dunno.

CTDB question: Repair function

Reply #15 –
Ok.... well following that massive discussion between you two wasnt easy, but I think i caught a few things here and there and i'll try to respond.

 - So far i've repaired 7 CDs, and I have about 123 to go..... sooo you can see why I'm quite passionate about this.

 - The situation I am talking about is when the rip is identified in both AR and CTDB with more than 2 confidence.

 - Like Greynol said, your use of AR2 was a tad bit confusing. I am going to assume that every time you used it, you were referring to a rip with AR confidence >2

 - Yes Greynol, CTDB submissions require AR confidence >=2

 - I thought i saw one of you mention something about a bad log file or something. Could my original EAC log files be confusing CT somehow?

 - I will give you an example. I hope it helps. This is an example of one where I didnt fix the offset. But even if i fix the offset, it just says 'cannot be verified' in cuetools for CTDB. As you can see there are 337 CTDB confidence, and around 560 AR confidence.

Code: [Select]
[CUETools log; Date: 24/05/2010 5:27:41 PM; Version: 2.0.9]
[CTDB TOCID: be8vy8P3FbyY5zsvkRW5op85K_o-] found.
        [ CTDBID ] Status
        [4135cf03] (337/337) No match
[AccurateRip ID: 0017deff-00cf9b72-890dd20b] found.
Track   [ CRC    ] Status
 01     [8164b9a6] (000/562) No match
 02     [8d6e86c8] (000/563) No match
 03     [1ad0833b] (000/565) No match
 04     [458425a6] (000/565) No match
 05     [b2b0db89] (000/568) No match
 06     [b87e1bef] (000/562) No match
 07     [c4209825] (000/557) No match
 08     [de139d6c] (000/566) No match
 09     [ab4603ce] (000/563) No match
 10     [49f419f5] (000/558) No match
 11     [71e15541] (000/540) No match
Offsetted by 112:
 01     [4e5b16c2] (039/562) Accurately ripped
 02     [3cf51194] (039/563) Accurately ripped
 03     [c9ba3e97] (039/565) No match but offset
 04     [fc7c30b5] (040/565) Accurately ripped
 05     [a548029a] (040/568) Accurately ripped
 06     [e4ed989c] (038/562) No match but offset
 07     [3f9d7f5d] (039/557) No match but offset
 08     [c37a916d] (039/566) No match but offset
 09     [ac5ad610] (038/563) Accurately ripped
 10     [5ea5e171] (039/558) No match but offset
 11     [cc46d7c1] (039/540) No match but offset

Track Peak [ CRC32  ] [W/O NULL] [  LOG   ]
 --   97.7 [676A08B4] [F6C8BC1A]           
 01   97.7 [04B564BA] [6A33D5F9]   CRC32   
 02   97.7 [3DC55F78] [0296C6D0]   CRC32   
 03   97.7 [AA7422DC] [43358095]   CRC32   
 04   97.7 [0251F8EF] [A91411AA]   CRC32   
 05   97.7 [4FD3CD70] [24E1DABF]   CRC32   
 06   97.7 [43E1D1C6] [E45B33D8]   CRC32   
 07   97.1 [618BD826] [5C35B999]   CRC32   
 08   97.7 [5A9E0514] [23BB1B34]   CRC32   
 09   97.7 [645C41ED] [DF1D3E84]   CRC32   
 10   97.7 [DABC5DF3] [90290BF6]   CRC32   
 11   97.7 [C8636CF9] [8B7161C9]   CRC32
 

CTDB question: Repair function

Reply #16 –
With your last cuetools log: this rip is not accurate with a very very high confidence so it is not surprising that CTDB cannot fix it ... there is two possibility:

1: Very likely: the rip is not accurate & is scratched beyond repair.
2: Very unlikely: you own a rare pressing that is not in AR & doesn't match CTDB too

The possibility N°2 is still opened because of "Offsetted by 112:", so if you didn't fix the drive offset while ripping & the drive offset is +112, then possibility N°2 is closed & your rip is damaged.

Quote
- I thought i saw one of you mention something about a bad log file or something. Could my original EAC log files be confusing CT somehow?

This is where your EAC log will maybe help you, the records of the drive offset will maybe close possibility N°2. Other than that the EAC log is only usefull when the CD is enhanced & only if the log incluses the TOC.

Also:
Quote
337 CTDB confidence
be warned that as far as I understund this doesn't mean that 337 users submitted to CTDB, but only that the one that was submitted matches with AR at up to 337 accurate rips.

CTDB question: Repair function

Reply #17 –
Quote from: Skybrowser on
- Yes Greynol, CTDB submissions require AR confidence >=2

I knew this already, however CTDB submissions from CUERipper don't require any AR confidence, so it is possible for there to be CTDB entry that does not exist in AR (IOW, the two databases are independent). Either way, I'm glad to see this part of your problem has been addressed.

CTDB question: Repair function

Reply #18 –
Quote from: sauvage78 on
With your last cuetools log: this rip is not accurate with a very very high confidence
Sorry to nitpick again, but this is misleading.  Confidence applies to something that is accurate, not to something that is not accurate.

Quote from: sauvage78 on
2: Very unlikely: you own a rare pressing that is not in AR & doesn't match CTDB too
I don't see how you are able to assess that this is not likely, especially without a rip log.  Where was the CD produced, how many were produced from that run, was the data edited between production runs
(click removal/eq/etc.), where and when was it purchased, how long ago was it released, how many copies were sold?

CTDB question: Repair function

Reply #19 –
I may be wrong but I think that CTDB still requires an accuraccy of 1 even for CUERipper, there is a AR column in the CTDB page & I don't recall having seen any AR0 ... for me it is logic as an AR1+a CD in CUERipper means that the submission in AR is not from the same guy ... so in fact AR1+CUERipper 1= AR2 ... that's how I understand it.

CTDB question: Repair function

Reply #20 –
- My drive offset in logfiles for ripping is 667.

- The reason it says 112 in CT is because its a CDR. Thats why I mentioned fixing the offset earlier, i tried fixing offsets and still had the problem. Now i know what you're thinking, 'the problem is probably that its a bad burn' BUT I have already used CTDB to repair rips from burns that dont look damaged.... bad burns are repairable too and thus are not the problem.

- So how do i know the difference between an album that is unrepairable by CTDB and any other error i'm having? Do you think I should suggest to the developer that he uses different messages? One that notifies you that your album has too many errors to repair and one that says your album is not being recognized by the database or something?

CTDB question: Repair function

Reply #21 –
Well what is likely or not is only a question of probability, it's like poker if you have 2 aces in the hand you have a big probability to win ... but you can still lose.

Reading non accurate Cuetools log is like that ... with the information that he provided there is actually more chance that his rip is not accurate. If his EAC log confirm the drive offset then it's like drawing an additionnal ace  If you get what I mean

It's a question of habbit. You have to much non-scratched CD

CTDB question: Repair function

Reply #22 –
Ok I completely forgot that it was a CDR, well for me the rip is not accurate & beyond repair or you have a different pressing I can't tell. The fact that it is a CDR blurs the verdict, still even without certainty this rip is very suspicious IMHO.

Quote
- So how do i know the difference between an album that is unrepairable by CTDB and any other error i'm having? Do you think I should suggest to the developer that he uses different messages? One that notifies you that your album has too many errors to repair and one that says your album is not being recognized by the database or something?

I think CTDB has no way to know if it doesn't match because of pressing difference or because of scratches, hence the message doesn't make any difference. So my guess is that asking Greg for this will not help. I suspect that if it was possible Greg would have been clever enougth to make this difference. ... well I hope

CTDB question: Repair function

Reply #23 –
I already have a few encountering this situation. Like is the CTDB only really powerful enough to repair about 1 track? should i base it on how many in-accurate tracks I have on a specific CDR?

CTDB question: Repair function

Reply #24 –
The ability of CTDB to repair damaged rips is random, the only thing you can do is accepting it. Based on my small experience, so far I would say that if the rip is in CTDB you have 50% (maybe a little less) chance to be able to fix it (note that this estimation is likely very random too). It is (much) better than nothing, just be happy that CTDB exists.

I have already fixed rip with more than hundreds of difference (But it only happened once so far) so it's pure luck. You cannot draw any conclusion from the accuracy of tracks in cuetools log & extrapolate it to the ability of CTDB to fix it.

The ability of CTDB to repair damaged rips seems to rely much more on how many data Greg decide to store in the database. But the more data he stores the bigger & harder to manage the database becomes.