Hallo everyone!

I would appreciate any help.

While starting to write a CD, EAC pop-ups the following message:
Write error !
Cannot setup device SPTI:0,0,0

Thanking in advance.

have you tried with and without using cdrdao?

I'm confused. I thought it was due to CDRDAO. How can I write without it?

EAC Options, Write tab, there's a tick "Use CDRDAO for writing in the EAC layout editor".

Thank you for your wish to help.



Right. VCSkier's reply made me to study it even more carefully. I deactivated it. It wrote my CD sucessfully. Well, almost successfully - at the end, while closing the CD there was an error, but I can play it back on my CD player without problems. Seems like it ejected the CD without stoping to write it, there was even a scratch on the surface. Strange things ... Anyway, why it refuses to write with CDRDAO? It didn't happen neither with NTI CD-Maker, nor with Nero.

One this machine I have Windows 98SE + latest EAC only.

Anyway, does CDRDAO has any quality or other advantages over EAC writing engine?

CDRDAO lets you burn with corrected write offset on any drive, while EAC's writing engine only on few drives (Ricoh IIRC).

Could you please explain more ?
I'm already able to burn write offset corrected with my LG writer.
Is it possible to overwrite with DAO (and a writer which can overwrite) ? Plexwriters can overwrite, but EAC did not yet support it.

Take a look here & here. So yes, looks like it is possible to overwrite with CDRDAO and a drive which can overwrite.
EAC's native burning engine seems to support overwriting on some Teac drives only (not Ricoh as I wrote above), at least Pio2001 says so.
I'm not sure if we don't confuse overwriting and writing with corrected write offset...

EAC has enabled overwriting into the lead-out for : Teac 56-600, 56-400 and 58.
The threads talk about write offset correction, and not overwriting capabilities... -Martin.

I'm a bit confused on this issue, as well...

While attempting to write a CD-R in EAC (0.95b1) using a Plextor Premium, I received the following error message:


So I started searching around the forums and found this thread. I disabled the "Use CDRDAO for writing..." option in EAC, and the burn worked fine.

Afterwards, I extracted the WAV file and compared it to the original WAV file; there were no errors, so it seems that the burn was performed correctly, with the "write samples offset" that I entered into EAC's drive options "Writer" tab (-30).

So here are my questions:

1) What does that error message mean, and why was it corrected (?) when I disabled the "Use CDRDAO for writing..." option?

2) Is there a better way to correct the error than disabling the CDRDAO option?

3) Is the accuracy of the burning process compromised when using a Plextor Premium without the CDRDAO option?

and...4) Is the Premium one of the few drives that EAC's write engine supports?



Thanks in advance!

~esa


Windows XP SP-2; P4-2.8Ghz

just burn the cd using nero.

Ah, yes... the simplest answer is very often the best...

Thanks



:edit:
BTW, upgrading to EAC 0.95 beta 2 (CDRDAO) has fixed the problem.

That error occured in EAC 0.95 b1, when burning with cdrdao, and if there where a space in the path to cdrdao. The error was fixed in 0.95 b2.

If EAC´s internal writting engine works with your drive, then there is no reason to use Cdrdao... Cdrdao is meant for people with drives that dosen´t work with the internal one...

No... Andre has not said that Cdrdao can overwrite into the lead-out, with more drives than the internal writing engine... He has only said that Cdrdao can write offset corrected...

Yes... -Martin.

They're always related to each other, but I'm aware of the difference...

Nero doesn't support write offset correction. Addditionally, Nero is in general not as attuned to writing audio CDs than EAC is.


I think his question was if EAC's internal write engine supports overwriting with the premium, and rutra (or Pio) said "no" above. But it seems that EAC can overwrite when using a premium and dao, while it can't when using the premium and internal write engine.

Thanks for all the info, guys...

...it really helps clarify the issue!


To sum up, then...
For writing "perfect" (bit-exact) copies with the Premium, the best line-up is EAC v0.95 b2 with the CDRDAO option enabled.
This will make use of the Premium's write offset correction and overwriting features... correct?

If rutra is right, yes...
Why don't you just test it ?
What is your premium's write offset, -30 samples ? Enter it into the write offset box and write a test audio CD having dao enabled. The audio file that becomes the last track must have noise or audio or at least non-null samples until the very end. Then rerip the resulting audio CD. Be sure to create a perfect rip of the last track, that means use overreading into the lead out, if the ripping drive's read offset is negative (you enter a positive read offset correction then) Your premium probably has read offset -30 samples and is capable of overreading, thus your rip will be perfect when entering read offset correction +30 samples and enabling overreading. Then analyse the reripped file in a wav editor: If there aren't 30 null samples at the end, overwriting was performed.
To countercheck the whole thing, you can do the same procedure twice with one exception: Disable dao.

OK, I did the test as described above...

The original WAV and the WAV written with CDRDAO enabled had exactly the same number of samples (3,239,880).


The original WAV and the WAV written with CDRDAO disabled had exactly the same number of samples, as well.


So, according to this test, EAC v0.95b2 supports the Premium's overwriting features whether or not the CDRDAO is enabled.


Does this this test give us conclusive proof?
That is, is there any further reason to doubt the EAC/Plextor Premium overwriting function?

Number of all samples (of the last track, probably)??
That doesn't tell us anything - we need the number of samples which stay noise or which are changed to null samples.
If overwriting has been performed, there should be no difference at all in the last track. Original file and the reripped one are the same. But if not, the number of all samples is still the same, but the files aren't bit identical.
You can open the reripped file in a wav editor and zoom in to the end (both vertically and horizontally), then look if there are null samples. EAC's editor is not so suitable for that, since it has no manual vertical zoom ability. Maybe audacity is OK.
Ah, you could also use EAC's "compare wav" feature for the original and the reripped file. If it reports "different samples" at the track's end position, they're probably the null samples we're looking for.

[offtopic]edit: wait...In LA it's somewhen early in the morning (or late at night) when GMT is 2.33PM, right ? Funny that you do this test at such a daytime...just curious...

edit2: double wait... Is the HA clock (posted today, ...) no longer GMT ? Or is it wrong ? I'm confused...[/offtopic]

Ah, I see... sorry for the misunderstanding!

Yes, the two WAVs written and re-ripped in EAC (DAO enabled and disabled) do indeed have 30 null samples at the end; the number of samples is the same as the original WAV, but the files are not bit-identical. (Confirmed by comparison tests in Foobar and EAC, and confirmed visually in Adobe Audition.)

OK - so, does this indicate that EAC does not overwrite at all with the Premium?


:edit:
number of null samples


I was up early today... I started doing the testing around 5:00AM local time (PDT).

I don't think EAC does overwrite at all anymore. Neither with cdrdao and neither with the internal writing routines. For sure not with cdrdao, since cdrdao doesn't support overwriting. And as far as EAC goes, I asked this very question Andre once, and here's what he answered:

That seems to be the case.

That is certainly valuable information - thanks!


Out of curiosity, I also did the above write>rip>compare test with both Nero (v6.6.0.14) and Plextools (v2.01).

Nero did exactly the same thing as EAC - convert the last 30 samples of the original WAV to null values.

Plextools, however, wrote the entire WAV without alteration, and then appended 573.3 null samples (0.013 seconds) to the end of the file.


So it appears that using Plextools results in an accurate reproduction of the original source file, but adds several hundred null samples to the end of the file...

On the other hand EAC and Nero apparently maintain accurate file length, but alter the original waveform by converting the last few samples to null values.


Comments?

To be sure that i wasen´t giving wrong information, i posted the issue to Andre, on the EAC forum, and i have just got an reply... He said that overwriting is only enabled on a few Teac drives, when using the internal writing engine... So it´s not possible to overwrite at all, when using Cdrdao to burn with in EAC(like Gambit said). -Martin.

Well, yes.
Obviously, GMT doesn't have summer time, causing my actual local time to be 2 hours later than GMT/HA clock. That confused me. (My "user's local time" in the profile is GMT and wrong...)

You did use EAC with offset correction +30 samples for reripping, didn't you ?
Nero writes the CD 30 samples too early/shifted to the beginning. Enter read offset correction null samples on reripping, write and read offset of both -30 samples compensate each other then. Compare again, files should be bit-identical.

Confirmed.

Thanks, everybody, for all the input and help!

Pio2001's response to my similar question (and the subsequent posts) should shed some light.

Basically, Plextools has added one extra sector to allow for for the 30 extra samples - which equates to around 0.0133` seconds.