Hi,<br><br>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:<br><br><a href="http://www.nabble.com/cdparanoia-and-cache-t2390032.html">
http://www.nabble.com/cdparanoia-and-cache-t2390032.html</a><br><br>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.
<br><br>best regards<br>Harry<br><br><br><br><div><span class="gmail_quote">2007/3/21, Tim [TMO] <<a href="mailto:tmo@anize.org">tmo@anize.org</a>>:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<a href="mailto:xiphmont@xiph.org">xiphmont@xiph.org</a> wrote:<br>> On 3/21/07, Tim [TMO] <<a href="mailto:tmo@anize.org">tmo@anize.org</a>> wrote:<br>><br>> cdparanoia was written at a time before ATAPI cdrom drives exposed any
<br>> explicit cache control; it simply didn't exist in the ATA spec. Since<br>> then, the commands that had always existed for SCSI were added, but<br>> it's only been very recently that Linux has made it availabe (by
<br>> moving to a 'uniform' SG_IO interface).<br>><br>> If you have a drive that is showing consisten cache issues with<br>> cdparanoia, I'd be happy to sieze the opportunity to test adding ATAPI<br>
> cache control.<br><br>Monty et al--<br> Exciting news! Thanks for the input and interest in the matter. The<br>Hydrogen Audio forums have a lot of discussion on the matter and lots of<br>overlap with EAC in that regard. Forgive me if my information is a
<br>little vague. It has been a year since I've focused much attention on<br>the matter.<br><br>This site will give you a ready list of drives and features--including<br>those that cache.<br><a href="http://www.daefeatures.co.uk/search.php">
http://www.daefeatures.co.uk/search.php</a><br><br>When last I tested all of this (over a year ago) I found I could<br>demonstrate the problem as follows<br><br>1. Rip a track with proper offset for the drive.<br>e.g. cdparanoia -Bvz -o 102 1
<br>2. md5sum that track<br>3 Repeat steps 1 and 2<br><br>Ideally, the tracks will always match. That's why we use cdparanoia!<br>What I found (fortunately, sparingly) was that on occasion, cdparanoia<br>would complete with no major indications of error and the tracks would
<br>not match.<br><br>Mind you, the first I discovered this was hearing an encoded file with<br>obvious noise/errors/artifacts from a rip. From there, I pointed my<br>quest for an explanation and details on more accurate ripping toward the
<br>forums. I think that was also when I signed up to this list ;-) After<br>eliminating most of the other variables I found that lots of folks were<br>dealing with the cache issue through a variety of means (most using EAC
<br>via windows). I did that for a bit and then I opted for older SCSI<br>drives without Audio Caching in my linux pursuits.<br><br>The only work around (in lieu of the issues you mentioned above) seemed<br>to be the same rip/compare/rip/compare situation.
<br><br>e.g. RubyRipper<br><a href="http://www.hydrogenaudio.org/forums/lofiversion/index.php/t38418.html">http://www.hydrogenaudio.org/forums/lofiversion/index.php/t38418.html</a><br><br>I am glad to test with my Plextor 708A CD/DVD ATAPI unit and anything
<br>else I can dig up.<br><br>I'd wager that other folks here are also willing to help test any new<br>code. Lots of folks via Hydrogen Audio as well.<br><br>Cheers,<br>Tim<br><br>PS - Can't forget to say 'Thanks' for all of the efforts with cdparanoia
<br>and the other xiph projects.<br>_______________________________________________<br>Paranoia mailing list<br><a href="mailto:Paranoia@xiph.org">Paranoia@xiph.org</a><br><a href="http://lists.xiph.org/mailman/listinfo/paranoia">
http://lists.xiph.org/mailman/listinfo/paranoia</a><br></blockquote></div><br>