Hi Peter,
On 6/21/2006, "Peter Creath" <address@hidden> wrote:
>How big is your drive's cache? There's a setting in the
>cdrom_paranoia_t that you pass to paranoia_read() that specifies how
>many sectors cdparanoia needs to read to exhaust your cache.
>Specifically, it's cdrom_paranoia_t.readahead.
>
>cdparanoia is written in a way that assumes everything is broken,
>because it usually is in practice. Drivers and kernel can cause
>dropped samples, drives almost never support the features they claim
>to support, etc. Or, to your point, drives don't always obey FUA (or
>its implementation in the driver or kernel may be broken). Thus the
>way cdparanoia is designed to handle drive caches is to increase this
>readahead value so that it exhausts the drive's cache. This approach
>ends up being more reliable.
>
>Hope this helps,
Yes, that's very helpful information, thank you.
However, I'm not sure how to determine the size of my drive's cache,
either programatically or through experimentation. Do you have any
suggestions?
I'd prefer a programmatic mechanism if there is one, since I could then
take advantage of it in my CD ripper.
Thanks.
>On 6/21/06, Jason Voegele <address@hidden> wrote:
>> Hello all,
>>
>> I'm a relative newcomer to libcdio, and I plan to use it for the CD-ROM
>> control module and CD audio extraction library for a CD ripping
>> application that I've been working on. Currently, my application is
>> using Linux command line tools to control the CD-ROM drive (e.g. eject,
>> etc.) and is using Xiph's cdparanoia for audio extraction. I plan on
>> using libcdio to remove my dependency on platform-specific command-line
>> tools.
>>
>> That said, one of the major problems with cdparanoia has been its
>> inability to disable the CD-ROM drive's cache when extracting audio,
>> thus leading to rips that contain errors. If the drive caches data,
>> then cdparanoia's strategy of doing multiple reads to ensure an
>> accurate rip fails because the drive simply returns the same erroneous
>> data on each read.
>>
>> EAC and some other Windows rippers disable the drive's cache by using
>> the "Force Unit Access" (FUA) flag when extracting audio. I also
>> happen to know that Xiph's cdparanoia attempts to use the FUA flag in
>> some circumstances but is very unreliable, and in fact does not work on
>> my Plextor CD-ROM drive.
>>
>> I am wondering if libcdio's cd-paranoia library has any mechanism for
>> applying the FUA flag to audio extraction operations, or any other
>> mechanism for circumventing the drive's cache. If not, would you
>> consider making such an enhancement for a future release?
>>
>> Thanks.
>>
>> --
>> Jason Voegele
>> "There is an essential core at the center of each man and woman that
>> remains unaltered no matter how life's externals may be transformed or
>> recombined. But it's smaller than we think."
>> -- Gene Wolfe, The Book of the Long Sun
>>
>>
>> _______________________________________________
>> Libcdio-devel mailing list
>> address@hidden
>> http://lists.gnu.org/mailman/listinfo/libcdio-devel
>>
--
Jason Voegele
"There is an essential core at the center of each man and woman that
remains unaltered no matter how life's externals may be transformed or
recombined. But it's smaller than we think."
-- Gene Wolfe, The Book of the Long Sun
_______________________________________________
Libcdio-devel mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/libcdio-devel