lgmcben
Oct 16 2005, 06:34
Maybe this is because of my poor English, or the EAC help message is misleading again.(the previous time was about the Extraction priority)
In the feature test window, EAC tell me something like: "Whereas the 'Accurate stream' feature is useful for audio extraction, the 'Caching' feature WILL make exact extraction even more complicated and insecure!"
Now let's put your mouse on the "Drive cache audio data" option, the help message will pop up. For me, this message is somewhat confused with what it just told me in the feature test window.(Forgive me here, English is my 3rd language)
To make long story short,
Question: Should the "Drive cache audio data" box be checked if my drive does support this feature?
Thank you.
criZZb
Oct 16 2005, 06:43
In short: yes --- it turns on the routines trying to fake the internal drive's cache.
rutra80
Oct 16 2005, 14:42
Ummm, it rather turns on the routines trying to bypass internal drive's cache.
If the drive caches audio it's a bad thing - this option should be checked on drives which cache audio, and unchecked on drives which don't cache audio (or checked in all cases, to be on the safe side).
criZZb
Oct 16 2005, 15:56
QUOTE(rutra80 @ Oct 16 2005, 09:42 PM)
Ummm, it rather turns on the routines trying to bypass internal drive's cache.
As the matter of fact, 'bypass' is not a good description either, EAC tries to reset the cache between consecutive reads
mirrorsawlljk
Oct 16 2005, 17:27
Is it bad to turn off the cache option if your drive DOES cache? I've heard many drives report that they cache, even though they don't, and it does seem to speed up secure mode rips substantially.
dreamliner77
Oct 16 2005, 17:31
Yes, because you would just be re-reading the erroneus data already in cache.
if your drive DOES CACHE, YES, check it
If it doesn't, D NOT
Drenholm
Oct 17 2005, 02:00
Yeah, check the box if your drive caches. There should be a test which can determine this for you.
To elaborate, if your drive caches, it will 'read forward' a larger amount of data when requested to read certain data from the CD, then read from this buffer until new data is needed. For EAC this is bad as erroneous data could be missed because of being re-read from the cache. So EAC's option is a workaround this problem and should be checked, thus causing the data to always be re-read from the CD itself and not the cache.
sTisTi
Oct 17 2005, 05:56
QUOTE(Drenholm @ Oct 17 2005, 12:00 AM)
To elaborate, if your drive caches, it will 'read forward' a larger amount of data when requested to read certain data from the CD, then read from this buffer until new data is needed. For EAC this is bad as erroneous data could be missed because of being re-read from the cache. So EAC's option is a workaround this problem and should be checked, thus causing the data to always be re-read from the CD itself and not the cache.

One more thing: What about the combination of the "drive caches audio" and "~drive is capable of reporting C2 errors" boxes? Isn't it unnecessary to check the 1st when you have the 2nd checked? Because when you rely on the C2 error pointer of the drive, EAC does not read the sectors twice anyway, so no need to "flush" the cache as long as no C2 errors are reported.
Wouldn't it make sense to flush the cache only during the repeated readings that occur when the drive actually reports a C2 error? Otherwise the "drive caches audio" option unnecessary slows down the ripping process. Or am I missing something?
Of course I know that not all drives are flawless in reporting C2 errors, but if you have a drive that is known to be reliable and you decide to rely on it, the "drive caches audio" option seems a bit weird to be activated also if no errors are reported by the drive.
Drenholm
Oct 18 2005, 01:46
C2 can give misleading results as sometimes is can tell the drive the data is 'okay' when it isn't. If C2 is off, the drive will re-read sectors itself to verify data integrity (rather than relying on the CD's own error-correction information), thus giving you more chance of getting an accurate rip.
For the purposes of secure reading of any kind I would think caching is always baaaad. And it has been said here on HA to disable C2 for more accurate reads.
sTisTi
Oct 18 2005, 05:25
QUOTE(Drenholm @ Oct 17 2005, 11:46 PM)
C2 can give misleading results as sometimes is can tell the drive the data is 'okay' when it isn't. If C2 is
off, the drive will re-read sectors itself to verify data integrity (rather than relying on the CD's own error-correction information), thus giving you more chance of getting an accurate rip.
For the purposes of secure reading of any kind I would think caching is always baaaad. And it has been said here on HA to disable C2 for more accurate reads.
What you say makes perfect sense, but my point is that if you
do choose to use C2, the "drive chaches audio" box is kind of pointless as long as the drive does not actually report a C2 error, thus slowing down the reading unnecessarily.
Acid8000
Oct 18 2005, 23:54
Does the drive re-read with C2 enabled? I always thought it only re-read once a C2 error is found.
funkyblue
Oct 19 2005, 01:02
I don't even bother..I just use offset correction, burst mode and Test and Copy all tracks..I get ultra fast rips, and as long as the CRC's match, I know I get perfect rips..
kotrtim
Oct 19 2005, 03:43
Can we test the drive this way?
Turn off the output buffer of audio players, such as Winamp and foobar2k
then try to play a CD , eject the CD while the player is playing, if it still play, let's say for additional 10 seconds, that means the CD Drive caches audio data?????
I know it sounds stupid.....
sTisTi
Oct 19 2005, 11:44
QUOTE(Acid8000 @ Oct 18 2005, 09:54 PM)
Does the drive re-read with C2 enabled? I always thought it only re-read once a C2 error is found.
No, it doesn't re-read, that's why rips are about twice as fast with C2 enabled. Still, checking the "cache" boxs slows it down again by half, this is annoying as most newer drives cache audio.
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please
click here.