LIGHTNING UK!

Post the actual log please. The exact error message is important here as it appears the problem lies with your main storage device / system drive (i.e. C:\) Until the issue is resolved, have the program create an image file (from files/folder) rather than trying to burn on-the-fly (direct to disc). Once you've built an ISO (ideally, on another drive if C: is having issues), burn that to disc.

As that video doesn't seem to include the verification stage at all, have you tried using the disc you burnt and ignoring the fact the program reported loads of miscompares?

As UHD is just data, yes, they're compatible in the sense you can store that data on anything it'll fit onto. The problem would come when you attempt to playback that content from a DVD. If a player detects a DVD, it may only attempt to look for a DVD Video folder (VIDEO_TS). If it goes beyond that and looks for BD Video (HD and UHD) structure too, you should be fine. The best thing to do would be burn one and try it in the player you intend on using to see how it behaves.

Your log doesn't show anything useful. Do not enable debug mode unless one of us asks you to do so please. It makes things harder unless we specifically need that extra info. In what way is it not working... what actually happens? If your drive is erroring out, try and post a log showing that info please.

From an optical drive point of view, you don't finalise DVD+RW media. You format them (when brand new) and they then look like the full capacity of the disc has been used up. That's what this section of text is all about: What you probably want to do there is try cloning the disc... but not at sector level where ImgBurn works... you'd want to do it based on the content as recorded in the IFO/VOB/BUP files. So you could try using something like DVD Shrink, CloneDVD or DVD Fab to actually analyse the content of the disc and build a new ISO you can burn to a DVD+R (which can then be closed/finalised by the drive).

It isn't a feature of the board software that I use, so I don't know if it's working normally or not. I haven't updated the forum software in a few weeks, so if it's only just started happening in the last day or so, it's probably not that. We got visited by a nice spamming bot the other day that private messaged every user on the board with an explicit link. I obviously put a stop to it as soon as I saw what was happening, and in doing so, all of those PMs got removed from the system. That might have caused some confusion with unread messages though. I'd probably just mark the entire forum as Read, optionally clear cookies and see if it starts working normally again.

Did the last paragraph of my reply not cover it? I don’t know which speeds are available for your drive/media/firmware combo and I don’t know which one will produce the best quality burn. That’s something you’d have to find out for yourself by trial and error.

If your drive reports a read error at any point during the verification phase, I'd consider that disc to be a little suspect, even if it eventually managed to read the problem sectors after x retries. Different drives are more/less capable at reading problem sectors than others, so it may totally fail in another drive or it may not show an error at all. Verification is good for that drive at that moment in time. I guess it wouldn't hurt to retry the burn at 4x, the drive might do a better job of burning it. Please note that it's not ImgBurn claiming it can be burnt at 8x, it's the firmware in your drive. ImgBurn can't do anything your drive isn't programmed for - that's the purpose of the drive's firmware... to control all of the burn parameters for every different media.

As this is the ImgBurn Support Forum, please start by posting the disc info displayed by ImgBurn - which happens to be exactly what was asked for in the 2nd post (1st reply) in the thread you linked to.

Ok, I've found the problem and can see why it would sometimes work / not work. It turns out that the fields aren't populated during the initial analysis phase and are actually populated (refreshed from the file) when you select the track or go to save the actual CUE file. No such population / refresh occurs when just displaying the track listing.

Don't worry, the order in which they come through isn't important. Can you please double check then when you get an incorrect track listing file, clicking on the individual files in the list does indeed display the correct CD-TEXT info in the title/performer boxes. It makes absolutely no sense that the info would display correctly in one place and not the other. They're both reading from the same variables. If it turns out that it's wrong in both places (but only sometimes), it would mean it's occasionally running into some sort of issue with parsing the file - maybe it's being locked out by some other software on your machine (AV or whatever). Also, does it matter if you drag+drop the files Vs adding them via the 'browse' box? I'm assuming no errors are being reported in the Log window as it tries to analyse the files (and extract Tag info) ?

So where it says 'Default CD-TEXT (Disc / Track)' down the bottom right of the 'Create CUE' window, you have 'Tag' selected in both drop down boxes? The only time the track listing would use the file name is if the track's configured CD-TEXT Title and Performer are both empty. btw... yes, you should/can get an email if a reply is posted in a 'followed' thread - subject to your notification settings, which you can configure here: https://forum.imgburn.com/index.php?/notifications/options/&type=new_comment

When you add one of the problem files to the 'create cue' window and enable the 'Tag' option for CD-TEXT, does it fill out the 2 fields below with the correct info you expect to see? By design, the individual track performer info is removed if it matches the performer of the disc. That's why your 9 and 10 didn't have it. If I add someone's album and all the info is filled out everywhere, I want the album name and performer at the top and then all I need are the song names, not the performer and song names. That's duplicating info for no reason.

The log is more useful. The screenshot suggests the os has lost its connection to the drive. Bad cable/ USB port perhaps?

and… closed.

Your hdd will report an error if it cannot write the data for some reason. It'll also report an error if it tries to read the data and detects that the data doesn't match with the ECC. HDDs also have spare blocks they can use in place of any sector that's found to be bad. The remapping of bad sectors is done automatically and you, the user, wouldn't know it's happening. S.M.A.R.T info can report on such remappings/reallocations. So to sum up this topic (before it gets closed)... Corrupt files stay corrupt. Test for corrupt files by checking the MD5 or SHA-1 against a known 'good' value (or by using the 'Test' feature of a compression tool if dealing with zip/rar archives etc. If a storage device develops a bad sector and you attempt to read data from it, you'll be told about the problem. If a storage device develops a bad sector and you attempt to write data to it, the device might try to remap the bad sector to a known good one, or it will error out and you'll be told about the problem.

That's good then. Just FYI, such issues would be reported as a 'Miscompare', not an 'I/O Error'.

You're basically repeating yourself again (or asking questions I've already answered) and I've warned you about repeatedly doing that in the past. Please stop or I'll ban this account too. If the file was corrupt before you burnt it to disc, it'll still be corrupt on the disc and ImgBurn won't tell you about it (unless it's even more corrupt on the disc - then the statement below applies). If the file on the disc is different to the one on your hdd, ImgBurn will tell you so as part of the verification process.

I've already said what an I/O Error is (where ImgBurn is concerned). On a more generalised note, I/O stands for Input / Output. It's the sending and receiving of commands / data to and from a device. A drive isn't going to know if a file is corrupt (before/as it was written to it) - that's where CRC / MD5 / SHA-1 checks etc come in. In the case of a zip / rar file etc, the compression utils usually have a 'Test' feature built in that can be used to verify the contents of the compressed files. If you download a file and want to check it's ok, check its MD5 / SHA-1 using a tool suitable for the job - something like HashTab perhaps. Once it has checked out 'ok', you're fine to burn it to disc and ImgBurn's burn+verify will let you know if what ends up on the disc doesn't match with what's on your hdd.

I answered that earlier.

Yes, if it burns and verifies ok, the disc is good.

An I/O Error can be anything where a device (optical) reports an error processing a command. If there’s a problem reading or writing a file on your storage device (hdd), the Window API function will also return an error and ImgBurn will display the details.

No, general corruption of the file is not a hardware problem.

Yes

ImgBurn just burns what you give it. It doesn’t know what subtitle files are. Whatever you feed it must already be in the format your playback device supports.