LIGHTNING UK!

Your drive complained that it couldn't write to the disc. Try burning at a faster speed, your drive will probably do a better job and burn quality will actually increase. 8x or 12x should be fine.

Your disc in the above example is actually just over 128MB in size so it wouldn't fit in the buffer. Increase the buffer to 140 and it will. My guess is that you then won't see the prompt about directshow not returning data (and that's because the problem won't occur, not that it would just hide it). Can I just check that if you mix the songs up in the CUE (i.e. change the order to 3, 1, 2) that with a 128mb buffer it's still the last track that gets the error? My guess is that whichever song the buffer size lines up with is the one that produces the error message. Re. Successful Verification: Due to drives reading and writing CD-DA sectors with an offset (i.e. it doesn't write the data I give it exactly where I tell it to - and every drive is different), it's not possible for ImgBurn to do a byte level comparison on that data type. ImgBurn will just be checking the sectors are readable - which they are The option to make ImgBurn do a byte level comparison on CDDA tracks can be found in the settings - but as it only works for drives where the read/write offset cancel each other out exactly, I don't recommend you change it. It would just make verify mode complain about millions of 'mismatches' on all other drives.

No, you got the 8x verbs. Get the proper 2.4x ones with the MKM-001-00 dye. Notice yours are MKM-003-00.

'Continue' is the same as 'Ignore', which basically means ImgBurn will be zero filling (digital silence) the remaining 1MB of that file. Do you notice that when it's doing the initial 'analysing' pass (right after you've clicked the write button) that it hangs for a while? I don't see why that stage would work ok and not the real decode pass. Expect a PM from me.

Ideally your machine should be using NTFS, not FAT or FAT32.

Ah, I found the problem... it's not just x64 OS's that it happens on For some reason the directshow filter opens the file for read + write access and that causes some of my code to fail because it's only allowing for programs to open the file with read access - well, I don't want them writing to the file whilst I'm using it! The changes I've made to get this working were actually the same as I did a couple of days ago for another bit as a result of my learning something new about the inner workings of the 'CreateFile' API function. So basically you'll have to wait for 2.4.3.0 to burn APE files when using the radlight filter

Is the drive connected directly to a motherboard mounted USB port? (i.e. not off a backplate cable or via a USB hub) Some USB controllers just don't like certain external enclosures. I doubt there's much you can do besides change it for a different one. The problem dates back a good few years now (with all burning software) and I'm not sure anyone really found the reason for the I/O commands to fail like that.

Try burning those discs at 6x and 8x too seeing as the drive seems to think it also supports those speeds. rundll32 errors don't mean much unless you know what they were running.

ok so what do you see on the disc when you first open it up? Just a BDMV folder and a CERTIFICATE one? Won't PowerDVD play it?

'Write Error' means exactly what it says. The drive ran into a problem trying to write to the disc. Verbatim media is better quality and drives just prefer it over anything else. Get some of the 2.4x stuff (MKM-001-00 dye) and you'll be fine. Did you install the SB01 firmware ok?

Seeing as those discs are designed for burning at 8x, maybe they'll work better if you burn at 4x or 6x rather than 2.4x. Your drives support for them at 2.4x seems a little iffy, hence why it's erroring out now and then.

Check with your laptop manufacturer to see if they've released any firmware updates for the drive. Try and get some 2.4x Verbatims (MKM-001-00 dye) instead of the 8x (MKM-003-00 dye) ones. The error you're getting when setting the layerbreak is because you're trying to reuse a failed disc.

If the program says something else is using it then the API used to open them (CreateFile) has failed and that's the error windows reported - ImgBurn is simply passing it on. I don't have x64 anywhere right now to look into this myself, sorry.

Please post the burn log.

aajr, Why do none of your quotes / posts work properly? They all contain html stuff for some reason. Which browser are you using and which editor are you using for creating your post? (Quick/Normal/Rich Edit)

That pretty much just leaves the filter drivers then (Tools menu). Have you tried putting the controller into ATA mode just to see if it works?

Ok so do you have the latest Intel Matrix drivers installed?

All that's happened there is the I/O command has eventually timed out, meaning ImgBurn has regained control and quit nicely. Do you need your controller in AHCI mode? Which motherboard are you running? Which controller is the drive attached to?

Yes it's plain then.

Because the new NVIDIA drivers are rubbish and return bogus error codes to ImgBurn - they corrupt the real ones. Older versions of the driver are fine.

Erm probably (whatever that is).

Is the drive on an nvidia chipset?

Is this drive attached to an nvidia chipset motherboard by any chance?

If the disc you've got now work ok, I'd just go for a simple read -> write then. As mentioned in my previous post, you'll need to burn it onto a double layer disc. We recommend Verbatim DVD+R DL 2.4x speed discs - because they actually work! (unlike many others)

I assume you're using 'Read' mode yeah? If the disc is 7GB then the image will be 7GB... it's a 1:1 copy (whereby the data from every sector on the disc is added to the file on your hdd). To burn it you'll need a double layer disc. If it's a data disc would it be used in a DVD player anyway? Normally those things are for Video discs.