DAE caching & dBpowerAMP drive rankings

vbimport

#1

raynb PM-ed me with a few questions, following on from a discussion in this thread.

I hope you don’t mind me answering them in the forum. This allows other members to contribute to and benefit from the answers.

None of the Samsung SH-S203 or 202 drives should cache audio data. There is a lot of erroneous information out there regarding drive DAE features. Software like AnyDVD or DVDFab Passkey running in the background interferes and will produce incorrect detection of caching.

Caching is not cause for concern with secure audio extraction, so long as the software knows how much data the drive caches. It can then compensate by re-reading in larger chunks. This slows things down, but only when errors are detected and re-reading takes place. So long as the software knows the correct cache size and compensates correctly the results will be as reliable as a drive which doesn’t cache.

I would ignore the dBpowerAMP drive accuracy list as it does not take into account the condition of the discs. Therefore regardless of the volume of data, the range of data they are gathering cannot possibly support the conclusions drawn.

If you look at the 2014 dBpowerAMP list you will see that the Sony DRU-810A is in the midfield and the Philips DVD8701 second from last. As any CDFreak knows, these are exactly the same drive - a rebadged Benq DW1640. The difference in firmware could theoretically make a difference, but (almost) never does, especially with modern drives.
In my experience, how a drive behaves & performs when reading damaged CDs is mostly dependent on the chipset used.

There have been many other cases of drives with identical hardware being ranked very differently. Also Lightscribe & non-Lightscribe versions of the same drive, which as far as DAE is concerned are probably identical in both hardware & firmware.

Also they are ranking drives to 4 decimal places and the entire list is covered by less than 1.3 percentage points, a margin I consider statistically invalid in the circumstances.

In my opinion, all their data proves is that if the CDs are in reasonably good condition and the result can be verified using Accuraterip, any modern optical drive will do the job just as well as any other.

It is only when discs have significant damage/degradation, or if there is no external checksum to verify the result (i.e. Accuraterip), that the choice of drive becomes important.


#2

I don’t care anymore about audio data caching since AccurateRip was introduced on both EAC and DBPoweramp…:bigsmile:


#3

Thank you for clarifying the reality of the data Ibex. For a newbie it is hard to distinguish what data/reviews to follow. I appreciate the help.


#4

In EAC you can also uncheck caching.
I usually rip with EAC but I prefer dBpowerAMP for doing conversions.
I usually just listen after doing a rip. Either to the .wavs on the computer or burn back to an Audio CD & listen. If it sounds good to you then that should be OK.
You only need to worry if it doesn’t.


#5

[QUOTE=raynb;2759249]Thank you for clarifying the reality of the data Ibex. For a newbie it is hard to distinguish what data/reviews to follow. I appreciate the help.[/QUOTE]
No problem. There is a huge amount of optical disc related misinformation out there.


#6

[QUOTE=cholla;2759261]In EAC you can also uncheck caching.
I usually rip with EAC but I prefer dBpowerAMP for doing conversions.
I usually just listen after doing a rip. Either to the .wavs on the computer or burn back to an Audio CD & listen. If it sounds good to you then that should be OK.
You only need to worry if it doesn’t.[/QUOTE]

As I understand it, in EAC you uncheck caching IF the drive does not do it, meaning that EAC will not attempt to “blow away” the cache by reading more (and way better than the old method which used repeated drive resets).


#7

You’re probably correct Matth.
I didn’t research the cache setting.


#8

This is info from wiki.hydrogenaud :

Drive caches audio data[edit]
In order for secure mode to work properly, every read request made by EAC must cause the drive to seek data from the CD. If your drive caches audio, subsequent requests for the same data may result in the drive only fetching this data from its buffer, rather than from the physical disc. To prevent this from happening, EAC has a routine to ensure previously requested data gets flushed from drive’s cache. This is done by having the drive read extra data from the disc—more data than the cache can store.
If the “Detect Read Features…” function reports “Caching : Yes”, it is important that you enable the cache flushing routine by checking the “Drive caches audio data” box.
[B]If the “Detect Read Features…” function reports “Caching : No”[/B], 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. [B]What it will do however, is reduce your ripping speed and shorten the life of your drive.[/B]
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” (this setting can be found under the Extraction tab in the EAC Options dialog). 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.
Tip #2: Tip #1 is all you need to know, but if you’re still paranoid that your drive caches audio, feel free to tryFeurio’s audio caching test (Ctrl+Alt+P\Test device\Cache test) or spath’s cache explorer. If either determine that your drive doesn’t cache or caches less than 64 KB of data, then cache flushing isn’t necessary (ignore the reported buffer size when using cache explorer). The reason for the 64 KB barrier is that EAC will never request less than this amount while ripping (link).
Note: If “Drive has ‘Accurate Stream’ feature” is deselected, then “Drive caches audio data” is automatically checked, regardless of whether the drive actually caches audio data.


#9

The other drive feature that is a source of debate … C2 errors.

If the drive supports C2 reporting, and does it accurately, then ripping can be VERY fast, as the C2 status is used instead of double read checking.

If they are VERY VERY accurate, then applying correction may be possible.

See EAC’s other project, DAE quality, for more info


#10

One problem with EAC is that it doesn’t state what size of cache it has detected.

I suspect that it always uses the same value. Which would result in more over reading than necessary (to flush the cache) for most drives, but not enough to clear the cache completely for drives with an unusually large cache size. (My experience with the Benq 5232X supports this view.)

For a definitive answer on caching, I prefer Cache Explorer. Unlike EAC & dBpowerAMP, Cache Explorer reports the raw data (timings & cache size) over multiple passes, so you can reach you own conclusion (it is not always clear cut) and see if the cache size is variable. Most drives are consistent with the amount they cache, but on a few drives (like the ALI Benqs) the amount varies a lot.

The only reliable way to compensate for drives with a varying cache size is to use Cache Explorer to run many passes, note the largest cache value detected and manually set the extraction software to a value larger than that. As far as I know only dBpowerAMP allows the cache value to be set manually.

Another advantage of Cache Explorer it that it can test the reliability of FUA. I have several Lite-On drives which support it. It works reliably on the DVD writers, but on the CD writers Cache Explorer reports it only works 2-3 times out of 5. (dBpowerAMP only detects that the drive supports FUA.)

Of course all this only really matters if you are relying on C2 pointers and/or multiple reading to detect errors. If you can verify the result by checksum (Accuraterip) then all you need is a drive with a fixed read offset (accurate stream).


#11

@ Ibex ,
I have a few questions as I seem to be getting some different results depending on what program I use.
My dBpowerAMP version is an old freeware one.
I rips OK but has fewer settings.

EAC says I have caching when I run the “Detect Read Features” test.

This is the EAC offset test:

Cache Explorer say it’s disabled.
If it is do you know how to enable it ?
Or if I even would want it enabled . I’m thinking disabled would be the best .
C:\Users\User\Downloads\CDDrives\cachex> cachex -i -c -n 3 d:

CacheExplorer 0.8 - spath@cdfreaks.com

Drive on D is BENQ DVD DD DW1650 BCIC

[+] Buffer size: 2048 kB, read cache is disabled
[+] Supported read commands: BEh A8h(FUA) 28h(FUA) D4h(FUA) D5h(FUA) D8h(FUA)
[+] Testing cache line size:
147 kB / 64 sectors
22 kB / 10 sectors
4 kB / 2 sectors

I also ran Feurio! & the cache part is this :
+++++++++++++++++++++++++
++ Cache test
+++++++++++++++++++++++++

Feurio! will now try to determine the size of the cache memory usable for audio data and the max. transfer rate.
To do so, Feurio! will read a certain number of sectors repeatedly and measure the transfer rate.

First 1 sector will be read repeatedly, then 2 sectors, and so on.
Normally the transfer rate will increase, because the more sectors are read, the fewer search operations will be needed.

Number of sectors: 1 (=2 kByte) -> 0.631 MBytes / second
Number of sectors: 2 (=4 kByte) -> 1.147 MBytes / second
Number of sectors: 3 (=7 kByte) -> 1.672 MBytes / second
Number of sectors: 4 (=9 kByte) -> 2.215 MBytes / second
Number of sectors: 5 (=11 kByte) -> 2.710 MBytes / second
Number of sectors: 6 (=14 kByte) -> 3.210 MBytes / second
Number of sectors: 7 (=16 kByte) -> 3.679 MBytes / second
Number of sectors: 8 (=18 kByte) -> 4.116 MBytes / second
Number of sectors: 9 (=21 kByte) -> 4.583 MBytes / second
Number of sectors: 10 (=23 kByte) -> 4.951 MBytes / second
Number of sectors: 15 (=35 kByte) -> 5.975 MBytes / second
Number of sectors: 22 (=51 kByte) -> 8.206 MBytes / second
Number of sectors: 33 (=77 kByte) -> 9.970 MBytes / second
Number of sectors: 49 (=115 kByte) -> 11.182 MBytes / second
Number of sectors: 73 (=171 kByte) -> 0.572 MBytes / second
Number of sectors: 49 (=115 kByte) -> 11.527 MBytes / second
Number of sectors: 50 (=117 kByte) -> 11.410 MBytes / second
Number of sectors: 51 (=119 kByte) -> 11.459 MBytes / second
Number of sectors: 52 (=122 kByte) -> 11.650 MBytes / second
Number of sectors: 53 (=124 kByte) -> 11.753 MBytes / second
Number of sectors: 54 (=127 kByte) -> 11.975 MBytes / second
Number of sectors: 55 (=129 kByte) -> 12.068 MBytes / second
Number of sectors: 56 (=131 kByte) -> 12.254 MBytes / second
Number of sectors: 57 (=134 kByte) -> 12.336 MBytes / second
Number of sectors: 58 (=136 kByte) -> 12.522 MBytes / second
Number of sectors: 59 (=138 kByte) -> 12.631 MBytes / second
Number of sectors: 60 (=141 kByte) -> 12.813 MBytes / second
Number of sectors: 61 (=143 kByte) -> 12.024 MBytes / second
Number of sectors: 62 (=145 kByte) -> 11.930 MBytes / second
Number of sectors: 63 (=148 kByte) -> 12.012 MBytes / second
Number of sectors: 64 (=150 kByte) -> 12.165 MBytes / second
Number of sectors: 65 (=152 kByte) -> 0.556 MBytes / second
Number of sectors: 97 (=228 kByte) -> 0.607 MBytes / second
Number of sectors: 145 (=341 kByte) -> 0.677 MBytes / second
Number of sectors: 217 (=510 kByte) -> 0.703 MBytes / second
Number of sectors: 325 (=764 kByte) -> 0.728 MBytes / second
Number of sectors: 487 (=1145 kByte) -> 0.751 MBytes / second
Number of sectors: 730 (=1716 kByte) -> 0.772 MBytes / second
Number of sectors: 1095 (=2575 kByte) -> 0.780 MBytes / second
Number of sectors: 1642 (=3861 kByte) -> 0.788 MBytes / second
Number of sectors: 2463 (=5792 kByte) -> 0.791 MBytes / second
Number of sectors: 3694 (=8688 kByte) -> 0.797 MBytes / second
Number of sectors: 5541 (=13032 kByte) -> 0.807 MBytes / second
Number of sectors: 8311 (=19547 kByte) -> 0.816 MBytes / second
Number of sectors: 12466 (=29320 kByte) -> 0.830 MBytes / second
Number of sectors: 18699 (=43980 kByte) -> 0.848 MBytes / second


Result:
Maximum transfer rate: 12813 kBytes/Second
Cache size for audio data: 150 kByte



#12

[QUOTE=Matth;2759309]The other drive feature that is a source of debate … C2 errors.

If the drive supports C2 reporting, and does it accurately, then ripping can be VERY fast, as the C2 status is used instead of double read checking.

If they are VERY VERY accurate, then applying correction may be possible.

See EAC’s other project, DAE quality, for more info[/QUOTE]

It is worth mentioning that C2 errors are an event experienced by the drive (an uncorrectable E32 error), not a feature on the disc. A scratch may cause a drive to experience an C2 error, but it is not itself a C2 error. There is a lot of misinformation out there.

Take an audio CD and deliberately deface it by drawing a thick black radial line. This should cause every drive to experience C2 errors. If a drive doesn’t report any errors then it doesn’t support C2 reporting, even if it tells the software that it does. (Or something is interfering with the process, such as a USB bridge or other software.)

But what if drive A reports 1000 C2 errors and drive B reports only 990? Does that mean that drive B is only 99% accurate? That is what many people have concluded, but it is incorrect.

While it is possible that drive B has not reported all of the C2 errors it experienced, it is also possible that drive B is a better reader and has encountered fewer C2 errors. The only way to confirm that a drive has actually failed to report all of the C2 errors is to compare the data read by the drive against a known good copy of the data or checksum.

Consider this scenario. You extract an entire audio CD using EAC or dBpowerAMP (with C2 pointers) and all tracks are verified OK by Accuraterip (with high confidence), except for one which is only marked as secure. In this case you could reasonably conclude that error(s) have gone unreported by the drive.

(Although not necessarily that the drive has failed to report a C2 error it experienced. In certain rare circumstances, erroneous data can be read without the drive actually experiencing an error.)

There is widespread, long-established opinion on the internet that re-reading is more accurate. This appears to date back to the earliest days of EAC when people were mostly using CD/DVD-Rom drives.
In my experience very few read only drives report C2 errors reliably. But writers are normally very reliable. Of the drives in my collection, all of the writers which claim to support C2 pointer do so very reliably. And for me, using C2 pointers on discs with significant damage has always resulted in far fewer unreported errors than the re-reading method.

But why be forced to chose one method or the other when dBpowerAMP can do both in Ultra Secure mode, with as many passes as you like? Although if you are a die-hard EAC fan you can use C2 pointers, then re-rip the disc and manually compare the checksums.


#13

[QUOTE=cholla;2759311]@ Ibex ,
I have a few questions as I seem to be getting some different results depending on what program I use.
My dBpowerAMP version is an old freeware one.
I rips OK but has fewer settings.
[/QUOTE]
Congratulations on correctly guessing the only family of writers I [I]never[/I] use for secure audio extraction. :clap::wink:

I don’t think the DW1640 & 1650 drives cache. But I haven’t used mine for this purpose since 2007.

(Badly damaged audio book on CD-R. Successfully salvaged the second half of a track my Lite-Ons found unreadable, using non-secure dBpowerAMP 11.5. Managed to piece the parts from multiple drives together and polish it into something usable that would pass as perfect to most ears. Proof that even a poor CD reader can occasionally perform miracles.)

The Cache Explorer report is contradictory. Although the beginning says cache disabled, the results show caching has been detected.

I’ve never used Feurio for cache detection. But if I’m interpreting the figures correctly, the results are all over the place.

Do you have AnyDVD, Passkey or similar running in the background? That will produce this sort of erroneous result.


#14

[QUOTE=Ibex;2759318]Congratulations on correctly guessing the only family of writers I [I]never[/I] use for secure audio extraction. :clap::wink:
[/QUOTE]
I do my best. :wink:

[QUOTE=Ibex;2759318]
I don’t think the DW1640 & 1650 drives cache. But I haven’t used mine for this purpose since 2007.
[/QUOTE]
The mixed results are what confused me .

[QUOTE=Ibex;2759318]
The Cache Explorer report is contradictory. Although the beginning says cache disabled, the results show caching has been detected.
[/QUOTE]
That’s the way I read it too but never hurts to get another opinion.

[QUOTE=Ibex;2759318]
I’ve never used Feurio for cache detection. But if I’m interpreting the figures correctly, the results are all over the place.
[/QUOTE]
I could give it a try with a different CD & see what the results are.
This one was a commercial CD but I can use a burned one.

[QUOTE=Ibex;2759318]
Do you have AnyDVD, Passkey or similar running in the background? That will produce this sort of erroneous result. [/QUOTE]
I didn’t have any decrypter running . Or any other program I thought would interfere.


#15

What controller is the drive connected to?

And are you using the standard Microsoft driver or something else?


#16

It should be the standard Microsoft .
Standard Dual Channel PCI IDE Controller
For this drive.
I do have AnyDVD HD so one of the drivers for the Benq is AnyDVD.sys .
But it was not enabled.

My LG BD drive is SATA & has a controller on the SATA adapter .
Silicon Image Sil 3132 SoftRaid 5 Controller

I have a Samsung that is external but it is not connected right now.

I also have a Matsushita in an older computer.


#17

AnyDVD must still be interfering. (One of the reasons I prefer Passkey. ;))

Is AnyDVD running in the taskbar, but “Enable AnyDVD” is not ticked?

If so, try right clicking on the taskbar icon and selecting exit. Then re-run Cache Explorer (I suggest 10 passes).

If that doesn’t work, deselect Autostart in AnyDVD, re-boot and try Cache Explorer again.


#18

AnyDVD isn’t enabled .
It isn’t in the task bar at all.
It doesn’t show in the Task Manager/ Processes .
It also doesn’t show in another software I use named “End it All” for doing forced stops of software if necessary. It is also a good indicator of what’s running.
I have never had AnyDVD set to autostart . It isn’t even in the list of msconfig/Startup .
I will give Cache Explorer a 10 run & see how it does.

I also did the Tip 1 for EAC in the post I made about this.
The log said “There were errors” but it didn’t show they were read errors.
I used a scratched CD as suggested for this.

What do you draw the "thick black line " with on the test you suggest ?


#19

Making a ‘thick black line’ disc is useful for investigating C2 pointer support. (Although I can confirm that the Benq DW1640/1650 drives do not support C2 pointers for audio extraction, despite the prowess as CD scanners.)

All you need an undamaged expendable audio CD, or make an audio CD-R, and a good quality permanent marker (the type you would use for labelling discs) with nice dense black ink.

There are instructions out there saying that you should draw a narrow triangle using masking tape (so the line width and thus errors generated get greater as the disc is played). But for this purpose I just draw a radial line (i.e. running from the centre of the disc to the outer edge, like the spokes on a wheel) on the data side of the CD. Several passes of the pen may be necessary to achieve a nice thick layer of ink. And if possible, scan the disc (using CD-DVD Speed, K-Probe etc.) to verify that it produces lots of C2 errors.

I suggest a line width of about 2mm, but this isn’t critical. Neither is the length; about 10-15mm would be a practical minimum, but you can make it as long as you want.

It is most important that the line doesn’t start at the very beginning of the disc; if the lead-in is covered the drive may not be able to recognise the disc. But apart from that the position isn’t important. The further the line is from the start of the disc, the longer the drive will have to read before encountering an uncorrectable error. It is not necessary to extend the line all the way to the end of the disc, but you can if you want to. Just do whatever you think will suit your needs best.

All I wanted a disc to quickly verify that C2 pointers are functioning correctly (some USB bridges can interfere with them), so I made a disc with a short ~2mmx10mm line placed close to the start of the disc.


#20

[QUOTE=cholla;2759324]
I also did the Tip 1 for EAC in the post I made about this.
The log said “There were errors” but it didn’t show they were read errors.
I used a scratched CD as suggested for this.
[/QUOTE]
Normally you would use an undamaged CD for cache testing, so as not to introduce other factors which may affect the timings.

Detection of caching is based on performing two read tests - one a straight single pass read, the second re-reading everything a second time in small chunks. If the drive does not cache, the second test with re-reads will take more than twice as long as the first (twice as much data is being read and there is the time taken for the optical pickup to move back & forth). If a drive caches the time with re-reads will be almost as quick as the single read, as the second read is actually being retrieved from the high-speed, near instant access time cache RAM.

The principle behind using a scratched CD to verify if a drive caches is that, so long as the damage to the disc is severe enough, the drive must encounter errors. Because C2 pointers are disabled, the drive will attempt to detect errors by re-reading each area of the disc twice, with a non-matching result indicating an error. But if a drive caches the re-read will always produce a matching result, as in reality it is retrieving the first result from the cache memory. So in this scenario a drive which caches will be unable to detect & report read errors. If any read errors are recorded in the log (not sync errors) then the drive doesn’t cache, but if none are reported the drive must be caching.

This testing method will (probably) not work with dBpowerAMP as it re-reads each track in two complete passes, whereas EAC reads in small chunks (thus requiring much back & forth movement of the OPU, which puts much stress of the drive mechanism).

It is also not infallible. It assumes that the test CD is sufficiently scratched that the drive must encounter read errors. But modern drive can cope surprisingly well with even deep scratches (if the angle between the scratch & groove is reasonably favourable), so this is a bold assumption. (Hence the use of a ‘black line’ disc to test C2 support.) And if a drive caches inconsistently it may report some read errors (which would be interpreted as an indication that it doesn’t cache), but not report others which were re-read from the cache.

There is a variation on that test, which is to judge how quickly the drive re-reads when attempting to correct an error (this test requires a drive which supports C2 pointers). Using a damaged or defaced CD, turn the error correction level up so the drive will make more re-read passes when it encounters a read error. Judge the speed of the re-reading by observing the red lights in EAC and listening to the drive. If they flash by very quickly and the drive isn’t seeking loudly then the drive caches.