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: Still in doubt with Defeat audio cache EAC (Read 5598 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Still in doubt with Defeat audio cache EAC

Hi guys, I'm back with another question.  ;D I have read a lot about EAC settings etc. in these years, but I'm still in doubt about Defeat audio cache option. My drive doesn't seem support this option based on eac detection and of course I always left unchecked the option. Drive in question is a HL-DT-STDVDRAM GT51N, but searching on web I have read a rip's log with same drive with audio cache option checked. I looked in the forum and somewhere but someone says that is better to check and someone says no if EAC report that drive doesn't cache audio. My drive seems to recognize well the read errors, slow down speed and back up fast etc. without defeat audio cache.

My rips are perfect except some disc that I had to rip with another drive bought (this also doesn't support defeat cache audio) because laptop's drive can't rip. My question is even if my drive supports caching respect what eac detects, the quality of my rips may be compromised without cache audio checked?

This is my primary drive:

Spoiler (click to show/hide)

This is second drive:

Spoiler (click to show/hide)
"Always account for the change."

Re: Still in doubt with Defeat audio cache EAC

Reply #1 –
afaik so long as the rip & log reports no errors and has been accurately ripped it's not an issue. Enabling the setting causes rips to take longer, which in theory will reduce the lifespan of your drive; wrt a negative point.

Re: Still in doubt with Defeat audio cache EAC

Reply #2 –
The matter is really only a point of contention for preservationists, where the media in question is unlikely to have been ripped by anyone before, and therefore you have no AccurateRip basis to determine if your rip is "accurately ripped" to begin with. Plus, if you're a preservationist who shares with sites like Archive.org, or similar sites for backing up rare and original media, they'll likely tell you to use Defeat Drive Cache, or a similar method with whatever other OS or ripper you use.

It probably won't be necessary if you do a basic test and copy method, but if your disc is not indexed by anything like AccurateRip yet, it may be worth the peace of mind to enable it anyway.

Plus, if you have certain drives like Plextor that happens to also be a model that caches, turning on the "Defeat Drive Cache" is as simple as the application sending a special vendor command to the drive to disable the cache, and doesn't involve complex reading patterns to otherwise defeat the cache.

Slightly off topic, some may or may not also offer mixed advice on C2 read pointers. Drives which support this properly, enabling the functionality will speed up secure ripping immensely. Of course, some other authorities might also ward off such advice as well. If you want a truly accurate rip of 100% unique, never before widely seen media, do you want fast, or do you want accurate?

Re: Still in doubt with Defeat audio cache EAC

Reply #3 –
Yes, I know someone like sites sharing flac album etc, wants Defeat Audio Cache checked. I think my drive is indexed with AccurateRip. I usually rely on test&copy with AccurateRip confirmed. My drive, according to what EAC says, support C2 pointers but reading around here about the lack of reliability on a lot of drives I preferred to disable it.

I have to say that my primary drive HL-DT-STDVDRAM GT51N can read fast depending on pressing cd or can read and copy slow if some disc is old or with scratches. It can re-read sectors if there is some problem etc. but I can get accurate copy as the log and AccurateRip says.

So in conclusion you say that the cache is not necessary in any case if my drive behaves as I described?
"Always account for the change."

Re: Still in doubt with Defeat audio cache EAC

Reply #4 –
Quote from: Linuxx on
It can re-read sectors if there is some problem etc.
That is precisely when you want cache defeat. When you ask it to re-read you want it to re-read from the CD and not from the cache; that is, you want it to read as much a chunk as necessary to get the offending sector out of the cache.
So the reasonable thing would be to either enable both re-reading AND cache defeat, or none. (Apart from Test & Copy - that "re-read" of course defeats cache anyway.)

dBpoweramp uses the following strategy: burst first, and only if it fails AccurateRip it brings out the secure rip machinery. (IIRC that's a mode dBpoweramp won't let you "disable" other than by disconnecting your network cable or blocking the AccurateRip IP addresses ...)
dBpoweramp's approach is safe except in a very few odd cases, like when there is an error in a part of the CD that isn't part of the AR calculation (it chops off beginning/end in order to be robust against offset issues - often you can verify against the CUETools database if you are paranoid).

Oh, and a couple of more things:
* "Pro burst": from my experience, the immediately most promising "re-reading" strategy when AR fails, is to use a different drive. Often that would just resolve everything and get an AR match. (This of course assumes the CD is in the AR base!)
* Drive wear ... run-of-the-mill drives aren't that expensive.

Re: Still in doubt with Defeat audio cache EAC

Reply #5 –
Quote from: Porcus on
That is precisely when you want cache defeat. When you ask it to re-read you want it to re-read from the CD and not from the cache; that is, you want it to read as much a chunk as necessary to get the offending sector out of the cache.
So the reasonable thing would be to either enable both re-reading AND cache defeat, or none.
What?
https://wiki.hydrogenaud.io/index.php?title=EAC_Drive_Options#Drive_caches_audio_data
Quote
Checking the "Drive caches audio data" box with drives that are reported by EAC as not caching will not improve EAC's accuracy. It won't improve EAC's ability to detect errors nor EAC's ability to correct them. What it will do however, is reduce your ripping speed and shorten the life of your drive.
korth

Re: Still in doubt with Defeat audio cache EAC

Reply #6 –
Quote from: korth on
What?
https://wiki.hydrogenaud.io/index.php?title=EAC_Drive_Options#Drive_caches_audio_data

Huh, did I misread the OP?

At least the first drive does cache, but if I got it right, the OP has set EAC not to defeat it. Cache & not defeating it --> risk that re-reads are pointless --> stick to burst, for the reasons outlined in the the four first sentences in the paragraph you link to.

And then: https://wiki.hydrogenaud.io/index.php?title=EAC_Drive_Options#Burst_Mode

Re: Still in doubt with Defeat audio cache EAC

Reply #7 –
Maybe I misread the OP. I interpreted
Quote
My drive doesn't seem support this option based on eac detection
as Detect Drive Features returned "Caching : No"
korth

Re: Still in doubt with Defeat audio cache EAC

Reply #8 –
Ok, now I'm even more confused....So what Porcus says is that apparently my drive defeats the cache even if the option is not enabled?

Anyway I've always relied on what hydrogen wiki linked by Korth says: If the "Detect Read Features..." function reports "Caching : No", it is not necessary to enable the flushing routine. Checking the "Drive caches audio data" box with drives that are reported by EAC as not caching will not improve EAC's accuracy. It won't improve EAC's ability to detect errors nor EAC's ability to correct them. What it will do however, is reduce your ripping speed and shorten the life of your drive.

But I have to say that I think my drive works well without cache because relying on TIP#1 of wiki "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. If EAC is capable of displaying a read error then cache flushing isn't necessary. Ignore any sync errors that may be displayed; they are irrelevant to this test.",
with lot scratches on cd my drive sometimes stuck on a certain point or fails with all rows red.

But after this I'm still confused......Enable or leave disabled as I have always done until now?
"Always account for the change."

Re: Still in doubt with Defeat audio cache EAC

Reply #9 –
I suggest sticking with the advice from the wiki. Drive specs showing the presence of a buffer does not mean the drive will cache audio data while ripping. Run the 'Detect Drive Features' test. If in doubt, try TIP#1. If still in doubt you could try TIP#2.
The wiki also suggests disabling C2 even when the 'Detect Read Features' test says the drive is capable. Capable doesn't mean reliable. Unless you know that the drive can use the C2 setting reliably, disable it.
korth

Re: Still in doubt with Defeat audio cache EAC

Reply #10 –
Quote from: Linuxx on
apparently my drive defeats the cache even if the option is not enabled?
You may or may not have gotten "cache" and "cache defeat" mixed up. If a drive doesn't have a cache, you need not and should not tell EAC to defeat it, like korth points out.
 
I took your first post to indicate your settings, rather than output of any test results. I might have read you dead wrong?

Here is a different tool to check whether your drive(s) cache: https://web.archive.org/web/20150620034911/http://download.cdfreaks.com/download/155/cachex.zip
What do they report? Be sure to use a scratched CD.
(Or just rip burst as long as you get AR verification, and come back when you (e)ac-tually encounter a scratched CD.)

Re: Still in doubt with Defeat audio cache EAC

Reply #11 –
Ok, I used Cachex and this is the result:



This mean that my settings are ok right?

Read mode               : Secure
Utilize accurate stream : Yes
Defeat audio cache      : No
Make use of C2 pointers : No
"Always account for the change."

Re: Still in doubt with Defeat audio cache EAC

Reply #12 –
Yes, keep "Defeat audio cache: No". (Sorry if I messed up stuff - I am actually surprised to find an un-caching modern drive.)

Do the same thing for the other drive.

And consider enabling C2 pointers for troubled CDs - although my first line of defense here is actually "use the other drive".

Re: Still in doubt with Defeat audio cache EAC

Reply #13 –
I thought most drives have terrible C2 error implementation.

Re: Still in doubt with Defeat audio cache EAC

Reply #14 –
Quote from: Porcus on
Yes, keep "Defeat audio cache: No". (Sorry if I messed up stuff - I am actually surprised to find an un-caching modern drive.)

But my drive is not modern. This pc is 10 years old. Anyway I took a longer test to be safer:



Quote from: Porcus on
Do the same thing for the other drive.

And consider enabling C2 pointers for troubled CDs - although my first line of defense here is actually "use the other drive".


For other drive I'll wait because I left it at a friend's house, but i think that also has no cache. I'll let you know of course.  ;)

EDIT: I took a test with Feurio and this is the result:

Spoiler (click to show/hide)

Cache size for audio data: 23 kByte is irrelevant? I mean, such a low value also indicates that it doesn't support audio cache?

"Always account for the change."

Re: Still in doubt with Defeat audio cache EAC

Reply #16 –
I've fixed the links in the Hydrogenaudio Knowledgebase article for the section "Drive caches audio data"
https://wiki.hydrogenaud.io/index.php?title=EAC_Drive_Options#Drive_caches_audio_data
Note: I couldn't find a reliable archive link for the Feurio software.
An audio CD should be in the drive for cache tests.
Quote
Cache size for audio data: 23 kByte is irrelevant? I mean, such a low value also indicates that it doesn't support audio cache?
http://web.archive.org/web/20140626091839/http://www.digital-inn.de/threads/cache-detection-in-eac.32972/
korth

Re: Still in doubt with Defeat audio cache EAC

Reply #17 –
I found Feurio on another site in trial version. Korth I have read your second link but I'm still confused. So 23kb require Defeat cache audio enabled or no? I rely on Cachex?
"Always account for the change."

Re: Still in doubt with Defeat audio cache EAC

Reply #18 –
"No". In the link, André explains that EAC requests 64 k at the time, so any smaller cache will be "automatically defeated".

Re: Still in doubt with Defeat audio cache EAC

Reply #19 –
So Porcus, I will sound repetitive, so my drive doesn't have audio cache? Should I stay on Defeat Audio Cache Off? I know this is paranoid but I ripped 429 CD ahahahahah!
"Always account for the change."

Re: Still in doubt with Defeat audio cache EAC

Reply #20 –
All tests indicate you shall keep "defeat cache" off. For this drive.

As for those 429, the "defeat cache" setting you chose would not matter [at least those that were ripped with this drive]. How many failed AccurateRip?

Re: Still in doubt with Defeat audio cache EAC

Reply #21 –
So those 24kb of feurio cache are not to be considered as real cache?

All 429 cd match with AccurateRip. Just a few differ samples for some random tracks but I thinks is for different pressing cd. But AccurateRip match is always high. For example this is last cd ripped:

Spoiler (click to show/hide)
"Always account for the change."

Re: Still in doubt with Defeat audio cache EAC

Reply #22 –
Quote from: Linuxx on
So those 24kb of feurio cache are not to be considered as real cache?
Short answer: consider it as "0" and turn Defeat off.

Longer answer: the cache is a little bit of memory for the drive. If the ripping software needs to re-rip, it wants to ensure that it is re-read from the CD, rather than having the drive just look up the cache and come up with precisely the same bits without re-reading.
But since EAC reads in 64k chunks, every single read operation will defeat a "24k" size memory. A drive that can only remember 24k, will need to re-read if it gets a request for 64k.


And, rips that are accurate are accurate, basically:
Quote from: Linuxx on
  7   | (1976/1991) Accurately ripped, or (3/1991) differs in 72 samples @03:35:12-03:35:13
This means that nearly 2000 entries in the CUETools database are the same as yours. And three differ.
But those three are most likely the same files from the same erroneous rip, submitted three times. (Also, there are likely duplicates among the 1976 as well.) I.e., disregard it; since you have ripped the CD yourself, rather than going out for pyracee, you only need to have someone out there agreeing with you.

AccurateRip is better guarded against resubmission of duplicates. It is capped at 200, which is also a total overkill. 2 is enough for an accurate rip. (Sometimes you get strange results because among two different pressings there might be one that has a defect in the master. That is another chapter. Ripping cannot fix that. CUETools Repair can sometimes, but then you need to know which of those is correct, and if you cannot hear anything wrong then ... )

Re: Still in doubt with Defeat audio cache EAC

Reply #23 –
Excellent explanation Porcus!  :) I'm glad my drive doesn't have audio cache and my rips are perfect. Today I'll try to check even if the other drive doesn't really have the audio cache and I'll let you know.  ;)
"Always account for the change."
 

Re: Still in doubt with Defeat audio cache EAC

Reply #24 –
Ok @Porcus glad to know that also my second drive doesn't support cache audio!!!  :D  :D  :D



Spoiler (click to show/hide)

Dilemma solved!  ;D
"Always account for the change."