LIGHTNING UK!

What happens if you return the 'write type' to Sao/dao? Have you tried doing a full erase on the disc?

You always need to post a log file. Please include one showing the burn and verify stages. I assume you've checked your image is OK using the appropriate tool? Please also post a kprobe scan (@ 4x) of the disc. I'd like to see the actual graph rather than the text output showing the results, so have it save a screenshot please.

Sorry, I just googled 'DH-16ABS firmware' and that was the first link. I didn't even notice Google had given an incorrect match. Glad you got it sorted anyway.

ImgBurn uses the 'Track Information' reported by the drive for these things and yours claims the 'Logical Track Start Address' (LTSA) is 16580608 rather than 0. If you have access to another drive, try reading the disc in that instead. If you have a Dell machine, this firmware update may fix the issue. http://www.dell.com/support/home/us/en/19/Drivers/DriversDetails?driverId=R211597

Your drive must be misreporting certain disc info. Can you copy + paste everything from the info box on the right when you're in Read mode pleas?

There isn't really a 'comments' field in cdtext terms. It's not as flexible as ID3 tags and alike.

Etfsboot is for Vista onwards. You should be looking at the XP guide.

It doesn't look like that disc was burnt with ImgBurn. Actually, that doesn't look like a DVD video disc at all. Have you muddled them up somehow?! Do you have the log of the burn + verify operations?

Put the disc in and see if ImgBurn can read the cdtext back ok. Use the media info button when you're in read mode.

If you simply compare (hex type / byte level comparison) the files on your hdd to the ones on the disc, you'll see they're the same. That's why I can say it's nothing to do with the burning stage.

It burns exactly what you give it, so the issue is nothing to do with burning itself. You'll need to look elsewhere for the cause of the problem I'm afraid.

Post the log please.

Try at 8x rather than max and / or try some different discs.

Yeah there's nothing wrong with that burn.

If what you're doing doesn't work, it probably isn't possible.

You save the image as a png or whatever file and then attach it in your post.

Any current LiteOn model should do the trick. It'll probably end up being an iHAS124 / 324 revision E / F. I haven't tested the F revision personally, but I have tested the E and know it overburns just fine. And when I say 'overburns', I mean it can burn up to the extended capacity allowed by the burnermax payload.

Get a second drive and share the load between them. With regards to the drive just stopping burning, like I said, it could be the drive has just had enough and is now a bit temperamental. So if you get another drive, see if that also gets stuck randomly during burns. If it does, it must be your system as a whole. 4x is always what I've used in testing overburning on MKM-003-00 with the LiteOn drives.

It appears your drive just stopped burning or the system stopped processing I/O. Like you, ImgBurn is simply having to wait for other stuff to happen. That's why the rate decreases to zero and the remaining time goes to Unknown. Btw, 1x isn't possible (it would burn at 2.4x anyway) and 4x is the recommended burn speed for the mkm-003-00 discs. Looking at your log, your drive has burnt a lot of discs. It could be giving up the ghost or it could be a system issue. It's impossible for me to say.

The graph is easier to read than the text. Can you screenshot that please? That said, the max values look fine. So then like I said, it's down to the source image being correct and your playback device being able to play the disc correctly.

Well, burn and verify a disc so I can see that's all 100% OK. Then scan the disc at 4x using kprobe so I can see the burn quality. If they both check out ok, there's nothing more for us to do.

Chances are, the VMware driver isn't passing through the command. They need to allow unfiltered access to drive but many only pass through commands they understand... Not 'vendor unique' ones used for stuff like changing the book type settings. ImgBurn doesn't care that the name has been changed. If you're on the lg tab, it'll be sending lg commands.

Ideally I'd have liked to see the log from the verify operation too. If it burns, verifies and the kprobe scan looks ok, there's no reason for it not to work. The issue must then lie with the source image or the playback device. Your settings are fine.

Ok, so it burnt that time.

You're confusing queue files and cue files. Just load the cue in Write mode as if it were an image file. I.e. Load it via the 'source' box.