« Return to Thread: cdparanoia and cache

Re: cdparanoia and cache

by Harry Sack :: Rate this Message:

Reply to Author | View in Thread

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] <tmo@...>:
xiphmont@... wrote:

> On 3/21/07, Tim [TMO] <tmo@...> 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
Paranoia@...
http://lists.xiph.org/mailman/listinfo/paranoia


_______________________________________________
Paranoia mailing list
Paranoia@...
http://lists.xiph.org/mailman/listinfo/paranoia

 « Return to Thread: cdparanoia and cache