I just bought a new DVD drive, a Plextor PX-800A, which I've found it is not one of the 'true' Plextor drives but a cheaper rebranded model that the company sees fit to distribute. This drive comes with Plextools Pro which lets you perform a diagnostic of your drive. It told me that my drive has 2048 kb cache, although it does not cache audio data.

This came as a bit of a surprise, and it meant that I had to rethink my EAC setup as the usual Jiggafellaz guide, that I have always unquestionably followed, advocates the use of the "Drive caches audio data" option:
http://img112.imageshack.us/img112/1661/ex...onmethodcb5.png
It's very close (most likely a copy) of one of the configs I have seen on these forums

I now know that my drive cannot cache audio data so I'm left scratching my head as to what to do about this option. I think that the caching of the audio data is part of the error correction process but to stick with this option seems like to lull myself into a false sense of security.

Do you know if your drive is capable of caching audio data? If it isn't what do you do? Utilise the C2 method instead? Does this impact on other settings? I'm after some advice here

I know that "Accurate Stream" should be selected as EAC confirms I have this feature after using the "Detect Read Features" option. It will let me select caching before running the test, but like I said, my drive doesn't support this and it then defaults to selecting "Drive is capable of retrieving C2 error information" after running the test:
http://img266.imageshack.us/img266/29/eaccache2ie1.jpg

for more info on these two features see the hydrogen audio wiki here

So, what is the best way to configure such a drive?

I have run a few tests with different setups and I have been getting some strange results when using the pre-beta version of EAC 0.99 with Accuraterip on a keydisc (Massive Attack's 100th Window), and on the usual 0.95b4 release (also with Accuraterip installed, despite it not appearing in the log file?). I'm not sure whether or not it is Accuraterip, caching, or the C2 process causing the strange results. I have tried again with a different keydisc: Massive Attack's Mezzanine (see logs below)

So below you will find the results of testing the Mezzanine CD with EAC ripping to v0 with Lame 3.97
STAGE 1.1 - pre-beta EAC 0.99a: cache selected: C2 deselected
STAGE 1.2 - pre-beta EAC 0.99a: cache deselected: C2 selected
STAGE 1.3 - EAC 0.95b4: cache selected: C2 deselected
STAGE 1.4 - EAC 0.95b4: cache deselected: C2 selected
STAGE 1.5 - EAC 0.95b4: both cache and C2 option selected
STAGE 1.6 - pre-beta EAC 0.99a: both cache and C2 option selected

Note: I erased the CRC values for both test and copy before starting each extraction so as to work from a clean template

***********************************************
STAGE 1.1
edit: test 1 using pre-beta 0.99a with Massive Attack Mezzanine (Accuraterip keydisc)
Log 0.99 pre-beta: cache yes: c2 no


EAC had a big problem with Track 8 and took about 90 minutes to extract this track before reporting it as having errors. Curiously, Accuraterip seemed to have a good deal of confidence in the track being wrong (must be from all the user submissions).
Despite the errors it came out as "Copy OK" according to EAC?! I can't really explain this. It might have something to do with the config telling the drive to do something it doesn't do? If so this raises some doubts in my mind about the reliability of my configuration

***********************************
STAGE 1.2
log 0.99 pre-beta: cache no: c2 yes


Strangely enough, the C2 feature detected the same Copy CRC as the rip in STAGE 1.1. What differed was the Test CRC in STAGE 1.1

CONCLUSION: rip was more accurate with C2 feature

Next test is with a more stable version of EAC...

***********************************
STAGE 1.3
log: EAC 0.95b4 cache yes: c2 no


This method is, I imagine, quite a normal way for a lot of people to rip their discs. There were no errors despite the cache option being selected and my drive not supporting caching. :shrug:

***********************************

STAGE 1.4
log: EAC 0.95b4 cache no: c2 yes


There appeared to be no problems with the rip at first but closer inspection points to some worrying CRCs (highlighted) for tracks 9 and 10

****************************************
STAGE 1.5
For kicks, I decided to see what would happen if I tried to select caching and C2 in the tickbox. Logic tells me that this is silly so forgive my indulgence

These are the results:
log: 0.95b4 cache yes; c2 yes


Bizarrely, no errors seemed to have occurred although there are a hell of a lot of CRC mismatches! These occured in tracks 3, 5-11 but I've edited the results out for sake of brevity.
If we do the same test on the pre-beta 0.99a version we get similar issues (see below)

*************************************
STAGE 1.6
log pre-beta 0.99a cache yes; c2 yes


At least this time EAC acknowledges the errors

***********************************

In conclusion, it would appear that Jiggaefellaz ripping guide works even on those drive who don't support the features selected to extract discs. Or at least, that selecting the cache option on my drive which doesn't support such a facility works as well as the C2 route.

The caching option was fine on the standard (0.95) release whereas the C2 option was fine on the pre-beta release. When you combine the two, in either version of EAC, you get problems

I have to admit, I'm a newb at this but I thought the results may have been interesting to someone...

Please edit your post so that it uses "codebox" and "/codebox" instead of "quote". You should also remove portions of the log files that have no direct bearing on your post and crop your images so they don't extend beyond the natural margin of this site. The images aren't even necessary since they provide no additional information from what your logs already show, actually. All this has made your post annoyingly difficult for me to follow.

I'll tell you right now, however, that it is safe to trust EAC's test to determine if you need to check the audio caching setting, despite what you may read in third party manuals.

Here are some other points you should know to help you better understand what you're seeing...

With all other things being equal (and they are usually not), drives that don't cache audio are better than drives that cache audio.

You're better of not using C2 when ripping discs that can't give you matching CRCs (the caching setting was not your problem here).

Setting EAC's error recovery to high will reduce the likelihood that EAC reports an error. More important than this is to understand that EAC's "no errors occurred"/"the were errors" messages are far from conclusive.

EAC versions prior to V0.99pb1 don't have the ability to add AccurateRip information to the log files. You'll need to select and copy them from the dialog that gets displayed and manually paste them.

You need to know that V0.99pb1 has quite a few bugs that will be fixed in the next release. One of them is that it provides AccurateRip results using the test pass rather than the copy pass!

As Greynol stated above, when all other things are equal, a non caching drive is better then a caching drive, or atleast I think he means that when it comes to extracting audio using EAC, a non caching drive is to be prefered... With caching drives EAC has to "defeat" the cache which slows down the ripping process considerably... If told so, EAC will follow the same routine with none caching drives which absolutely makes no sense at all as... There is no audio cache to be "defeated" (formerly disabled)..

So what you considder a bad thing (as some online guides make you believe) is actually a good thing... With you're drive it is perfectly safe to have the drive caches audio button UNticked as your drive doesn't cache audio... I own the same drive and EAC and Cache Explorer both tell me the drive does not cache audio... Ticking "drive caches audio" will do nothing but slow down your ripping speed and stress the drive more, it will in no way make your rip more secure or accurate...

FWIW, people who do own caching drives if possible go out of their way to make the drive behave like a non caching drive... On this forum you can read about the use of the FUA-command, an experimental switch people use to make their real plextors behave like it doesn't cache audio... Your drive left the factory that way...

And as in fact the drive is a Nec drive (which are known to have poor C2-error detection) I would recommend not using it, other than whether you tick or leave caching unticked, selecting C2 can influence the reliablitly of your rip (C2 will speed your ripping speed but with the way it is implented in most ? drives it will in some cases let errors go by undetected leading to a rip with flaws in it).

Just my two cents,
Mill

Thanks for the advice and the replay. Sorry about the formatting. Hopefully I've made it a little easier to read

Having read your post and Millenium's below, it seems like the C2 switch is the route I should be following when trying to produce accurate rips but that this is problematic as my drive has poor C2 error detection. Bah! Looks like I'm going to look for another drive.

Thanks for the feedback

Please don't get me wrong here, I'm not saying your drive is a bad drive. That it (probably) has poor C2 error detection capabilities does not make it a bad drive IMO. If producing accurate rips is you're goal and you're not bothered by the incapabilty of the drive to overread (which if I'm not mistaking it doesn't do) you're drive will do just fine... The use of C2 in EAC is some sort of shortcut to speed up the ripping process. If you're using T&C however and the CRC's match you can stop worrying bout ripping errors caused by faulty C2/caching settings. If still insecure bout the results, use AR, if you're rips match the ones stored in it's database ripping errors are excluded altogether, no matter what your settings were..

But coming back to your drive; my experience with it is that it was able to flawless rip CCP-discs that other (true plextor) drives were unable to..

Change your logs so they appear inside a codebox, rather than in a quote and it'll be even better. You should probably include the CRCs in the second log (or whichever log had all matching CRCs) for the tracks that you show later where the CRCs don't match.

Disabling the use of C2 error information is the route you should be following if you're going to use this drive with EAC. As Millennium already stated, in EAC, C2 pointers are only used to speed up a rip. EAC does not use C2 pointers to ensure that your rips are accurate!

I would normally say rely on AccurateRip results first and then matching CRCs, but in the case of V0.99pb1, you must also rely on matching CRCs because there is a serious error in the code!

One thing that I didn't mention is that secure mode in V0.99pb1 and V0.95b4 is exactly the same. The differences you see have nothing to do with the version of EAC you're using. Repeat the tests several times if you don't believe me.

You're welcome. Sorry for being so crabby in my response yesterday.

If you want my advice about EAC V0.99pb1, use either AccurateRip or T&C, but do not use both at the same time!!!

Wow, the day has come Greynol actually advised AGAINST the use of AR (okay, in combination with T&C).. So miracles do happen . Just pulling your leg here ofcourse, when it comes to EAC/DAE I take your word for it... The fact that you of all people give advise like this makes me fear the worst.. And now I'm even more anxious to see the release of pb2....

Once again, thanks for the replies, and I perfectly understand how irritating the initial post must have been - it wasn't exactly easy on the eye (doh!). I've ran a quick test on the same disc using Accuraterip and EAC 0.95b4 in secure mode and it came out great. Thanks for that.

I think I'll wait until the next version of EAC comes ot before I start any further tampering

On a side note, I can't seem to get the logs to appear quite right in these codeboxes (my first time using them). I thought it would be a simple matter of removing the [-quote-][-/quote] tags and replacing them with [-code-][-/code-] (without the minus signs, of course), but it seems to look exactly like a quote

Greynol is simply pointing out that ONLY in the case that T&C fails (checksums don't match), if AR reports that the rip was accurate then you are GUARANTEED to have a bad rip because the copy that was saved is NOT the one that matched the AR database.

You need to use [-codebox-] and [-/codebox-] (without the minus signs, of course ).

Well put!!! I wish I had thought of that!

Ah, so the AR result is compared to the Test-run instead of the Copy run with seperate tracks as well...I was hoping this would only be the case with image rips, bummer.... But I trust the problem will be solved with the forthcoming release pb2...