![]() Such matrix has up to ~30000 rows for a 70 minute CD, so i can use 16-bit Reed-Solomon for each column independently. So i have to process the file as a matrix with rows of 10 sectors (5880 samples = 11760 words/columns). Unfortunately, 32-bit Reed-Solomon is extremely slow, and 16-bit Reed-Solomon can be used directly only on chunks of up to 64k words = 128kbytes. The basic algorithm is Reed-Solomon code on 16-bit words. The algorithm is not very simple, there's quite a lot of code. The only problem is it's in C#, i wonder if i will have to provide a. Of course CTDB is open, and the code required to use it is LGPLed as all CUETools libraries. * 180kb recovery record, which is stored separately and accessed only when verifying a broken rip or repairing it. * CRC32 of the whole disc (except for some leadin/leadout samples). 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. What information does the database contain per each submission? * The worst case scenario is 4 non-continuous damaged sectors in (very) unlucky positions. The best case scenario is when there's one continuous damaged area up to 30-40 sectors (about half a second) long. How many errors can a rip contain and still be repairable? * Database was just born and at the moment contains much less CDs than AR. * Verification process is slower than with AR. * If your rip contains errors, verification/correction process will involve downloading about 200kb of data, which is much more than it takes for AccurateRp. If one of the tracks is damaged beyound repair, CTDB cannot tell which one. Your rip as a whole is either good/correctable, or it isn't. * CUETools DB doesn't bother with tracks. ![]() This checksum is used as a rip ID in CTDB. * 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). There are exactly three possible outcomes: rip is correct, rip contains correctable errors, rip is unknown (or contains errors beyond repair). * Verification results are easier to deal with. Different pressings of the same CD are treated as the same disc by the database, it doesn't care. 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. ![]() * The most important feature is the ability not only to detect, but also correct small amounts of errors that occured in the ripping process. CUETools Database is an extension of this idea. What it can tell you is how many other people got the same data when copying this CD. 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. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |