LIGHTNING UK!

'MODEx/2xxx' isn't really valid and doesn't mean anything. To be honest I'm not sure why EAC even added it like that. Why's it stuck a data track in a wav file?! To burn it, try changing the line to say 'TRACK 18 MODE1/2352'. It's impossible to say if it's mode 1 or mode 2 though. You should be able to find out once the image has been initialised and the mode is shown in the main ImgBurn window. (once you know you can correct the CUE if need be) btw, that's obviously an CD-Extra disc so even when you burn it, it's not a decent copy. The data track should be in a 2nd session but EAC doesn't support that directive in the CUE sheet.

Verify isn't even starting, the drive won't initialise the disc - full stop! So that means that you won't even be able to see the disc's content via Explorer/My Computer or watch it on a PC based software player. A standalone player might be able to read it but I personally wouldn't settle for that. If at all possible, try and get some 8x Taiyo Yundens DVD-R and try those instead (TYG02 dye) Maybe try some Taiyo Yuden 8x DVD+R or Verbatim 8x +R too. (It doesn't look like you've tried +R's yet?)

Still only 4x on those 16x discs?! Is that all the drive can handle or what? Maybe you'd be better off with 8x TYG02's instead. Although personally, I'd probably just get an external drive and use that instead!

Remember that when you're burning an image there's no possibility for ImgBurn to do any 'padding', hence a cell must already exist somewhere that's aligned correctly on an ECC boundary. If it's saying it can't find any then it can't find any! Recreating the image is the easiest option by far. Doing it in build mode (on a 6gb image), I very much doubt you'll need to resort to using VobBlanker to split anything.

It's not a 1:1 if you do it that way. And is sure as hell wouldn't work with a proper Audio CD!

So long as you're not sending new ones every day, it doesn't matter too much

Yes, the quality of the disc often prevents players getting past the layer jump point. The errors on the disc normally rocket at this point and that's why the player gets stuck. DVD-R DL are rubbish for anything except data really, keep clear of them. You can tell which discs are verbatims by looking for 'Verbatim' and '2.4x' on the box. It'll also say 'Made in Singapore' or 'MIS' on it. Of course you could always just buy them online? It's probably cheaper too.

I'd have liked to see a successful Verify along with the burn. If you're running into problems that's the first thing to check... does it verify? After that, you check the firmware is up-to-date on your drive. and then finally you change to better discs - Verbatim 2.4x DVD+R DL (MKM-001-00 dye). You want the ones made in Singapore. Those made elsewhere do not appear to be such good quality.

As the error message kinda hints at, you've got DMA issues. Download + install the latest motherboard bios and chipset/ide/sata drivers and then follow the DMA post in the faq to uninstall your controllers from Device Manager and reboot.

What we really need from you is the log of the burn.

consider 'major bug' removed

I've never made a DVD-Audio disc and I doubt many/any other people have either! As such, you might find you're on your own a bit on this one I'm afraid. I've no idea if it would work.

It's already done - back on the day when you mentioned it.

No, it's designed to be super basic and burn an existing folder structure.

Plextor probably get the info via a special command sent to the drive. It's impossible for a normal burning tool to be 100% accurate because some drives empty the buffer during the burn anyway - like when doing OPC type stuff. If you really need the buffer underrun info, stick to plextools and plextor drives.

Because it's already possible via Verify mode. Doing it your way adds complexity where it's simply not required and I have no interest at all in implementing it.

Drives aren't always 100% accurate with their pregap timings and I figured there's very little reason to have something like 72 frames or 77 frames for a pregap, hence it snaps to the nearest multiple of 75 (nearest second) if it's within the configured pregap snapping range.

So if that works then the installer has no reason to complain. Personally I'd slow the burn down a bit though, 20x is too fast if you want high quality burns. Personally I'd go for 12x or at the very most 16x - which is the manufacturers recommended speed for TYG03 anyway!

That'll be pregap snapping then. Look in the options. btw, 3 frames is not 0.3 seconds! There are 75 frames per second, which I sure you already know if you think about it.

It'll never happen, sorry.

Yes, it will have read all the sectors on the disc and if it didn't error out then the drive thought they were fine at the time. This a drive issue if it didn't pick them up the first time around, ImgBurn can only go by what it reports. Post the log of your burn/verify and maybe we'll be able to spot something that could cause the problem - i.e. outdated firmware/old drive/cheapo media.

Verify confirms that at that moment in time, in that specific drive, all the sectors were readable and matched what's in the original image. If you think there's a problem, verify it again and double check.

Erm I seem to recall having to fix something in that area yes. One of the commands returns info in a different format to the others and I hadn't noticed that in the initial 2.4.0.0 release. How 'different' are your gaps exactly? Are they different *wrong* or just different?

If the source is OTP, ImgBurn will always be able to use the LB position from the MDS - as it will always be valid. The only time it can't is if L1 > L0 (which only happens on *some* PTP media) and then it has to fall back to scanning the IFOs / Cells etc trying to find one that is acceptable. When it can't, it then throws up that error box. At this point you have 2 choices (or maybe just 1, I can't remember!): 1. Ignore getting a nice LB and just divide the image in 2. 2. Rebuild the image via a virtual drive and Build mode.

I wish the drive people would implement a proper way to disable the auto write/verify without me having to resort to using the 'streaming' command. There seems to be a flag I can set that does exactly that on BD-R but it doesn't apply to BD-RE... what I don't get is that BD-R burns at the correct speed anyway! I guess the only timesaver is that you can disable the program's Verify feature if FastWrite is not enabled - there's no point in verifying twice!