LIGHTNING UK!

The 'Write Error' is being returned as a deferred message, meaning it dates back to something ImgBurn was doing a while back. Don't forget that drives have cache. The command ImgBurn just sent doesn't have to be the one the drive is actually processing. Your Googling attempt on the error code from Alcohol wasn't right. It errored out with the same error ImgBurn got - i.e. 'Write Error'. That really isn't a good sign. There's obviously a bigger problem somewhere. Likewise, this would indicate a bigger problem too... Are you forced to use IDE drives? Does you board actually have an SATA controller or is it pretty old? Which chipset does your motherboard use?

Define 'did not work'....

Oops, I forgot about this. I'd actually just email it to you, there won't be a 'release' as such. Maybe you could PM me a decent email address to send it to?

It should be easy to find the cause of problems like that, just look in regedit at the following key. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\AutoplayHandlers ImgBurn adds entries under 'EventHandlers'... look at the keys starting with 'Handle*' and 'Play*'. Then look under 'Handlers' for the keys starting with 'ImgBurn*'. I'm 99.9% positive ImgBurn isn't to blame for your problems. To me it sounds like you uninstalled something and it didn't remove its autoplay handlers properly.

Why is your machine unable to burn at an average rate of above 1.4x? If the source files are on a network drive and it's really that slow, make an image first and then burn it. You'll be riding the BURNProof feature for the entire burn otherwise and that's never a good thing. The image file you burnt that did actually verify ok should work just fine. Take a look at the disc via IsoBuster and see if it looks ok that way... it might just be Windows playing silly buggers.

When buffer recovery kicks in the first thing ImgBurn does is totally fill it's own buffer... after that it can't possibly be doing any more 'reading'. When that's done it waits for the average queue length to drop to the desired value. So basically, it's not ImgBurn that's keeping it high.

If you install to the desktop/wherever can you copy the file to program files?

Sometimes disabling these programs isn't enough, you have to actually uninstall them before they'll stop doing what you've told them not to. In my opinion you should probably uninstall them anyway if you've no idea which one is doing it and none of them are giving you any indication that they're blocking something. You don't sound like a computer nOOb so why have all that rubbish installed anyway? Do you often open up files (viruses) from people you don't know in emails etc? These things get into your system by something you do, so if you don't 'do' anything in the first place, they don't get on there!

That's where the 'that works properly' comes in.... buggy filter drives are a system wide problem though I usually like to see filter drivers with newer dates in the copyright field but if they're not really updating the software these days then I guess it's as good as you'll get.

The basic nature of the build mode screen doesn't really lend itself to that, all you have is the 'Information' tab and the 'Calculate' button.

ImgBurn is just an exe, there's no reason for it not to be compatible with anything that works properly!

Can you try reading off the original disc and see if it does the same thing? Or burn the image to disc with Alcohol and then try reading it back with ImgBurn? The disc info from the panel on the right when looking at the mounted image in a virtual drive would also be helpful.

Because they live in a world where only 'picture' image files exist

The log entries were wrong because the drive/system returned an error when ImgBurn tried to set the layer break. The drive is now reporting the LB in the correct place (The one ImgBurn tried to set it to - 1,913,760) so I wouldn't worry about it.

redbook, gear, pxhelp20 and imapi are ok.... delete the rest. I thought you'd already posted the filter driver list before, but I guess that was in another (similar) thread... my bad

It's probably the UPX compression used on the exe. It would make sense that whatever's blocking it wouldn't be worried about readme files

Update DVD Flick.

If you want to 'copy' an original XP SP2 disc just follow the 'how to copy a disc' guide in the Guides forum. If you're looking to do a slipstream one just copy the contents off the original disc to a folder, patch in SP3 or whatever and then add that top level folder to the 'Source' box in Build mode. Switch to the 'bootable disc' tab and add the boot image file (emu type None, sectors to load 4) and build your new image.

What does your batch file currently look like?

Losts of people have old LG drives in their machines, a lot of companies use them. Old drives and new discs just don't match.

I don't know enough about DVD Audio to implement anything like that for it.

So even when the file doesn't already exist on your hdd, you still can't create a new one? Something you've got running is blocking it and only you can track that down I'm afraid.

This has got nothing to do with ImgBurn, please discuss it elsewhere.

You can't cancel because ImgBurn isn't in control. Windows is dealing with an I/O request and until it finishes, ImgBurn is basically stuck in limbo.

I don't follow you? The BIN/CUE is the image and that's what ImgBurn creates. You just can't mount them in VCD because it only supports CCD images for Audio CD's. If you want a CCD image you'll have to read the disc using CloneCD.