Am I missing someting here?

The documentation that I find all refer to installing old ASPI interfaces to XP and Win2k etc to extract data with EAC. This is not exactly straightforward.

Is this really necessary seeing as the other option is 'Native Win32 Interface'. This has got to be better that installing dodgey 4 year old drivers. Right?

The SPTI interface can sometimes create problems (e.g. blue screens) with device drivers (mainly if using USB/Firewire...). Andre has said that either it works or it dosent...And if it does work, then it should be as good as ASPI. -Martin.

You can obtain errors from time to time with win32 native interface.
Aspi has been well tested; and has proven to be more compatible, stable and standard.

You consider that not all the versions of aspi can extract audio digital. One of the most popular and stable versions is the legendary version 4.60 (very old), this was done originally for Windows 95 and NT, and has demonstrated to be very stable; even it seems to work better than new versions, and still is compatible with XP and Win2000.

What type of errors? data transfer errors?

Thanks for that AOJ; But the question has got to be:

Is it any better?

Do I get a better quality of extract, and thus resulting WAV file? I have had perfect rips, and no errors (that I know-of) from those Native Win32 extractions. Works like a dream.

But is it a question that the Native Win32 drivers are glossing over errors where the ASPI driver would retry? This is a very grey area, and I am not sure that it is entirley clear.

I want to get the best possible ripped WAV file, so that from that I can get the best possible compressed version.

I am begining to suspect that the difference between the two interfaces will be marginal, and if that is indeed true, then I would be happy to live with the simpler, cleaner Native Win32 interface, and acccept the fact that it maybe 0.5% worse than using the 4.60 ASPI interface.

Does anyone have any comments, or want to add to this statement?

AFAIK the only difference can be speed and compability.
If what you use now doesn't create problems I would perhaps try VOB, nero and adaptec. But only to see if speed is any different.

There is no quality difference in DAE (only security, but that is independent of ASPI vs. STPI). It either works or it doesn't. If STPI works fine for you, that's good. You can try one of the ASPI implementations mentioned by JanS to see if you can improve performance, but your rips will be the same.

Good idea!..I have just puchased/installed Nero 6.6.0.12..

Just to make sure: JanS was talking about Nero's ASPI drivers (http://www.nero.com/de/ASPI_Driver.html).
Just copy wnaspi32.dll into your EAC directory and select ASPI.

If you encounter any errors there is. There will be a difference depending on the drive & there will be a difference depending on the software.

Quality implies a scale (bad -> good). DAE either works or it doesn't.
If it doesn't (caused by scratches or similiar), the DAE tool will either report an error (and try re-reading) or output a faulty file.
The purpose of secure DAE tools is to spot errors, try rereading to fix it and abort extraction if it can't be fixed.

No. I was talking about the hardware incompatibility and systems errors (more common problems in win32 interface than aspi); not data transfers errors (rip errors).

The Win32 native is in some cases less stable than aspi and less standard; but, if you obtain good performance and stability with him, then not problems.

" systems errors "

By this I am assuming you are talking generally about the two methods on Windows as used by any CD ripper (rather than specific to EAC and its implementation)

"The Win32 native is in some cases less stable than aspi and less standard;"

" less stable " every driver on the system of WinXP / NT / 2000 goes through the same process (CreateFile, DeviceIoControl), programs talking to CD rom drives use the SCSI pass through method - data is passed straight to the drive. I would also hazard a guess that ASPI on WinXP has to go through Native Win32 (edit: just checked Neros Wnaspi32.dll and it uses Native DeviceIOControl).

" less standard " how can it be less standard? all drivers use the same 2 function calls, want to talk to your USB mouse in a program, same calls, seems pretty standard to me.

Obviously, how could a simple DLL access drives in another way on 2K/XP ?

Yes, this exactly also has happened to me.

In my work I have installed many PCs, and, generally I prefer (when I work with DAE and Cd-roms) the ASPI interface: more fast and more stable than Win32 native interface; but this has been my personal experience, another people could prefer SPTI.

They could have gone one level lower, bypassed CreateFile / DeviceIOControl and gone into the Kernal direct, I have seen apps do that - there is documentation on the web (but not from Microsoft).

Really, which app does that ?

I believe certain disk defragmenters. I don't have the kernal function names off hand, but if you are keen :

Install the Microsoft Hardware development SDK,
See some device driver examples (pull out the kernal function names - the ones you are looking for are Ntxxxxxxx function names) - program does not have to be a device driver to access them),
Then install standard Microsoft Platform SDK - you need Dependancy walker,
Install a few commercial applications, or drivers - walk them and see what they are using (and hope they are not dynamic linking, Dependancy walker will not list dynamic linking).

I don't have hours to waste doing that, it is pointless - it was just your reply that Nero's driver would 'obviously' do something one way, was not obvious at all unless you looked into it.

...but all this is sadly going off-topic.

I think you misunderstood my remark and that you are now arguing on
topics you don't know well.

First, the "Hardware development SDK" you're talking about is called
DDK (Driver Development Kit), and I have been using it for years.

Second, I don't know what you're hoping to find with your dependency
walker thing, but it is clear that one can use NtDeviceIOControlFile()
instead DeviceIOControl(), or anything down the DeviceIOControl()
calling chain until the interrupt call. That was not my point.

Third, my point was this : since Nero's ASPI layer for 2K/XP comes
as a single DLL, it was obvious that it is just a wrapper for native
2K/XP interface, in other words SPTI. And while it is obvious for
Nero's 2K/XP ASPI, it is not true for Adaptec's 2K/XP ASPI, which
comes with a real driver (aspi32.sys).

This is the last I will say on this, as your posts have become insulting "arguing on
topics you don't know well", picking on minor things such as the name of SDK.

Well I suppose you are clearly right I know nothing of the sort (in the last 3 years I have written 4 device drivers, of those 1 was a Windows ME .vxd to direct talk to CD drives (specifically to bypass wnaspi32.dll, you can find it on dbpoweramp.com), for Windows 2000 WDM I have written two .sys USB device drivers).

You have:

Wnaspi32.dll >> DeviceIOControl >> NtDeviceIOControlFile >> System

and if we were to get back on topic (and not nit pick), I responded to posts that it is silly to say that DeviceIOControl (using scsi-pass through) is less stable than Wnaspi32.dll when it calls the very same thing.

Also it is very 'obvious' that wnapsi32.dll does not call IOCTL_CDROM_RAW_READ through DeviceIOControl, thus not using SCSI Pass through (IOCTL_CDROM_RAW_READ uses one of microsofts .sys drivers, has a benefit of not requiring admin privileges in Win2000/XP to access the CD drive like scsi pass through).

Now I suppose at this point it is 'obvious' I am 'arguing on
topics you don't know well'. I suggest you take it to PM (as not to bore people with techno babble that is irrelevant to 99.9999999999% of people) if you wish to test my knowledge on CD drives / SCSI Commands / device drivers (Win 9x, NT, WDM) / Wnaspi32.dll

Which is correct for Nero's ASPI and wrong for Adaptec's ASPI.
Instead of losing your temper, compare the two wnaspi32.dll
and you will learn something.

VOB (ASAPI interface) has never failed me with 7 different drives (Plextor, NEC, Pioneer, Samsung) and 3 different OS's (Win2K, WinXP, Win2K3).

I recall reading somewhere that certain versions of EAC would not work correctly with SPTI if the Intel Application Accelerator was installed.