LIGHTNING UK!

The content of the image is irrelevant. Power Calibration Errors are always due to a bad hardware / firmware / media combination. I realise that goes against what you think (and so won't believe me!) but I can assure you it's true.

burn it again to the same disc and post up a copy + paste job of the log. It's also worth ticking the little 'Verify' box so the program checks that what's been burnt can be read back. If that's all successful, I have no idea where any problem is coming from - apart from the ISO being bad in the first place.

You posted this (and another one) in the 'ImgBurn Support' forum. I moved them.

If you're going to try and get technical about things and show some raw command data, please at least tell me EXACTLY where you're getting it/reading it from! From what little you've said, I would assume you're saying it comes from reading the physical format information, as part of the 'Read Disc Structure' command. That 32 changing to a 31 is correct. It means it gone from being 'recordable' to 'embossed' (i.e. burnt). I think your problem lies elsewhere.

What i mean is, if you'd extracted the dvrflash.exe program to that folder, you wouldn't have gotten that error. So something went wrong somewhere... maybe you extracted it with path names and it's now in a subfolder of the real pioneer one.

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 ?