Mar 31 2010, 02:27
Joined: 16-October 03
Member No.: 9337
I have only now become aware of Gregory S. Chudov's effort to develop CTDB (CUETools DB). I am very excited about this as I have actually been suggesting this to spoon (dbpoweramp's developer for over 5 years)
for others that have missed it:
What's it for?
You probably heard about AccurateRip, a wonderfull database of CD rip checksums, which helps you make sure your CD rip is an exact copy of original CD. What it can tell you is how many other people got the same data when copying this CD. CUETools Database is an extension of this idea.
What are the advantages?
* The most important feature is the ability not only to detect, but also correct small amounts of errors that occured in the ripping process.
* It's free of the offset problems. You don't even need to set up offset correction for your CD drive to be able to verify and what's more important, submit rips to the database. Different pressings of the same CD are treated as the same disc by the database, it doesn't care.
* Verification results are easier to deal with. There are exactly three possible outcomes: rip is correct, rip contains correctable errors, rip is unknown (or contains errors beyond repair).
* If there's a match, you can be certain it's really a match, because in addition to recovery record database uses a well-known CRC32 checksum of the whole CD image (except for 10*588 offset samples in the first and last seconds of the disc). This checksum is used as a rip ID in CTDB.
What are the downsides and limitations?
* CUETools DB doesn't bother with tracks. Your rip as a whole is either good/correctable, or it isn't. If one of the tracks is damaged beyound repair, CTDB cannot tell which one.
* If your rip contains errors, verification/correction process will involve downloading about 200kb of data, which is much more than it takes for AccurateRp.
* Verification process is slower than with AR.
* Database was just born and at the moment contains much less CDs than AR.
How many errors can a rip contain and still be repairable?
* That depends. The best case scenario is when there's one continuous damaged area up to 30-40 sectors (about half a second) long.
* The worst case scenario is 4 non-continuous damaged sectors in (very) unlucky positions.
What information does the database contain per each submission?
* CD TOC (Table Of Contents), i.e. length of every track.
* Offset-finding checksum, i.e. small (16 byte) recovery record for a set of samples throughout the CD, which allows to detect the offset difference between the rip in database and your rip, even if your rip contains some errors.
* CRC32 of the whole disc (except for some leadin/leadout samples).
* Submission date, artist, title.
* 180kb recovery record, which is stored separately and accessed only when verifying a broken rip or repairing it.
May 27 2010, 18:34
Joined: 4-May 08
Member No.: 53282
In a discussion (that took a bad direction because I was making a lot of assumptions about CTDB which ended to be erroneous, sorry if it is painfull to read), it appeared that CTDB seems to accept non accurate submissions as long as it is done with cueripper (I didn't test it myself). The so-called AR(1) entries.
I am now worried about this, as from my un-educated point of view it seems that it means that you possibly admit entries to CDTB that might be damaged. The proportion of bad submissions should be low & even in this case it is up to the user to verify that once "fixed" the rip is more accurate than before trying to fix it. ... still even if I think that I know how to avoid "fixing" damaged rips with damaged CTDB submissions, I don't like idea that such non accurate CTDB entries will appear in my .accurip.
So, without resurecting this thread, I wanted to simply ask you: Why you are doing this & why you think that this is a non-issue ? I ask because most of the reason why the linked thread derailed is that I couldn't believe myself that CTDB was behaving like this.
I don't understand the logic of being AR(2) dependent if the rip comes from EAC or dbpoweramp & in the same time not dependent of the accuracy at all if the rip comes from cueripper.
Is there any rationnal explanation ? Is it just that you wanted to populate the database quickly ? (too quickly ...) Have you stored any additionnal informations that would allow you to re-check the accuracy of these suspicious submissions later ? (& purge them ...) Do you think that this is a minor issue ?
I don't understand why you store submissions that might be damaged & which does take some space on your database/hardrive when I think I recall that you said that you couldn't store a stronger correction file to keep the database small.
As I don't want to make assumptions about CTDB anymore (I get trouble with Greynol when I do so), I thought that I'd rather ask you directly, sorry ... Am i just completely wrong once again ?
Thks for any answers & all apologies if this is a non-issue.
This post has been edited by sauvage78: May 27 2010, 18:47
|Lo-Fi Version||Time is now: 21st December 2014 - 13:16|