LIGHTNING UK!

Add your files and click the calculate button. The Information page tells you the size of the resulting ISO file and what media you'll need to burn it onto (at a minimum - i.e. you can still burn a 600mb iso onto a dvd) If you're burning direct to disc it won't let you burn if it's too big for the currently inserted media.

You've got discs your drive doesn't support. Update the drives firmware or buy some different ones.

There's no reason I can think of as to why you WOULD NOT do bitsetting. So if the drive supports it for SL media, do it. Personally, I see no point in doing it on DVD+RW, but then I guess it depends on how you use those sorts of discs. DVD+R and DVD+R DL, fine, bitset away - and it doesn't matter *what* you're burning.

Did you do what I said within ImgBurn's settings? Click Tools -> Settings. Select the 'Write' tab. Change 'Write Type' to 'Incremental'. Then try burning again. It might work, it might not - it's worth a shot though.

Being DVD-R, Nero will probably burn it using the 'Incremental' write mode so it can pretend to perform a short leadout. Some drives do seem to work better using that mode than when using DAO - even though DAO is more the standard one. Buggy firmware I guess. So you could even try that option in ImgBurn. In the 'Write' tab within settings. 'Write Mode' has a drop down box. Good to see your drive is once again misreporting the supported speeds on the media. Had enough yet?!

The media types tab is nothing to do with the images / media supported by the program. It's purely there so that when you build a DVD DL image (and aren't burning direct to disc) it knows how to deal with the layerbreak.

It really doesn't matter if you've been using those discs all along - what matters is what's happening now (and I'm prefectly capable of looking at screenshots! ) Discs change, drives ware out. For all you know, you could have been right on the edge of creating coasters with all the ones you've burnt. Now you're over that edge and it's all going wrong. The only constant thing here IS the software - so no, it's not losing its mind. Your drive is the one with the problem here. The sizes, speeds supported etc are all read from the drive. What it reports is what gets displayed - end of story. You asked 'what does that error mean?', erm well it says 'Write Error' down the bottom so I'm gonna go with that! Your drive errored out complaining of a write error - meaning it couldn't write to the media. I'm not sure how else I can put it Where did you get your drive from? Was it just in your PC when you got it? What brand is your PC? The first thing you do in these situations is check you're running the latest firmware. http://forum.rpc1.org/dl_firmware.php?download_id=2279 From that link I can see there's a v1.05 available.

I've never actually seen any philips DL media before. They're certainly not very common and that's probably why you're experiencing problems - the firmware hasn't been tweaked to burn them correctly.

It's normal and by design.

It all depends on which button you click in build mode. One browses for files, the other browses for folders. If you ended up with an ISO as a file on the last cd/dvd you burnt, either you used Build mode or the ISO you burnt (in Write mode) DID actually contain another ISO file!

Setting it to 2.4x wasn't why it worked, it just would have worked anyway. Your drive only supports those discs at 2.4x so it wouldn't have mattered what you'd set it to, it would always burn at 2.4x. Sorry to be a pain but this forum isn't the place to ask questions about why your disc isn't working in your 360. Obviously 360's aren't meant to play backups as standard and we don't talk about anything naughty here!

I've done about 60 Verbatim DL discs in that very same drive without 1 failure. So if your drive fails on those too, RMA it!

Try some discs other than TTG02, your drive still doesn't seem to like them - although at least it's reporting some better 'supported' write speeds now. We recommend Verbatim (MCC dye) or Taiyo Yudens.

This one is pretty simple....don't use anything other than Verbatims for DL burning. Ok, they do cost more but at least they work!

You'd also do well to try and burn at a slower speed. 16x over USB is pushing it and that's probably why you're seeing so many of these buffer issues in your log. Try 8x or 12x.

I cannot modify the phyiscal layout of an ISO file. Once it has been made, it has been made! All the file system pointers expect a file to begin / end at a certain position. For a prebuilt ISO a Cell must already just happen to start on an LBA that's a multiple of 16 for ImgBurn to suggest it as a potential layer break position. So that's what happens in Write mode. When you're in Build mode, I have control over the positioning of files so I can apply padding to the file system to MAKE a cell start on an LBA that's a multiple of 16. That's why it gives you more choices. If DVD Shrink makes an ISO and ImgBurn finds a potential layer break position, from my point of view, you have nothing to worry about. When ImgBurn cannot locate a Cell to use for the physical layer break, it WILL tell the user. This issue is not limited to DVD Shrink, any program that makes a double layer ISO would really need to align a cell properly so it can be used for the layer break position.

The balloon only comes up if the app is in the system tray - but it's only there for 10 seconds and so easily missed. The message box pops up regardless of application state. There's nothing in the code to tell it to shove the message to the front of the z order, that's something windows appears to be doing all by itself. btw, I just built a few test images and the 'operation successfully completed' box didn't pop to the front of the z order for me, my currently active window (which happened to be IE) stayed at the front.

You can't erase write once media (WORM) and all DVD+R DL discs are write once media. So if your drive crapped out on the 2nd layer, the disc is now pretty much useless.

That screenshot shows your drive only supports 2x on that media. You won't burn any faster than that even if the discs themselves ARE rated at 16x. Are your nVidia drivers up-to-date? If not (or you're not sure), uninstall the old ones and reinstall a freshly downloaded set. Oh and LOL, you do realise the 'Time' shown on the main GUI is not how long it's going to take to burn?! It's to do with the size of the image in the old CD (M:S:F) time format. i.e. where 650MB = 74mins 700MB = 80mins.

Correct. If you've somehow managed to split an image into 2 parts - with each part representing what 'should' be a layers worth of data, you CANNOT burn those parts onto different discs. The 2 parts must always be burnt to the same double layer (and I don't mean double sided!) disc. So basically, there's no point in splitting by layer in the first place!

I think you're confusing ImgBurn with a 'Backup' tool. Buiding an ISO from some files doesn't mean those files will keep the exact same name. Each file system has its limitations and those should be realised before ever burning anything. If you decide to build an ISO using only the ISO9660 filesystem, you should know that all the file names will be converted to 8.3 format. That's just how it works and all programs are the same. It's not the job of the verify function to compare filenames against those on the hdd. It compares what was written with what should have been written, data wise, nothing more. The program expects/knows (and the user SHOULD expect/know) they will be different so why show it as a failure? Logging was disabled by default because nobody sticks to 8.3 format for names on their hdd and nobody wants 20,000 log entries when they build a disc as the program converts all the filenames to 8.3 format. As I said before, it's not my fault that whatever you're trying to create an image from breaks Joliet specs for filename lengths. If it was on a disc in the first place, that was naughty of whoever made it. Now you've seen first hand what happens, learn from it. For people that just want to stick some random files on a disc, a slight truncation of names is no big deal - and again, people who've ever burnt discs before with long file names will have probably already seen that they get truncated and know it's going to happen before it actually happens. I've improved the 'non compliant folder/file names' logging option to let you specify which file systems to show the warnings for. So it's now enabled by default, only showing warnings from the Joliet and UDF file systems.

http://forum.imgburn.com/index.php?s=&...ost&p=32093 That disc you mean?! No it didn't burn fine, it failed to finalise it. A PC drive (well, a burner at least) doesn't care if the disc isn't finalised. It should always be a case of, if it can create it, it can read it - and PC burners can create unfinalised discs. The verify checks the actual data is correct, not that the disc has been finalised properly. Cheapo players play everything because they're designed that way. Maximum features, minimum cost - and without too much regard for any 'specs' that players are supposed to follow. Decent players (often with far less features) do things properly and expect things to be 'just right'. A 'just right' disc will always be finalised and that's probably why it won't play yours.

The positioning of the layer break is not the cause of write failures, it's a potential cause of playback problems if you were burning a DVD Video disc. Write errors etc are always due to some glitch between the drive / firmware / media combo. All a software tool can do is 'retry' on error, the rest is out of its control.

On this occassion you were actually quite lucky and a Cell did just happen to land on an LBA that's a multiple of 16 - this is a basic requirement for ImgBurn to make use of it. As such, your layer break was actually ok in the first burn - but this WAS a fluke and that's why DVD Shrink should never be used to build double layer images. DL burning wasn't anywhere near as common as it is now and the author never had the chance to, nor got around to fully implementing support for it.

Implemented as YYYYMMDD_HHMM, case closed You can also now specify [DATETIME], [DATE] and [TIME] in an IBB file for the Volume Label entries and ImgBurn will replace them with the appropriate value. i.e. [DATETIME] = YYYYMMDD_HHMM [DATE] = YYYYMMDD [TIME] = HHMM