Re: cdparanoia and cache

Hi,

I also found this article online where a person tried to solve the problem
by modifying the source code, but I don't know if it works:

http://www.nabble.com/cdparanoia-and-cache-t2390032.html

I also do the same thing like Tim: ripping, comparing, ripping, comparing
and I also found some times where the 2 tracks are not exactly the same. I
use a Plextor Premium and it has a cache of a whopping 8 MB, so maybe caches
this big cause many problems in cdparanoia.

best regards
Harry



2007/3/21, Tim [TMO] <[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.
> _______________________________________________
> Paranoia mailing list
> [email protected]
> http://lists.xiph.org/mailman/listinfo/paranoia
>

_______________________________________________
Paranoia mailing list
[email protected]
http://lists.xiph.org/mailman/listinfo/paranoia