[Paranoia] cdparanoia and cache

[Tim [TMO]]

xiphmont at xiph.org wrote:
> On 3/21/07, Tim [TMO] <tmo at anize.org> 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.