IPB

Welcome Guest ( Log In | Register )

 
Reply to this topicStart new topic
EAC question about audio caching, are my rips okay???
ratscrew
post Dec 22 2005, 18:47
Post #1





Group: Members
Posts: 3
Joined: 21-December 05
Member No.: 26558



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
Go to the top of the page
+Quote Post
evereux
post Dec 22 2005, 19:13
Post #2





Group: Members
Posts: 907
Joined: 9-February 02
From: Cheshire, UK
Member No.: 1296



QUOTE (ratscrew @ Dec 22 2005, 05:47 PM)
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?
*

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
Go to the top of the page
+Quote Post
Cosmo
post Dec 22 2005, 22:12
Post #3





Group: Members
Posts: 913
Joined: 10-January 05
Member No.: 18979



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.
Go to the top of the page
+Quote Post
Shade[ST]
post Dec 22 2005, 22:22
Post #4





Group: Members
Posts: 1189
Joined: 19-May 05
From: Montreal, Canada
Member No.: 22144



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

If you drive read em, they were at least partly readable.
Go to the top of the page
+Quote Post
Cosmo
post Dec 22 2005, 22:50
Post #5





Group: Members
Posts: 913
Joined: 10-January 05
Member No.: 18979



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

This post has been edited by Cosmo: Dec 22 2005, 23:21
Go to the top of the page
+Quote Post
don_pipo_corleon...
post Dec 22 2005, 22:52
Post #6





Group: Members
Posts: 49
Joined: 1-March 02
Member No.: 1425



QUOTE (ratscrew @ Dec 22 2005, 05:47 PM)
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! tongue.gif
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. wink.gif

cu, pipo.
Go to the top of the page
+Quote Post
don_pipo_corleon...
post Dec 22 2005, 22:59
Post #7





Group: Members
Posts: 49
Joined: 1-March 02
Member No.: 1425



QUOTE (Cosmo @ Dec 22 2005, 09:50 PM)
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.

This post has been edited by don_pipo_corleone: Dec 22 2005, 23:08
Go to the top of the page
+Quote Post
LANjackal
post Dec 23 2005, 07:18
Post #8





Group: Members
Posts: 731
Joined: 26-October 05
From: Various networks
Member No.: 25371



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.

This post has been edited by LANjackal: Dec 23 2005, 07:21


--------------------
EAC>1)fb2k>LAME3.99 -V 0 --vbr-new>WMP12 2)MAC-Extra High
Go to the top of the page
+Quote Post
Never_Again
post Dec 23 2005, 15:11
Post #9





Group: Members (Donating)
Posts: 698
Joined: 31-March 04
From: NYC
Member No.: 13152



QUOTE (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.

QUOTE (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?

QUOTE (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.

QUOTE (don_pipo_corleone)
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 (don_pipo_corleone)
there is a post here about that.
Broken link. Should be Plextor, EAC and cache, great news for Premium/PX-712 users

QUOTE (don_pipo_corleone)
i'm certainly not very clear! :P
Certainly not. =) I'm sure you mean well, though.
Go to the top of the page
+Quote Post
don_pipo_corleon...
post Jan 11 2006, 23:42
Post #10





Group: Members
Posts: 49
Joined: 1-March 02
Member No.: 1425



[quote=Never_Again,Dec 23 2005, 02:11 PM]
[quote=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
[/quote]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]

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=Never_Again,Dec 23 2005, 02:11 PM]
[quote=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!!![/quote]If it was accurate, then why different results?[/quote]

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=Never_Again,Dec 23 2005, 02:11 PM]
[quote=don_pipo_corleone]as i remember, some drives do caching while not caching at all for audio extraction![/quote]It would be helpful if you specified what drives those are.[/quote]

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=don_pipo_corleone]i'm certainly not very clear! tongue.gif[/quote]Certainly not. =) I'm sure you mean well, though.
*

[/quote]

excuse i'm translating (surely not well) from my french understainments (sic).
cu!
Go to the top of the page
+Quote Post
liekloo
post Jan 19 2006, 11:51
Post #11





Group: Members
Posts: 456
Joined: 22-March 02
From: Belgium
Member No.: 1596



QUOTE (evereux @ Dec 22 2005, 07:13 PM)
QUOTE (ratscrew @ Dec 22 2005, 05:47 PM)
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?
*

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.

This post has been edited by liekloo: Jan 19 2006, 11:54


--------------------
"E S S E N T I A L" Guide for E A C :

http://users.fulladsl.be/spb2267/
Go to the top of the page
+Quote Post
DARcode
post Jan 19 2006, 14:39
Post #12





Group: Members (Donating)
Posts: 682
Joined: 10-January 05
From: Italy
Member No.: 18968



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 4.70.0 -b384hx6cmv/qaac 2.43 -V 100
Go to the top of the page
+Quote Post

Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 24th October 2014 - 21:48