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 9 2010, 04:12
Joined: 4-May 08
Member No.: 53282
While I agree that burst rip should be accepted as long as those are AR2, I disagree with the idea that burst mode would always be faster than secure mode. This is only true if you compare burst vs. secure on a non-scratched CD. It also depends on the number of re-read you're using in your secure mode & it also depends on if you're ripping as CDImage or as separate tracks (because re-ripping a single scratched track is faster than re-riping a whole CD, which means that burst works even faster with separate tracks). As soon as there are a few scratched CD in your collection (and the average joe always have a few scratched CD in his collection), it is "on average" faster to use the secure mode with a lower number of re-reads than to completely drop the secure mode in favor of the burst mode (This is specially true if you rip as CDImage as you cannot only re-rip the scratched track). This is due to the fact that the burst mode will be faster on a single pass but you will need several pass to achieve an AR result. So if you want to avoid the headache of re-ripping ten time the same track (or whole CD if you use CDImage) you'd better use a secure mode with fewer re-reads than completely drop the secure mode. This is specially true with CDImage, but this is also true with separate tracks because even if re-riping a single track in burst mode is very fast. You will have to verify each burst rip separatly with cuetools, & as it will be burst, the chances that it will be AR2 on a really scratched CD will be low. Overall this means that the time you will gain for using burst will likely be lost checking dozen of burst rip against AR with cuetools. (Edit: Here I am a special case as I delete EAC log but keep .accurip which forces me to use cuetools after the ripping process, the cuetools part might be irrevelant to you if you directly check AR thru EAC)
When AR was created I was thinking like you that it would make the secure mode obsolete in favor of burst+AR2. This is not true, AR only allow you to reduce the number of re-reads. My experience tells me that it is faster to rip a CD twice in Secure+Low than ripping it ten time in burst & then checking ten time if it's AR. Burst mode+AR2 can be faster if you're lucky (lucky to only have non-scratched CD in your collection), but it's pure random. The only exception is maybe if you just bought the CD as it will be shinning new. As I don't want to use two settings for new & old CD (even with profiles), this exception is irrevelant to me.
In the end this means that even if AR2 burst rip should be accepted, it is not really a priority IMHO because in the end the burst mode is not always as fast as it seems. It depends on what you rip (new or old CD) & on how you rip (what setting you're comparing burst to).
Edit: The above applies to EAC, I never tried CUERipper so far.
The fact that CTDB ignores 10 frames instead of 5 like AR is a "much bigger" (I know some people people might not consider 5 frames "big" but I disagree) design flaw IMHO, I already have 3 rips which are not AR but are CTDB OK ... even if AR & CTDB doesn't serve the same purpose, it is a little weird to have them conflicting.
[Verification date: 05/05/2010 21:42:49]
[AccurateRip ID: 001555ed-00b500c2-990b410b] found.
[CTDB TOCID: 9ZJTSx3s7H3pnsu6h7eKNf9M8xE-] found.
[ CTDBID ] Status
[2b6d1a2c] (190/190) Accurately ripped
Track [ CRC ] Status
01 [ec93376d] (76/203) No match but offset
02 [dbd08c29] (77/203) Accurately ripped
03 [83406c8a] (76/201) Accurately ripped
04 [983f8873] (77/203) Accurately ripped
05 [eabd4d44] (77/203) Accurately ripped
06 [10c7c833] (77/204) Accurately ripped
07 [d4328e57] (77/204) Accurately ripped
08 [d98b9da8] (76/203) Accurately ripped
09 [984cf36c] (77/203) Accurately ripped
10 [0994ce6b] (77/203) Accurately ripped
11 [4e9e9b41] (76/198) Accurately ripped
Note: This log was shortened.
This post has been edited by sauvage78: May 9 2010, 05:00
|Lo-Fi Version||Time is now: 21st May 2013 - 11:00|