LIGHTNING UK!

It's never witten in the log and that's the way I like it.

Find out the chipset used on your motherboard and then visit their website and get the latest chipset drivers. To find out which one you're using, load up device manager and look in the 'system' branch. You'll see a bunch of entries by the same manufacturer - i.e. Intel......, Via......, SIS......., NVIDIA........ etc.

Did you forget to do that bit?

No it's not.

It asks if you want to retry (or at least it should do ) It may only happen if you have multiple copies queued for that image, can't remember exactly.

There's no reason to use the Nero ASPI layer, use whatever ImgBurn selects by default.

Indeed.... it's all garbage.

I must be missing something here... surely a 'retry' is as simple as swapping discs and clicking the 'Write' button again?!

Again, I think that goes back to it not really closing the discs properly - especially if it fails and then works on a subsequent attempt.

You may also find that if you can somehow burn slightly less you won't be on the outer edges of the media and then you might not get write errors when it's trying to write the lead out stuff. The burn part itself has gone one, so if you can do that, you should be ok. The commands I'm issuing are correct, it's just unlucky that your drive can actually perform the 'close' routines properly. I'm going to look at catching the problems during polling sometime later on today... but again, I only hope this doesn't screw things up for other people!

Well it means the OS is more likely to interfere with the burn. Lets face it, if it made no difference I wouldn't have bothered to implement it in the first place!

So in 1.1.0.0 the buffer still goes down? It's got to be something hdd related then. Is that a Via chipset on your motherboard? Have you stuck the latest drivers on for it? Maybe with/without the IDE driver. Try some different cables too incase yours is messed up somehow. Also give the drive a good defrag. There is no way on earth your hdd would only be able to do 10mb/s if it was running properly.

Get some totally different discs. Buy them online somewhere and find some with a decent DYE (i.e. don't go by the name on them alone). Look for Taiyo Yuden or MCC (often branded by verbatim). You can also pretty much ignore that DMA box, it means nothing. You can read more about that in the FAQ.

I guess the 'Buffer' is at 100% when the burn starts, yes? So up the buffer to 256mb (for testing purposes) and try again. Does it then just slowly return to 0 as the burn progresses? (after leadin has finished). If so, it would appear the program can't read from your hdd quickly enough. Check your CPU usage during the burn. It should be very low. If not, DMA may still be a problem for you somewhere along the line. If it were a DVD drive DMA problem, you wouldn't get over 2x, so the problem is with your hdd - or wherever you're reading from. You could just be suffering quite badly from a problem with Windows caching that was introduced in 1.2.0.0. I guess only time will tell.

Wow, I've never seen a drive error out like that before. I do not attempt to detect errors once the command has been submitted and 'polling' has begun - the polling is the 'test unit ready' stuff after the 'Close Track/Session' command. The last 'test unit ready' pretty much sums it up though, your drive failed to finalise the disc and returned a generic 'Write Error' as the reason. Whilst I can try to catch the errors during polling, there isn't much I can do if the drive can't finalise the disc. If you look at when you tried it manually, you can see 2 close track/disc commands being issues. The first tries to ensure the most compatible close possible, the second is like a fallback. The first is still erroring out with a 'Write Error'. That then seems to screw the disc up even more because the second errors out saying there is an incomplete track - which there can't have been as the first would have errored out in that way too. What I really don't understand here is why you're happy to admit the program / drive burns all the other media ok and yet you continue to mess around with this combo when it quite obviously doesn't work properly! The Nero log tells me nothing of any use... they're not meant to.

I realise the 'Write Speed' is low (going by the log), but I don't think enough data has been burnt to confirm that a DMA problem. The program has barely started burning when it errors out. If the firmware update didn't fix anything, buy some different / better discs. The ones you're running are not very good. On top of that, they're really 16x discs and your drive is limiting to 12x at best. That should tell you something.

There are some weirdo drivers at there that stop it from working. As dirio49 said, I tried an extra workaround in 1.2.0.0 but it didn't work. I've added yet another for 1.2.1.0 when it's released so maybe it'll work again then. I choose to display these errors rather than hide them from you, that's why my tools show them and others do not.

No you shouldn't. Doesn't look like that image is built for burning onto an OTP DL disc. You'll have to recreate it using PgcEdit.

If ImgBurn has to do the work (and it's possible), it'll add the flag in all PGCs within that VTS that use that cell. If it's in a different VTS, you're out of luck I'm afraid.

Must be odd ISO images then as I've never come across that problem yet. What sort of data do you expect them to contain? Is the a 'normal' filesystem within the image? i.e. ISO9660, Joliet, UDF ?

cdi is already in the 'supported files' list. It's only basic support though as I don't have the actual file format.

Odd error though. Maybe it's related to your have it connected via firewire.

Pretty much if my 'Auto' code doesn't work for you and you get an error the second I try and read/write something of that size from/to the drive. I've not seen it being a problem of late so you're ok to leave it on auto. There were just some crappy drivers around that only allowed for 32k transfers and not the default 64k. As I've improved the 'Auto' part over time, there has been less and less need for a manual option - but I still like to leave such things in there just in case.

That's not really RAW as I think of it, that's just the full sector. You can burn 2352 in normal SAO burning mode, and yes, ImgBurn supports that. You need to use RAW mode when burning subchannel info etc. That equates to a 2448 sector, which is what I'd assume alcohol is producing. It also gives you full control over leadin area - normally the drive does all that. I always send the full 2352 bytes to the drive if it's available in the source file. If the drive doesn't support 2352 (I'd found some old pioneer 104 drives didn't), I had to flick back down to sending 2336 bytes and manually convert the sectors myself. Most of the time though, the drive will only actually look at 2048 (well, for MODE1 data anyway), and as you mentioned above, the drive regenerates the ECC stuff itself.

Probably not because I for one like to see which image I've just burnt - regardless of if it's been deleted!