Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: EAC Caching Tests -- Conflicting Results (Read 3427 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

EAC Caching Tests -- Conflicting Results

I recently installed Exact Audio Copy on an old computer and did more thorough research than usual to make sure I set it up right.  During the Configuration Wizard, before detecting the read features of each drive, EAC reported that according to the EAC Database both my drives cache audio:

LITE-ON COMBO LTC-48161H
Accurate stream:  Yes
Audio cache:  Yes
C2 error information:  Yes

SAMSUNG CD-R/RW SW-216B
Accurate stream:  Yes
Audio cache:  Yes
C2 error information:  Yes


However, after feature detection, it said the Samsung drive does not cache audio:

LITE-ON COMBO LTC-48161H
Accurate stream:  Yes
Audio cache:  Yes
C2 error information:  Yes

SAMSUNG CD-R/RW SW-216B
Accurate stream:  Yes
Audio cache:  No
C2 error information:  Yes


I have read that EAC's drive caching test results may not always be correct, so I decided to do my own testing of the drive.  I thought I had read somewhere that if EAC is still able to detect errors on a scratched CD while in Secure Mode (with "Low" error recovery quality) while "Drive caches audio data" is NOT ticked in the Drive Options, it means that the drive does not cache audio data.  Which makes sense, because when EAC is in Secure Mode it reads each chunk of data twice and compares them to look for errors, and if the drive caches it will report the exact same data to EAC for both requests without actually re-reading the disk, and EAC would never detect any suspicious frames no matter how scratched-up the CD is.

So in my mind, I believed that if a single error can be detected on a CD with EAC in Secure Mode and cache flushing disabled, it means that the drive does not cache audio data.

I ripped a CD with the Samsung drive using those EAC settings, and it actually found suspicious positions in track #1, which also was the only track that couldn't be verified by AccurateRip.  I am hoping this means I can be 100% sure that the drive in fact does not cache audio, despite EAC's database telling me it does.  But then I dreamt up a question that cast some doubts for me (which I am hoping someone here can answer):

Is it possible that the suspicious position on the first track is due to something unusual that I'm not familiar with, perhaps due to not being able to read the lead-in?  I am not really familiar with what the lead-in is.  (Note: EAC reports suspicious positions at 1-minute+ into the track, not at the beginning.)

I am assuming that this doubt is unwarranted, and that not being able to read the lead-in wouldn't cause EAC to report errors, and that EAC wouldn't report suspicious positions unless it actually got two different readings at those exact positions.


...Then, out of curiosity, I decided to test whether the LITE-ON drive caches audio.  EAC had already reported that it detected caching in that drive, so I figured that it was impossible that this drive does not cache audio.  I thought EAC's caching test would not say "Yes" unless the drive truly did cache.  I ripped a different, more-scratched CD with this drive with cache flushing enabled, and it took a horribly long time to rip (I cancelled it after almost 2 straight days, but got 13 out of 14 tracks ripped).  Some of the tracks had suspicious positions.  I then disabled cache flushing and ripped again, figuring that EAC most likely would NOT report any suspicious positions due to the caching by the drive.  The rip went much, much faster, but...  EAC still found suspicious positions.

So now I'm wondering why EAC said the LITE-ON drive caches audio, but was then able to find suspicious positions on a CD with cache flushing disabled.  Is it possible for EAC to find some suspicious positions using a caching drive with cache flushing disabled, under certain circumstances?  Perhaps some of the chunks EAC requested from the CD were too large to fit in the drive's cache and were properly re-read, but some were not?  (Again, I'm using my imagination -- I have no basis for that idea.)

As an interesting note, EAC actually did find more suspicious positions overall when it ripped with cache flushing than when it didn't, and 3 more tracks could be verified by AccurateRip.  But this might have been a coincidence.

My last questions are:

Why did EAC report caching for the LITE-ON drive if it can still detect some suspicious positions using that drive?

Can I be 100% sure that neither drive caches audio data, despite reports to the contrary from EAC's database and drive feature detection, because otherwise NO suspicious positions could have been detected without flushing the cache during extraction?

Thank you very much to anyone who can help me with this!  I thought I had EAC all figured out, but now these unexpected results are challenging my beliefs and causing me to wonder how much I really understand.

EAC Caching Tests -- Conflicting Results

Reply #1
EAC finds suspicious positions by looking at the drop in read speed, i.e. it measures the time it takes to read sectors.

If a drive caches audio then it would not give different re-reads, i.e. no red light dots in secure mode, but it would still give a drop in read speed.  Assuming the scratch/damage is sufficient to give unrecoverable errors and there were no red dots in your test or tests then it suggests the drive caches audio. Also C2 reporting will also give red dots so that should be disabled in the test.

EAC Caching Tests -- Conflicting Results

Reply #2
Ohhhhhhkay, so just because EAC found suspicious positions does not mean it found re-read mismatches.  I thought that “suspicious position” meant that EAC had found a mismatch and was not able to get consistent reads for 8 out of 16 re-reads.  I didn’t actually watch for red dots.

As for C2, I thought I disabled that, but I was pretty tired at the time and could very well have forgotten.

I should repeat my tests, making sure C2 is disabled this time, and watch for red dots.

Thanks for the information, hyman.

This issue may be solved, but I thought I should post this anyway -- I just installed Feurio and ran tests on the drives, and it reported the following:

“Cache size for audio data:  889 kByte” for the Lite-On drive.
and
“Cache size for audio data: 0 kByte” for the Samsung drive.

This is consistent with EAC’s test results.

If my re-test confirms that the Samsung drive does not cache, my last question is, why did EAC’s database report that the Samsung drive caches when it doesn’t?  I’m just curious as to how an inaccurate test result could have gotten into the database.

EAC Caching Tests -- Conflicting Results

Reply #3
EAC finds suspicious positions by looking at the drop in read speed, i.e. it measures the time it takes to read sectors.

In burst mode, yes but this is not true for secure mode.

If a drive caches audio then it would not give different re-reads, i.e. no red light dots in secure mode

This is completely false.  Even if a caching drive is configured as not caching, EAC will still detect errors and attempt to perform re-read sets (i.e. red light dots will appear) exactly as it would if the drive was correctly configured as caching.  This is the case whether or not C2 pointers are being used.

@heyo_speaker:
Please disregard hyman's largely incorrect reply and have a look at this wiki article:
http://wiki.hydrogenaudio.org/index.php?ti...C_Drive_Options

EAC Caching Tests -- Conflicting Results

Reply #4
Thank you very much for the clarification.  I have actually been following the wiki guides and I'm trying to follow this tip from the article:

"Tip #1: If you're concerned that your drive caches audio data even though EAC is saying otherwise, try ripping a scratched disc (one known to produce errors easily). Make sure you uncheck the "Drive caches audio data" setting AND uncheck the "Drive is capable of retrieving C2 error information" setting. Make sure you also set the error recovery quality to "Low". If EAC is capable of displaying a read error then cache flushing isn't necessary. "

I guess what I need to know is, how do I know EAC "is capable of displaying a read error"?

Which of the following indicate a read error:
-- Red dots during extraction
-- A "suspicious position" reported in the log
-- and/or something else

And is it correct for me to interpret the above tip to mean "if, in Secure Mode with cache flushing and C2 disabled, EAC displays even a SINGLE read error (even just 1 red dot, "suspicious position", or something else), you can be 100% confident your drive does not cache"?

Thanks!!!


[Edit:] I just re-read your post, and I forgot that you already ruled out the red dots as being a reliable indication of a "read error".  So I'm just wondering how I will know if one occurs.

EAC Caching Tests -- Conflicting Results

Reply #5
In the status dialog that pops up after ripping is finished, EAC will display either or both of two types of errors when it doesn't get at least 8 identical re-reads out of the allotted 16 re-read set(s).  The two types are "read" errors and "sync" errors.  EAC must be able to report a "read" error in order to know conclusively that the your drive is going back to the disc for each re-read, rather than just giving back what is in the cache.  "Sync" errors will display even if the cache setting is incorrect.

EAC does not report this specific information in the log file.

 

EAC Caching Tests -- Conflicting Results

Reply #6
Thanks, greynol.  So just to summarize:


To test whether a drive caches audio data using EAC:

-- Set EAC to "Secure Mode"
-- Disable "Drive caches audio data"
-- Disable "Drive is capable of retrieving C2 error information"
-- Set error recovery quality to "Low"

Insert a badly scratched CD in the drive and start extraction.

If "Read Error" appears in the status dialog before the extraction is complete, you will know with 100% certainty that the drive does NOT cache audio data.

If "Read Error" does not appear, try again with another scratched CD, or assume the drive DOES cache audio data.


If anything I said above is incorrect, inaccurate, or incomplete, please let me know!


I'm just worried because the above procedure doesn't seem to match what I'm reading here:
http://www.hydrogenaudio.org/forums/index....showtopic=26919
(But that could be 'cuz I'm having trouble understanding it.)

EAC Caching Tests -- Conflicting Results

Reply #7
If "Read Error" does not appear, try again with another scratched CD, or assume the drive DOES cache audio data.

I would try the same disc again but with the drive configured as caching.

Another thing I'd check is how quickly re-reads are performed.  The row of red lights will illuminate extremely quickly (a small fraction of a second) if the drive caches and isn't configured as caching.  A non-caching drive will not perform re-reads anywhere near as quickly.  You can also increase the error recovery quality beyond low (medium or high, does not matter).  All rows of error correction lights will only illuminate when there is a sync error, otherwise one and only one row will illuminate and a read error will never be reported.  The point here is that seeing a read error is conclusive proof that caching is not causing a problem.  Absence of a read error is not proof that caching isn't a problem since it is possible to have a rip that only gives a sync error using a properly configured drive.

I'm just worried because the above procedure doesn't seem to match what I'm reading here:
http://www.hydrogenaudio.org/forums/index....showtopic=26919

I skimmed the thread and continue to feel 100% confident that what I have told you and what is in the wiki is correct, regardless of what you may read elsewhere.

Anyone and everyone is welcome, even encouraged, to try to prove me wrong. 

EAC Caching Tests -- Conflicting Results

Reply #8
When ripping the same track with cache flushing disabled:

Using the Lite-On, the row of red dots fills up near-instantaneously and NO read error is reported.

Using the Samsung, it takes almost a full second for the row to fill up and a read error IS reported.

So it seems EAC's tests were right, and the database was incorrect about the Samsung for some reason.

Thanks for the help!  (again)