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 question about audio caching (Read 4768 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

EAC question about audio caching

I have ripped many cds on my Plextor PX-W4012A with the following options:

secure rip checked (and it has secure rip)

audio cache NOT checked (but it does cache audio!)

c2 error unchecked (though it does do c2 error checking)

I have recently come across posts on this forum telling me that if the drive caches audio, the box should be checked so that the routines to circumvent caching are on.

Here is my question...  If these cds were ripped with these settings, and there were never any "red bars" and the audio quality was 100%, is it possible that errors were still introduced into the ripped file? Or would these errors only come when EAC starts filling up the red bar area?

I copy to a complete image + cue sheet.

I am not worried about those cds i ripped when red bars were created..  I either cleaned/resurfaced these enough so that this did not happen, or i did not keep the resulting file.

Anyone out there that knows for sure?

Chris

EAC question about audio caching

Reply #1
Quote
Here is my question...   If these cds were ripped with these settings, and there were never any "red bars" and the audio quality was 100%, is it possible that errors were still introduced into the ripped file?
[a href="index.php?act=findpost&pid=351933"][{POST_SNAPBACK}][/a]

Yes, albeit extremely unlikely. The safest method you're likely to get is to use Test & Copy and check that you have matching CRCs. There could still be errors due to copy protection but if your CRCs match your rip is probably as secure/perfect as you're going to get.
daefeatures.co.uk

EAC question about audio caching

Reply #2
Error checking does not work if drive caching is not disabled and C2 error detection is not in use. If your drive is able to properly use C2 error detection, then errors should be detected on the first read*. With no C2 checking, EAC error checking relies on a second read of every sector and compares the two reads. If the drive caches, then the second read will be from the buffer and errors will go undetected.

*But C2 error checking is often unreliable. It's safer to not use C2, and to disable caching.

If secure mode with no C2 or caching is too slow for you, burst mode test & copy (+matching CRCs) is very unlikely to let errors slip through, tho it's not perfect.

EAC question about audio caching

Reply #3
Chances are, your rips are fine.. They COULD be "just okay"

If you drive read em, they were at least partly readable.

EAC question about audio caching

Reply #4
Quote
I am not worried about those cds i ripped when red bars were created..

Hmmm... This means errors were detected with cache enabled and no C2 ???

edit: but=and

EAC question about audio caching

Reply #5
Quote
audio cache NOT checked (but it does cache audio!)

as i remember my readings of the EAC documentation, when not enabling the cache for drives that cache audio data, the error checking process (multiple reads of the same sector) is falsified because EAC re-reads the sector in the cache, so it is identical each time. so if an error occurs, it can't determine if and when it has occured.
when eac is "filling red bars", it means that eac has obtained two different results by reading the same sector. so the reading was accurate!!!

in fact, when caching is enabled, EAC has to clear the drive cache each time a sector is read (because EAC reads at least twice the same sector) to ensure that it is not a re-read from the cache.

as i remember, some drives do caching while not caching at all for audio extraction!
so clearing the cache is totally unuseful and consuming time for nothing. in this case the option should be disabled.
it seems that plextor drives do so (it is your case).

there is a post here about that.

i'm certainly not very clear!
and i may be wrong so,
to be sure, you should test this with a cd that produces errors with cache enabled and disabled and compare EAC behaviour (does it "sees" the error or not) and the obtained waves.
also, please refer to the EAC documentation to understand those options. 

cu, pipo.

EAC question about audio caching

Reply #6
Quote
Hmmm... This means errors were detected with cache enabled but no C2 ???

about the C2 option...
if it is checked, EAC use C2 information reported by the drive to determine the correct data.
if it is unchecked, EAC guesses that the correct data is the one that is coming more often in the multiple reads.

leaving it unchecked is safer, because C2 is not correctly implemeted in some drives that are detected to report it.
edit: oops! already said!

why don't you use plextools?
full speed and safe DAE for your drive.

EAC question about audio caching

Reply #7
As far as my knowledge affords me, turning off the caching option in EAC doesn't disable caching on the drive, but merely stops EAC from compensating for the caching feature - a potentially bad situation if you're looking for bit-perfect rips.

However, the fact is that if any EAC image rip completes, it's more than likely to be a successful rip by audible standards (even if there were errors, they're inaudible anyway).

For example, I ripped my fairly (but not unreadably) scratched Nirvana - Nevermind CD using WMP 10. I've listened to the rip and found it to be fantastic with no skips, pops, artifacts or the like. Recently however, in a massive project to backup my entire original CD collection, I ripped the same disc using EAC with the software's cache option enabled on my caching Plextor PX-716UF. EAC took no less than 7 hours to complete the job. Moral of the story as far as I'm concerned is that unless you're interested in bit-perfect rips, the whole cache issue is moot.

By the way, I've since switched to ripping using my Toshiba laptop's non-caching SD-R2412 CD+/-RW/DVD-ROM drive, and have noticed fantastic improvement in rip speed (EAC settings: Secure, cache off, C2 on), but with the same resulting accuracy as with the Plextor (EAC settings: Secure, cache on, C2 on).

Bottom line in my opinion is that if you're DAE-ing and you must have a bit-perfect rip, use a non-caching drive, period. If you have to use a caching drive, however, don't disable EAC's cache feature - you could potentially be missing a lot of errors that way, especially with scratched discs. In any case, the only difference you're likely notice between caching and non-caching drives (with the corresponding compensating setting on EAC applied) is in the ripping speed, not the accuracy of the output. As usual, there are exceptions that are more likely to occur the more damaged the disc is.

If you only need a transparent rip, feel free to pare back EAC's more secure features without much worry, since commodity software does a good job of it anyway.
EAC>1)fb2k>LAME3.99 -V 0 --vbr-new>WMP12 2)MAC-Extra High

EAC question about audio caching

Reply #8
Quote
when not enabling the cache for drives that cache audio data
<snip>
in fact, when caching is enabled
The common misunderstanding: marking that Drive caches audio data checkbox does not enable (or disable) the drive's cache. If you read through the thread you referenced farther down, you should have noticed the words cache override.

Quote
when eac is "filling red bars", it means that eac has obtained two different results by reading the same sector. so the reading was accurate!!!
If it was accurate, then why different results?

Quote
as i remember, some drives do caching while not caching at all for audio extraction!
It would be helpful if you specified what drives those are.

Quote
so clearing the cache is totally unuseful and consuming time for nothing. in this case the option should be disabled.
it seems that plextor drives do so (it is your case).
Agreed =)

Quote
there is a post here about that.
Broken link. Should be Plextor, EAC and cache, great news for Premium/PX-712 users

Quote
i'm certainly not very clear! :P
Certainly not. =) I'm sure you mean well, though.

EAC question about audio caching

Reply #9
Quote from: Never_Again,Dec 23 2005, 02:11 PM

Quote from: don_pipo_corleone,Dec 22 2005, 05:52 PM
when not enabling the cache for drives that cache audio data
<snip>
in fact, when caching is enabled
The common misunderstanding: marking that Drive caches audio data checkbox does not enable (or disable) the drive's cache. If you read through the thread you referenced farther down, you should have noticed the words cache override.


certainly i didn't mean that. you didn't understand...

if your drive caches audio data,
checking the box "drive caches audio data" indicates to eac that it has to clear the drive's cache before re-reading.
it prevents eac for reading twice the same data (it prevents eac to re-read data from the cache instead of re-reading the disc itself -> it prevents an unuseful re-reading - which is not the goal).

in fact, this was a problem for eac (and its method for detecting errors) with certain drives that cache audio data. so the option was introduced in eac. it's a safety option enabled by default upon the detection of drives parameters.

Quote from: Never_Again,Dec 23 2005, 02:11 PM

Quote from: don_pipo_corleone
when eac is "filling red bars", it means that eac has obtained two different results by reading the same sector. so the reading was accurate!!!
If it was accurate, then why different results?


i meant:
the reading was accurate because eac detected an error! if eac was re-reading from the drive's cached data (the data read from the first read - the issue is here!) it would not have detected an error because it should have read the same data.
it is much better explained in eac documentation!!!

Quote from: Never_Again,Dec 23 2005, 02:11 PM

Quote from: don_pipo_corleone
as i remember, some drives do caching while not caching at all for audio extraction!
It would be helpful if you specified what drives those are.


i don't a list but
i own such a drive: yamaha cdr-f1e
i'm obtaining same error reports with scratched cds that produce read error with "drive caches audio data" box checked or not. but with a speed decease issue with the box checked.
so there is no need to check the box as there is not accurateness (toward errors) issue.
saying this,
i was refering to eac documentation (available since eac 0.8 betas)

Quote from: don_pipo_corleone
i'm certainly not very clear!
Certainly not. =) I'm sure you mean well, though.
[a href="index.php?act=findpost&pid=352055"][{POST_SNAPBACK}][/a]
[/quote]

excuse i'm translating (surely not well) from my french understainments (sic).
cu!

EAC question about audio caching

Reply #10
Quote
Quote
Here is my question...   If these cds were ripped with these settings, and there were never any "red bars" and the audio quality was 100%, is it possible that errors were still introduced into the ripped file?
[a href="index.php?act=findpost&pid=351933"][{POST_SNAPBACK}][/a]

Yes, albeit extremely unlikely.

Why do you think so, evereux? I'd say the opposite is true...
If the EAC cache setting is unchecked, EAC is told not to worry about caching. The result of that is simply a sabotaged secure mode.

EAC question about audio caching

Reply #11
From http://users.fulladsl.be/spb2267/
Quote
Audio Caching
All drives cache but not all cache audio. "Yes" informs EAC that your drive caches (= remembers) the audio it reads. As you know, EAC needs 2 reads to find errors - but an audiocaching drive will not read a second time but instead send the cached first read again to EAC. Like that EAC can never find any errors! I will call these slip-through-the-net errors: errors in your rip that EAC and you don't know about. Solution: for such a drive, set audio caching to "yes", which informs EAC it should empty the cache every time - yes that costs speed.
WavPack 5.6.0 -b384hx6cmv / qaac64 2.80 -V 100