Help - Search - Members - Calendar
Full Version: Drive Caching Question
Hydrogenaudio Forums > CD-R and Audio Hardware > CD Hardware/Software
Mitch A
I'm getting conflicting information on whether my drive caches or not, I usally use T & C burst mode but I have few scratched which I want to rip.

EAC reports my drive LITE-ON DVDRW SOHW-1673S as Caching, Feurio! CD Manager doesn't have the ability to cache
exec
QUOTE(Mitch A @ May 3 2008, 16:20) *

EAC reports my drive LITE-ON DVDRW SOHW-1673S as Caching, Feurio! CD Manager says my drive doesn't have the ability to cache.

I also tried Tip#1 from wiki's EAC Drive Options instructions and the drive could detect errors.

Is it safe to say my drive doesn't cache?


I don't know if Feurio really understands caching of audio data when it says "caching". In this case I would trust EAC and not Feurio.

Edit: According to daefeatures your drive seems to cache.
Irakli
QUOTE
I don't know if Feurio really understands caching of audio data when it says "caching". In this case I would trust EAC and not Feurio.


Well, actually Feurio does quite extensive testing to determine whether your drive caches or not. Furthermore, it says exactly how much KB does your drive cache. However, if Feurio reports that drive caches less than 64KB, it is safe to assume that drive does not cache when ripping in EAC (since EAC reads audio in blocks of 64KB, IIRC).
Mitch A
I ran the Feurio test again and this time it says my drive does cache, 891kb. I guess I do need to enable caching.

CODE
Informations from INQUIRY command:
Manufacturer: LITE-ON, Product: DVDRW SOHW-1673S, Version: JS0D
Synchronous data transfer: Not supported


Reading device capabilities: OK
Maximum speed: 8467 kByte / second (47.9 times)
Cache size: 2048 kByte
Read CD-RW: Yes
Read Bar code: No
Read UPC code: Yes
Read ISRC code: Yes
Return C2 error pointers: Yes
Read R-W subcodes: Yes
R-W subcode de-interleaved: No
Read CD-DA: Yes
Read CD-DA correctly: Yes

====================================================================================================
=

+++++++++++++++++++++++++
++ Cache test
+++++++++++++++++++++++++

Number of sectors: 1 (=2 kByte) -> 0.001 MBytes / second
Number of sectors: 2 (=4 kByte) -> 3.779 MBytes / second
Number of sectors: 3 (=7 kByte) -> 5.288 MBytes / second
Number of sectors: 4 (=9 kByte) -> 6.529 MBytes / second
Number of sectors: 5 (=11 kByte) -> 7.920 MBytes / second
Number of sectors: 6 (=14 kByte) -> 9.493 MBytes / second
Number of sectors: 7 (=16 kByte) -> 9.940 MBytes / second
Number of sectors: 8 (=18 kByte) -> 11.496 MBytes / second
Number of sectors: 9 (=21 kByte) -> 12.367 MBytes / second
Number of sectors: 10 (=23 kByte) -> 12.647 MBytes / second
Number of sectors: 15 (=35 kByte) -> 10.786 MBytes / second
Number of sectors: 22 (=51 kByte) -> 14.255 MBytes / second
Number of sectors: 33 (=77 kByte) -> 13.951 MBytes / second
Number of sectors: 49 (=115 kByte) -> 13.109 MBytes / second
Number of sectors: 73 (=171 kByte) -> 13.478 MBytes / second
Number of sectors: 109 (=256 kByte) -> 14.100 MBytes / second
Number of sectors: 163 (=383 kByte) -> 15.047 MBytes / second
Number of sectors: 244 (=573 kByte) -> 14.347 MBytes / second
Number of sectors: 366 (=860 kByte) -> 14.518 MBytes / second
Number of sectors: 549 (=1291 kByte) -> 2.675 MBytes / second
Number of sectors: 366 (=860 kByte) -> 14.793 MBytes / second
Number of sectors: 367 (=863 kByte) -> 7.092 MBytes / second
Number of sectors: 368 (=865 kByte) -> 10.864 MBytes / second
Number of sectors: 369 (=867 kByte) -> 10.937 MBytes / second
Number of sectors: 370 (=870 kByte) -> 10.966 MBytes / second
Number of sectors: 371 (=872 kByte) -> 10.996 MBytes / second
Number of sectors: 372 (=874 kByte) -> 14.814 MBytes / second
Number of sectors: 373 (=877 kByte) -> 14.202 MBytes / second
Number of sectors: 374 (=879 kByte) -> 14.514 MBytes / second
Number of sectors: 375 (=882 kByte) -> 14.222 MBytes / second
Number of sectors: 376 (=884 kByte) -> 14.422 MBytes / second
Number of sectors: 377 (=886 kByte) -> 13.858 MBytes / second
Number of sectors: 378 (=889 kByte) -> 14.777 MBytes / second
Number of sectors: 379 (=891 kByte) -> 14.649 MBytes / second
Number of sectors: 380 (=893 kByte) -> 7.760 MBytes / second
Number of sectors: 381 (=896 kByte) -> 5.376 MBytes / second
Number of sectors: 571 (=1342 kByte) -> 2.473 MBytes / second
Number of sectors: 856 (=2013 kByte) -> 2.478 MBytes / second
Number of sectors: 1284 (=3019 kByte) -> 2.510 MBytes / second
Number of sectors: 1926 (=4529 kByte) -> 3.051 MBytes / second
Number of sectors: 2889 (=6794 kByte) -> 2.464 MBytes / second
Number of sectors: 4333 (=10191 kByte) -> 3.663 MBytes / second
Number of sectors: 6499 (=15285 kByte) -> 3.636 MBytes / second
Number of sectors: 9748 (=22927 kByte) -> 3.724 MBytes / second
Number of sectors: 14622 (=34390 kByte) -> 3.717 MBytes / second
Number of sectors: 21933 (=51586 kByte) -> 3.825 MBytes / second

-------------------------------
Result:
Maximum transfer rate: 15047 kBytes/Second
Cache size for audio data: 891 kByte

############################################
#### FINISHED
############################################


Firehawk
if you need another source, try Cache Explorer.
Mitch A
Get's even stranger

One cache test with Cache Explorer showed 1235kb

Then I did it again and it said no cached detected
greynol
QUOTE(Irakli @ May 3 2008, 09:30) *
However, if Feurio reports that drive caches less than 64KB, it is safe to assume that drive does not cache when ripping in EAC (since EAC reads audio in blocks of 64KB, IIRC).

Well the drive still caches even when ripping in EAC, but it's safe to tell EAC that it doesn't cache.
RamonSalazar
QUOTE(Mitch A @ May 3 2008, 16:20) *
EAC reports my drive LITE-ON DVDRW SOHW-1673S as Caching, Feurio! CD Manager doesn't have the ability to cache
Hmm, usually this question is the opposite: Why Feurio sais my drive caches but according to EAC it doesnt. Its strange that Feurio reports the drive as non-caching but EAC as cachhing. Feurio has the better detection method... Odd. Try cache explorer, but i would set the drive as caching in EAC. There's no harm in that.

Edit: typo.
greynol
QUOTE(RamonSalazar @ May 4 2008, 14:31) *
Try cache explorer, but i would set the drive as caching in EAC. There's no harm in that.

I wouldn't be so sure wink.gif...
http://www.digital-inn.de/133067-post36.html

EAC's test is no less safe for its purposes than any other test. This entire scare over the caching issue was based on some drives that cache 37kB which don't need flushing with EAC.

Testing for cache is not the easiest thing to implement...
http://www.hydrogenaudio.org/forums/index....mp;#entry547702

With respect to the drive in question, it sounds like EAC needs to be told that it caches. Anyhow, this is simple enough to test using a disc that produces errors...
http://wiki.hydrogenaudio.org/index.php?ti...#Drive_Features (See Tip #1)
Mitch A
Thanks for your help guys, I think I will set it as caching as EAC says it does, site says it does and some of the test confirm it does.
Juan C.
QUOTE(greynol @ May 4 2008, 16:51) *

EAC's test is no less safe for its purposes than any other test. This entire scare over the caching issue was based on some drives that cache 37kB which don't need flushing with EAC.


I have a drive that caches 37kB according to Feurio! and I have been using EAC's disable cache with this drive. It does has an effect on the audio extraction? I should have listened EAC and uncheck the drive caching option? I am a bit confused unsure.gif .
greynol
QUOTE(Juan C. @ May 5 2008, 10:20) *
I have a drive that caches 37kB according to Feurio! and I have been using EAC's disable cache with this drive. It does has an effect on the audio extraction?
Other than adding unnecessary wear to your drive, likely not, though I gave a link earlier to a disc with a specific type of defect that seems to exploit a problem centering around EAC's cache flushing routine when combined with C2 pointers that result in consistent errors.

QUOTE(Juan C. @ May 5 2008, 10:20) *
I should have listened EAC and uncheck the drive caching option?
Yes.

QUOTE(Juan C. @ May 5 2008, 10:20) *
I am a bit confused unsure.gif .
...as were the people who insisted EAC's test was not trustworthy. wink.gif
RamonSalazar
QUOTE(greynol @ May 4 2008, 23:51) *
Thanks Greynol, i didnt know this. smile.gif
greynol
I think it's safe to consider this case as a rare exception. How rare is up for speculation.

In order to be sure that you don't have a disc like this you would need to add diversity to your ripping procedure which includes using different modes as well as drives with different chipsets.
Martel
Just set the drive as caching and do NOT rely on C2 error information. I had some drive which reported a good rip through C2 but produced a mess instead. Be paranoid, do not trust them! biggrin.gif
greynol
It depends on the drive, Martel. This is not the best advice for every situation.
Martel
QUOTE(greynol @ May 6 2008, 08:58) *

It depends on the drive, Martel. This is not the best advice for every situation.

It's the best advice for uncertain conditions, which is exactly the case of this discussion. smile.gif
By choosing that a drive caches (even when it is not) and that it cannot provide C2 (even when it does), you potentially sacrifice only ripping speed/drive lifetime (which most people are not concerned about). If you choose different settings, you risk a bad rip/having to re-rip/re-listen the rip etc.
greynol
You may also sacrifice the ability to get an accurate rip when configuring a drive as caching and not capable of providing C2 pointers.
Martel
QUOTE(greynol @ May 7 2008, 08:28) *

You may also sacrifice the ability to get an accurate rip when configuring a drive as caching and not capable of providing C2 pointers.

And what exactly would be the scenario you are talking about? I've never experienced/heard of this.
What does "accurate rip" mean, anyway?
greynol
Accurate means without errors.

I have seen several occasions where a C2, non-cache flushed rip (or burst rip) was accurate where a non-C2, cache flushed rip was not. Some of them have been documented on this forum. I have seen instances where C2, cache flushed rips were accurate where non-C2, cache flushed rips were not as well. Yes, all of these situations involved ripping the same disc with the same drive.
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Invision Power Board © 2001-2008 Invision Power Services, Inc.