New version of CDParanoia III 10.2 Released Reply #25 – 2008-09-13 14:49:00 Quote from: xiphmont on 2008-09-13 08:05:56Truly missing samples are truly missing. If a sector is partially unrecoverable, the only thing you can do is software filtering after the fact. There are software filters that do a good job (I designed some of them), and I do plan to add one to cdparanoia in the future. Now that some drives report real C2 flags (as opposed to 2001-ish when many drives supported the feature by handing back bogus information that 'appoximated' the real data), there will be a more reliable way to do this than had originally been in Paranoia II, which I never added to Paranoia III because it just didn't work that well.However, that will still be, in a sense, manufactured information. I'm not really sure why you think you'd get 100% rip reproducability out of a disc with literal holes in the media! The original pupose of cdparanoia is to make the drive behave, including getting a stable read (one that doesn't skip, even if it can't completely repair the damage) around media inconsistencies. Even good drives will often skip on minor scratches that simple retry/compare fixes nicely. I haven't implemented the magic flag to make all heavy damage go away yet. I'm not actually being sarcastic here, some of the reconstruction filters are really damned good, if I can get reliable information from the read about which samples are suspect.Oh, and FWIW, there are no magic FUA commands on modern IDE/SATA ATAPI/MMC drives. There are commands in the command set (such as SET READAHEAD, 0xA7) that mandate specific cache side effects that *look* like they will be useful, but I've not found a drive yet that actually obeys the spec. I didn't even bother adding the commands to 10.2 (although A7 was in SVN for testing for a little while). Of my 10 main testing drives, 8 accepted the command. 7 then performed none of mandated cache side effects. The eighth did.. something kinda random (flushed cache depending on how the request intersected, then completely spun down, or just ignored the command entirely). I had one report from a beta tester that said the A7 command worked properly on his drive, but reduced its performance to around 2x before any of the retry/compare operations. So... not acceptable.Similarly, the various cache extents options avilable through MODE SET 10/12 nearly always only apply to data discs. The requests are either rejected, or accepted but ignored for redbook discs. I'm not sure how any other ripper thinks it's actually disabling the drive cache by flipping a switch. Sure, the drives accept the commands, but if you actually check what the drive is doing, the commands *don't actually work on audio discs*. So, cdparanoia 10,2 times every operation and compares the drive behavior to the cache model. If a seek should have happened, but a read comes back in only 2ms, it knows that something went wrong. No, this is not used a primary defense-- it's merely an additional safeguard on top of the new cache model (because the -A analysis is far too heavyweight to run before every rip and drive behaviors change from exact medium to exact medium. A cyanine CDR may not be read the same way as an aluminum commercial pressing, etc...).Montyxiph.orgThanks for the response ---- and software --- which I somewhat much understand in a non-programers kinda way.The disk was certainly an extreme case - the only one I have in my collection that I didn't (couldn't) repair.And I know that there's a lot of missing data there, and any rip will have that filled in with a guess of some sort. I've ripped the disk before with XLD with very good, no real audible problem results.So far the new version froze up my computer on two different attempts - one with caching off, and one on. Just my results so far with this particular disk on one particular drive.I'll be heading to the library to find some more "normal" damage disks to try.I actually got extremely good results before with the Paranoia II paired with a couple of good caching drives. It definitely improved their performance on problem disks. I'm looking forward to trying out P III some more.