Re: cdparanoia and cache
"Tim [TMO]" <[email protected]> Wed, 21 Mar 2007 17:07:27 -0500
| Newsgroups | gmane.comp.audio.cd-paranoia.general |
|---|---|
| Message-ID | <[email protected]> |
[email protected] wrote: > On 3/21/07, Tim [TMO] <[email protected]> wrote: > > cdparanoia was written at a time before ATAPI cdrom drives exposed any > explicit cache control; it simply didn't exist in the ATA spec. Since > then, the commands that had always existed for SCSI were added, but > it's only been very recently that Linux has made it availabe (by > moving to a 'uniform' SG_IO interface). > > If you have a drive that is showing consisten cache issues with > cdparanoia, I'd be happy to sieze the opportunity to test adding ATAPI > cache control. Monty et al-- Exciting news! Thanks for the input and interest in the matter. The Hydrogen Audio forums have a lot of discussion on the matter and lots of overlap with EAC in that regard. Forgive me if my information is a little vague. It has been a year since I've focused much attention on the matter. This site will give you a ready list of drives and features--including those that cache. http://www.daefeatures.co.uk/search.php When last I tested all of this (over a year ago) I found I could demonstrate the problem as follows 1. Rip a track with proper offset for the drive. e.g. cdparanoia -Bvz -o 102 1 2. md5sum that track 3 Repeat steps 1 and 2 Ideally, the tracks will always match. That's why we use cdparanoia! What I found (fortunately, sparingly) was that on occasion, cdparanoia would complete with no major indications of error and the tracks would not match. Mind you, the first I discovered this was hearing an encoded file with obvious noise/errors/artifacts from a rip. From there, I pointed my quest for an explanation and details on more accurate ripping toward the forums. I think that was also when I signed up to this list ;-) After eliminating most of the other variables I found that lots of folks were dealing with the cache issue through a variety of means (most using EAC via windows). I did that for a bit and then I opted for older SCSI drives without Audio Caching in my linux pursuits. The only work around (in lieu of the issues you mentioned above) seemed to be the same rip/compare/rip/compare situation. e.g. RubyRipper http://www.hydrogenaudio.org/forums/lofiversion/index.php/t38418.html I am glad to test with my Plextor 708A CD/DVD ATAPI unit and anything else I can dig up. I'd wager that other folks here are also willing to help test any new code. Lots of folks via Hydrogen Audio as well. Cheers, Tim PS - Can't forget to say 'Thanks' for all of the efforts with cdparanoia and the other xiph projects.