cdparanoia and cache

View: New views
5 Messages — Rating Filter:   Alert me  

cdparanoia and cache

by Harry Sack :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hi,

I found this question on the Internet:
http://www.nabble.com/cdparanoia-and-cache-t2390032.html

I was wondering if the cache problem in cdparanoia is already fixed
(because I also have a plextor premium cdrom drive) and in what
version of cdparanoia?

thanks in advance!
_______________________________________________
Paranoia mailing list
Paranoia@...
http://lists.xiph.org/mailman/listinfo/paranoia

Re: cdparanoia and cache

by Tim [TMO] :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Harry Sack wrote:
> Hi,
>
> I found this question on the Internet:
> http://www.nabble.com/cdparanoia-and-cache-t2390032.html

I corresponded with Wolf, who made that posting.  He informed me that
the change in read ahead values did not serve as a fix for the caching
problems with newer drives.  After more experimentation with his patch
he apparently found that the caching was still an issue.

> I was wondering if the cache problem in cdparanoia is already fixed
> (because I also have a plextor premium cdrom drive) and in what
> version of cdparanoia?

To my knowledge, no.  This is a long standing wish list item.  I've been
hunting for at least a year.  My work around was to buy a couple of
cheap plextor SCSI drives via ebay and implement them for ripping/burning.

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

Re: cdparanoia and cache

by xiphmont :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On 3/21/07, Tim [TMO] <tmo@...> wrote:
> Harry Sack wrote:

> I corresponded with Wolf, who made that posting.  He informed me that
> the change in read ahead values did not serve as a fix for the caching
> problems with newer drives.  After more experimentation with his patch
> he apparently found that the caching was still an issue.
>
> > I was wondering if the cache problem in cdparanoia is already fixed
> > (because I also have a plextor premium cdrom drive) and in what
> > version of cdparanoia?
>
> To my knowledge, no.  This is a long standing wish list item.  I've been
> hunting for at least a year.  My work around was to buy a couple of
> cheap plextor SCSI drives via ebay and implement them for ripping/burning.

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
_______________________________________________
Paranoia mailing list
Paranoia@...
http://lists.xiph.org/mailman/listinfo/paranoia

Re: cdparanoia and cache

by Tim [TMO] :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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

Re: cdparanoia and cache

by Harry Sack :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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