The Plextor RW Drive "-usefua" testing thread ...

[JeanLuc]

Hi folks ...

to support André (and Plextor owners), I think it would be a good idea to start off a thread that deals with EAC user's experience with the undocumented and non-recommended (due to no test results at this time) -usefua command line switch.

The idea behind this is to gather information whether -usefua works in different system environments or not ...

It has been reported that, in some cases, the "-usefua" option will render your caching Plextor RW drive non-caching ... the drive feature detection will therefore (on some occasions) report your drive as non-caching which can speed up extraction quite a bit.

Using the -usefua switch (simply change your link's properties to X:\...\EAC.exe -usefua), EAC issues an additional command that will flush the cache before re-reading ... this is the same method Plextools handle the buffer issue.

The downside is that EAC.exe -usefua does not always report a Plextor drive as non-caching. It has been reported that the results may vary with different CD's and/or different chipsets/IDE drivers/IDE setup. A bit of a drawback - on the one hand - is an uncertainty in EAC's cache test routines (which are not quite as reliable as I initially believed and whose results may vary with different CD's or system environments) which - on the other hand - is absolutely important to check whether the -usefua command is accepted within EAC or not.

In my actual opinion, it is absolutely necessary to perform a thorough test with a known damaged CD like being decribed in the fourth post of this thread to determine if -usefua works. Running a cache test will only tell you whether the -usefua command line addition is accepted by EAC or not.

To participate in this test is easy ...

1) fire up EAC with the -usefua switch
2) select your "real" Plextor drive
3) insert a CD of your choice
4) run the drive feature detection (Drive options->Extraction Method->Detect Read Features).
5) take down a note: does the Caching result say "Yes" or "No"? Remember EAC's test uncertainty - better use the same disc with and without the -usefua switch and try different times
6) try the aforementioned procedure with a different CD and take down the results as well.
7) submit your test results to this thread.

I suggest the following test report scheme:

1) EAC Version
2) Plextor drive (only 'real' Plextor drives, no rebadges like PX-740A/750A etc.) and firmware revision
3) Plextor IDE setup (like primary master, secondary slave etc.)
4) Mainboard chipset (like nVidia nForce 2, Intel 440BX, SiS 745 etc.)
5) IDE driver (Vendor-specific or Microsoft standard)
6) EAC read interface (like Adaptec ASPI, Nero ASPI, ASAPI or Microsoft SPTI)
7) CD used for drive feature detection / cache detection results (YES or NO is sufficient ... just type in what the EAC test tells you)

Maybe this could be a sticky thread (hint @ André) and maybe some of you have some ideas for improvement ...

Cheers

Sven

Edit: additional info
Edit: clearing up some stuff (thanks to greynol for that)

[Martin]

Hi JeanLuc

Nice idea about a testing thread for the -usefua switch. I would just recommend you to make the testers actually do some real extractions and error tests as just using EAC's drive features test isn't enough... The reason i'm saying this is that i have searched for info on Andre's implementation of the -usefua switch here on the EAC forum and i found this comment from him :

"But I just used a sniffer to have a look how PlexTools is clearing the cache... Nice idea how they do it... It is possible that it would also work with other drives that caches.
I am not sure whether I have implemented it correctly, so it would be a good idea to test a modified version with several drives that cache (but not only "Test Drive Features", but really a comparison of how many errors go unnoticed in comparison to the old version where the "Cache" flag is used. (And also compare speeds). Because of several aspects, the "Test Drive Features" could tell that a drive has now no cache anymore, but use it nevertheless for extraction."

Source :
http://www.digital-inn.de/77551-post16.html

[JeanLuc]

Yes, I started to check the very same thing doing some extractions yesterday with my Premium ... all I have to find is a CD that contains some (but not too much) CU errors to play around with ...

Fot now, I have tested 4 different CD's with my Premium and the 716A

1) EAC Version 0.95B3
2) Plexwriter Premium 1.06
3) Secondary slave
4) nVidia nForce 2 on ABIT NF7-2S
5) Microsoft standard IDE drivers
6) SPTI Interface (additionally tested with Adaptec ASPI)

Results:

CD 1 / YES
CD 2 / YES
CD 3 / YES
CD 4 / YES

-------------------------------------------------------------------------

1) EAC Version 0.95B3
2) PX-716A 1.09
3) Primary master
4) nVidia nForce 2 on ABIT NF7-2S
5) Microsoft standard IDE drivers
6) SPTI interface (additionally tested with Adaptec ASPI)

Results:

CD 1 / YES
CD 2 / YES
CD 3 / YES
CD 4 / YES

As for -usefua extraction results ... the speed increase (due to deactivated cache flushing) is very promising and the drive does indeed perform re-reading (with C2 being deactivated) but no read errors are being reported after performing the max. number of re-reads ... only sync errors are (although Plextools C1C2 scan tells me that there are a lot of read errors).

I'll keep tracking this issue ...

[JeanLuc]

OK ... here comes some more testing. I created an Audio CD with 6 times a track of 10 Minutes. The track does consist of a 440Hz sine. I afterwards damaged the CD's 6 tracks with increasing intensity and thus created an artificially damaged disc.

Attached is a Plextools Pro C1C2 scan that shows C1 and CU errors (C2 errors are way off the scale so I turned off showing them).

As you can see, there are various amounts of CU errors in every track.

I then fired up EAC with the -usefua option and selected the Premium as a reader ... drive setting was "Accurate Stream" only and I was using secure mode (of course).

The first and second track extracted successfully without EAC reporting an error. The wave compare with the original file did not reveal any differences ... the Premium's internal CIRC circuitry seems to be quite capable.

On the third track, EAC -usefua started re-reading (but the red dots went through very fast ... roughly < 1 sec.) and finally reported uncorrectable errors (but sync errors only) ... the logfile shows 4 suspicious positions at 0:04:28, 0:04:40, 0:04:44 and 0:04:49.

This did seem really odd to me, regarding the high amount of reported CU errors by Plextools Pro so I did a wav compare between track 03 and track 01.

The second attachment shows a part of the EAC wav compare result window - which doesn't even come close to matching the error report in the logfile. To visualize the differences more clearly, I performed a mix-paste between track 01 and track 03 in SoundForge - see the third attachment.

My personal conclusion is:

The commandline switch -usefua doesn't work at all in my system environment since the Premium obviously still caches during DAE ... there are no read errors being reported and the only indication of reading problems is the loss of sync in the damaged areas.

André is therefore absolutely right to not recommend the switch at this time.

I will do some additional testing once I find the time ...

Cheers

Sven

Edit ... some additions

[JeanLuc]

Oops ... the third attachment didn't come through ... here it is.

[Lucky2man]

I don't think your conclusion is right. Your test only shows that EAC possibly doesn't report every error in it's logfile. To get reliable results you need to repeat this test (with track 3) several times and compare the results made with -usefua to those made without -usefua.

[JeanLuc]

The fact is that EAC (using -usefua) does report 4 sync errors for track 03 only whereas there are in fact hundreds of read errors ... which is backed up by Plextools Pro that shows an extraction log of some 2 MB at 50% of track extraction (before I cancelled because it simply took too long).

From my experience, EAC does indeed reliably report every read error with proper DAE cache handling ... but as I stated above:

I will do some additional testing once I find the time ...

[Xenion]

1) 0.95b3
2) PX-712 1.07
3) IDE Primary Master, No Slave on this IDE Channel
4) Intel i875P / Intel Mainboard D875PBZ Rev 3.01
5) Using the latest Chipset Drivers from Intel Website
6) Nero ASPI
7) Eric Clapton / Unplugged: Caching=Yes
7) Dire Straits / On The Night: Caching=Yes
7) Pink Floyd / PULSE: Caching=Yes
7) Mark Knopfler / Ragpicker's Dream Limited Edition: Caching=Yes

Now as my drive is reported to cache audio data i should check "drive caches audio" i guess. i don't get any speed improvement (as this is no other setting to my normal eac setup)

[JeanLuc]

I guess then you'll have to stick to burst mode with T&C since the 712A (I have one connected to my notebook) is rather slow in secure mode with cache flushing on ...

[Xenion]

Originally Posted by JeanLuc

I guess then you'll have to stick to burst mode with T&C since the 712A (I have one connected to my notebook) is rather slow in secure mode with cache flushing on ...

yes i actually consider buying a 716 becuase my 712 only rips with 2.5x in secure mode

[JeanLuc]

Burst mode T&C works good on the 712A, though ...

[Xenion]

Originally Posted by JeanLuc

Burst mode T&C works good on the 712A, though ...

well, i'm paranoid. i would rather use "test&copy images+create cue sheet" in seucure mode if it were available for my wavpack archiving

[pop]

1) 0.95b3
2) PX-716AL 1.01
3) IDE Seconary Master, No Slave on this IDE Channel
4) Epox 8RDA3+ (nFoce 2 ultra)
5) NVIDIA nForce Drivers 5.10
6) Nero ASPI v.
7) AC/DC - Ballbreaker -> (EAC reference cd) -> caching=yes
8) Metallica - S & M [Disc 1] -> (EAC reference cd) -> caching=yes
9) Ozzy Osbourne - No More Tears -> (EAC reference cd) -> caching=yes

When uncheck 'Drive caches audio data" extraction speed last track on full cd is 38x-42x.
All Tracks Accurately Ripped.

1) EAC V0.95 beta 3 from 26. August 2005
2) Plextor PX-712A 1.07
3) Primary Slave
4) SiS 648FX
5) Microsoft Standard
6) Microsoft SPTI

CD1 (Pink Floyd - Echoes Disc 1): YES
CD2 (Pink Floyd - Echoes Disc 2): YES
CD3 (Pink Floyd - Animals): YES
CD4 (Dire Straits - Money For Nothing): YES

Doesn't seem to work on my system. I am wondering about two things:

Does it have anything to do with D8 being the read command selected in EAC?
Does my Plextor really re-read the data when copying with PlexTools or is it something that either works with EAC and PlexTools or doesn't work at all?

[JeanLuc]

Originally Posted by SebMares

Does my Plextor really re-read the data when copying with PlexTools or is it something that either works with EAC and PlexTools or doesn't work at all?

When using Plextools, your drive will re-read only when CU errors are being reported by the drive. CU errors in Plextools (CU = uncorrectable C2) are the same errors that are called "C2" in EAC ... so enabling C2 in EAC will roughly do the same.