LIGHTNING UK!

ImgBurn doesn't have the ability to read to an ISO how DVD Decrypter did. It's a burning program and basically just replaces (with enhancements) the 'Write' mode of DVD Decrypter.

It'll be in the next version I release. 2.2.0.0 or whatever. No date yet so don't ask

Ohh I never read/spotted that! Good call dontasciime! Perhaps it's USB 1.0 and so you'd only get 1mb/s transfer rates.

Are you drag dropping the video_ts files rather than the folder? There is a known issue if you drag + drop the files on their own.

Your benq just failed to burn it with a pretty generic 'Write Error' error. Maybe the BCIB firmware would fix that, or it could just be that you were unlucky that time around.

Having deleted the top level controller entry, did you go back in and check the channels are saying DMA is enabled / being used? If you still never get over 2x when burning, DMA is still to blame - unless of course that's all your drive will do!

I think you've hit the nail on the head there LFC. It certainly looks like a DMA problem to me.

It would appear the drive is having trouble running the command that reads the current booktype setting from the media. As LFC said, the program is waiting for a response and that's why you can't close it etc. ImgBurn is not really in control at this point. As soon as the command completes, be it successfully or with an error, ImgBurn will spring back into life.

Well I know for sure it works on XP x64 and I know it works on Vista x86 so I guess it should work on Vista x64! Most pure software apps should work ok on x64, it's the ones with drivers that you have to watch out for.

No but I'm sure it works fine. And why not use 5728 over 5600 anyway? That's the latest download from MS.

Sorry, I forgot to add it was mainly added for people doing DL builds whereby the location of the folders could actually have an effect on which layerbreak positions were made available to them. A dvd player would just parse the UDF filesystem, look for the VIDEO_TS folder and then for the VIDEO_TS.IFO file. (well, going by the specs anyway!) So it really doesn't matter where it's positioned on the disc, so long as the files within it are properly positioned. (i.e. the ordering - ifo -> vob -> bup, and the lba sector pointers / offsets etc).

You have to buy them from an online supplier that quotes the disc/manufacturer ID on the page where you add them to your basket. Verbatim generally use the MCC dye or TY (Taiyo Yuden). They're about the best you can get.

I'm not sure it matters to be honest. The option is only there for people adding DVDROM content to their DVD Video disc. Otherwise it doesn't make a difference.

te he he Really do appreciate your dedication to the cause though!

Please copy + paste the full log rather than just giving a screenshot.

lol blu you don't need to keep going with this, it's not physically possible with the media being identified as it currently is. As you can see from the screenshot the lowest possible LB address is 1975888. Multiply that by 2 and you get 3951776 Compare that to the available sectors on the media As you can see, it'll never fit!

Yeah see that goes exactly in line with what I just said. If you build to an image file it uses predefined sizes for DVD+R DL media. When you build direct to the drive it uses the size of the media in the drive. So if your drive was picking up the correct (normal!) size of a DVD+R DL disc, it would work fine.

Just a bit of an update... It was clear from your video that the autoinsert thread was being created/run (by another thread) AFTER I'd tried to terminated it at the start of the write process. So, it was running in the background during a 'Write' operation. As the drive goes between 'ready' and 'not ready' states when you're burning, the autoinsert thread thinks you've inserted a disc and so will try to initialise it. That's where the error was coming from and it's why you could have the error box up on the screen and yet the burn still carried on regardless - had the burn have been erroring out, that would not have been the case. I think I've fixed this now.

Ok, it has been implemented.

It can build images from whatever files you have on your hdd. It doesn't matter what the actual contents are. It will never use ~, it does use _ though when making ISO9660 compliant names from long name (it has to take them back to 8.3 format). The OS only shows the file names of the 'best' file system it supports. So if you enable Joliet and / or UDF, assuming your OS supports those file systems, you'll see the proper (long) file names.

Most people would already have it configured for that in the GUI if that's how they like the program to work. I'll add it for the next version though so it can override the normal GUI setting.

Your DL disc is registering as having an odd number of free sectors. That 'free' number is VERY close to the actual size of the image and so there's hardly any room for padding and moving stuff around. A Verbatim disc may register properly and could well be enough to make this all work. The 'Media' tab mentioned above does not appear/apply when burning direct to disc so don't worry about it!

I hadn't noticed it, no. I've look at it now though and I see where the problem is coming from - I'll look into it. The CLI stuff undergoes no/very little testing so weird thing do and can happen.

It means the drive is still busy finishing the previous write. If that's show in the statusbar then it would explain why the read capacity command is failing.

So this is a new pack? It would explain why it worked before and now doesn't. You can't ever go by the 'brand' name of the DVDs, you need to look at the dye type they use. Your current ones don't even register with a proper manufacturer ID - or perhaps your Matshita drive just isn't / can't report it properly.