LIGHTNING UK!

lol especially when you're the same person that created that other thread! You do realise we weren't born yesterday yeah? 10/10 for effort though

Well just make sure you have the full thing there in the first place! Nobody ever said you could take the main files of anything and play them as if it were a complete dvd - you can't!

Hmm you've actually brought another problem to my attention now with this thread. If DVD+R discs pad out to a full ECC block, that then mean 'my' last sector on the disc (so far as 'build' mode is concerned) is no longer the actual last sector - it's potentially 15 sectors before it. That basically means my UDF backup Anchor point is wrong because it's supposed to be in the last sector on the disc. The backup one is only used if the first (sector 256) is unreadble so it's not exactly a major issue, but I still had to fix it So now I pad the images I make after all the filesystem data and before the UDF backup anchor point, ensuring the last sector of the image lands on the last sector of an ECC block. This will also have the effect of the image + device MD5 hashes being equal even when burnt to DVD+R - because I'm doing the padding rather than the drive. I'll still leave the 'Device (Padded) MD5: xxxxxxx' value in the log though for times when you're burning images that don't align to ECC blocks properly and so the drive DOES have to do its own padding.

Geez... still can't find it?! Were you even looking for it?! lol

Sorry davidw89, you're not going to change my mind! The answer remains at 'No'. The 'smart' thing would be for LG to make the bitsetting stuff persistent between reboots/power cycles in the same was all the other manufacturers do.

Well I (we) can't comment on your stuff with DVD Dec. If the source files are ok (or source image), the burnt disc should be fine too.

Didn't you just say you'd done the original again with DVD Shrink and burnt it with ImgBurn.... and that plays ok? If so, I'm not sure I understand what the problem is now exactly.

The MD5 is calculated by passing the data (every sector / byte) read from the disc (or image file) to some API microsoft provides. Once you've given that API all the data, you run another API command to calculate the MD5 (or any other type of value you want) from it. As I don't read the extra padding sectors from the DVD+R, there's no way to append that to a second MD5 calculation. I'm also not sure if I can get the MD5 and then add more data before calculating it a second time. EDIT: Ok, I can't add data after I've calculated the value. What I can do though is duplicate the hash before I calculate it, then add data to the duplicate before calculating that one. I will add a 'padded' MD5 value to the log for DVD+R discs.

I'm sure the update shouldn't / wouldn't have caused this error. Could you get a full log of you burning + verifying a disc please so I can see what's going on. Thanks As a side note, have you also just recently got new discs or moved onto a different pack/spindle of them? They might be different to your last log - even if they are stamped with the same 'brand' name. This is the most common cause of things working and then suddenly not working.

By the sounds of it, you're comparing different sized images - so of course the MD5 will differ. When you compare a disc to an image, you compare the disc to the image, you don't compare the image to the disc - if that makes sense! So if the image is smaller than the disc, it still only compares the number of sectors in the image - meaning the extra stuff on the disc is never looked at (and hence not included in the MD5 calculation). The problem you're facing the DVD+R padding up to the 16 sectors marker is 100 times worse if you burn to DVD+RW. That I know of, there's no way to get the size of burnt data on a DVD+RW disc. It will always return the FULL size of the media and that never changes - even when you've burn 10 sectors and the rest is just empty (formatted) space. So whilst it might seem logical to read ALL the sectors on a disc, even when comparing to a smaller image, it doesn't work in practice.

calweycn, You have to remember that although other modes have speed settings, those are totally controlled by the drive, not by the program. The program always works at 'full steam ahead'. To slow it down for Build mode I'd have to perform some sort of throttling via wait (sleep) commands as and when I/O transfer rates went above a certain level. It's too much faffing around for very little gain. If there's something you urgently need to do and a 'build' is slowing you down, just pause it. If you must build an image rather than going direct to disc, build it to a different physical hdd and your machine will find the task much easier. If you don't have one of those, maybe it's time to invest in one - especially if you're going to be doing this kind of thing frequently. While you're at it, stick some more RAM in your PC too. Sorry but the answer is still no.

db, are you STILL going on about this?!?! lol Your board (assuming it's still the same one I have) only has 1 USB controller on it and that's the one in the ICH5R chip. That chip supports USB 2.0 and so all your USB ports are capable of that speed. http://support.intel.com/design/motherbd/bz/index.htm The Intel 875P chipset pages also state that it supports 8 v2.0 ports. I don't recall ever seeing a chipset where it supports X ports at 2.0 speed and Y ports at 1.1 speed. That would be pretty 'cheap' of them! Either it's USB 2.0 or it's not - and in your case it is! Here's another handy little tool for examining USB controllers/ports http://www.microsoft.com/whdc/device/strea...ap/UVCview.mspx

Because I don't want to have to keep updating it for every drive that gets released. All the major players (except LG!) remember the bitsetting settings anyway. So really it's an LG problem

If you had a layerbreak in the first place it should be easy (ish) to spot in the dialog box that ImgBurn presents to you. For the DVD you've presented here, it seems the LB has been removed at some stage. If it's feasible to keep using the original one, do so. As I said before, IFO/BUP 32k padding is a 'nice' thing, you do not 'need' it. Your discs will play perfectly fine. However, if you have the intention of scratching the hell out of them, it's best you wait for a fixed version of ImgBurn that won't have problems when 32k padding is enabled.

It could just be a simple 'bitsetting' problem. Is your drive performing bitsetting on the DVD+R DL media to make it look like DVDROM? You can check it (or let us do it) but putting a burnt disc in the drive and copying + pasting all the text from the info panel on the right. What speed are you burning the DVD+R DL at?

Normally, I believe higher burn speed = higher jitter. Of course if the drive in question has a better write strategy for burning at 16x than it does at 4x, it would make sense that the 16x one is producing better burns. I would think a lot of drives are geared towards burning at full speed (if not faster!) on media now. So the faster write strategies probably see more testing etc that the much slower ones do. Unless there is a fundamental flaw in the drives hardware, a firmware update can fix most things.

Are you actually clicking (right clicking actually!) the option to apply settings to all selected files? If not, you're only changing that option for 1 image - the one whos details are displayed in the lower part of the Queue window.

I have no need for the emulation options myself so they're all turned off (as is default anyway). I would like to think that even when the options are enabled, they only effect the DT drives an not the entire I/O subsystem!

DT is fine, I have to use it quite a lot for tests etc, never had a problem with it.

Sorry, this really is out of our control. You'll just have to keep messing around with drives / cables / drivers until the problem goes away. If you have anything else on the same cable as the burner, try disconnecting it. Make sure the drive is configured as a Master / Slave device. Do not use the 'Cable Select' jumper setting. You could also take a look at your filter drivers using the free tool available from www.bustrace.com Maybe it'll show you (us) a driver that could be messing things up.

I don't recall changing anything for CDRW. It's not a format of media I do *anything* with these days! Here I am trying to reproduce whatever the problem is you're having.... Put disc in drive... This is what the program says in the box on the right: The status bar reads: I then select an image to burn and hit the 'Write' button. Now this pops up: I click 'Yes'. It then begins to erase the disc. Hmmm... no problem there! Do you actually have a full log handy of you doing what I've just done?

It will be in the next one. At to whether it should be switched on or not.... well that depends on the files you're building an image from! There could be occassions where you need: 1. The DVD Video content before the DVD-ROM stuff. 2. The DVD Video content mixed in with the DVD-ROM stuff. 3. The DVD Video content after the DVD-ROM stuff. Each disc could be different so it's really down to the user to decide what works best for the image they're trying to build. All 3 options are now possible within ImgBurn v2.1 (not out yet!). I default to the 'Mixed' one.

ImgBurn is a burning tool, not an authoring tool. What you're asking for is way out of the scope of the program.

Hmm, I don't like optodisc myself. To be honest there aren't really any great dyes for any sort of rewritable discs. The Ricoh 4x DVD+RW ones are ok but the 8x ones are very unreliable in current drives (with current firmware). I don't bother with DVD-RW because I can live without having to erase them each time I do a test burn (I have to do a LOT of tests!). With DVD+RW I can just overwrite the existing data.

They might put those files after the DVD Video content. I've just added an option to ImgBurn so you can do that too. Normally the folders are just added in alphabetical order etc. Enabling the new 'Force Video Content First' option will move the AUDIO_TS / JACKET_P / VIDEO_TS folders + their content to the front of the disc.