LIGHTNING UK!

I guess because that's just what it defaults to? You can't make something from nothing though and 2048 bytes images only contain 'user data'. Nothing that writing in RAW mode would do anything for. Should you be so inclined, you can look up the structure of a CD sector and see the difference between 2448, 2352 and 2048 byte sectors. 2448 being the same as 2352, but with the added 96 bytes of subchannel.

I suggest you take a 2nd look at the name of the application you're using. What part of 'InfraRecorder' looks like 'ImgBurn' ? Getting back to the application this support forum is actually for... ImgBurn... that doesn't offer RAW at all. Your other thread is beginning to make a little more sense now. It seems you have your apps confused. btw, as an ISO is meant to just be 2048 bytes per sector, you're wasting your time even looking at RAW writing. You don't have any data in the image that would benefit from being written that way.

ImgBurn outputs iso or bin/cue. I do not understand where you’re getting this toc and subchannel from?!

Your disc is copy protected.

As verify re-reads the image and compares it at bit level against what's read from the disc, it can actually be better at finding problems. For example, if there's an issue with data corruption when reading from the source drive (but no 'hard' error) or a memory issue (faulty ram), verify would give you a 'miscompare' error. Hardware Defect Management won't notice that kind of thing. As you say, it's pointless formatting with spare areas and then turning on fast write. Just format without spare areas. Only if I really wanted to make sure everything was ok would I use hardware defect management AND verify. I don't think I'd rely on hardware defect management alone (as in, verify being disabled), but I'd certainly rely on verify alone (as in, without HDM being active during the writing phase). Yes, spare areas are transparent to software. The drive handles remapped blocks itself internally.

Can you post the log please? If it burnt and verified ok, the disc is ok so far as your burner is concerned. The issue then falls with the image itself or your playback device (being unable to read the disc or something).

It's normal for it to perform a 'one time only' full format and zero fill of a new BD-RE. ImgBurn defaults to liking discs fully / properly formatted and there are structures on the disc that (in a non-user data area) that tell the program if it is or not. Once it's been formatted properly, the program just makes use of the Direct Overwrite capability of BD-RE media. It's not normal for it to get stuck like that during the zeroing phase. Assuming you terminated the program somehow, did you happen to save the contents of the log window before doing so? The log only saves when the program is closed down cleanly.

The problem here is that you're asking for 'help' on something that's actually quite complex... and perhaps you don't fully appreciate that? I don't have any code samples, I did exactly what I suggested you do.... located the specs of the file systems, learnt about the different descriptors and then wrote the code to create those descriptors. If you don't understand everything in the file descriptors and how they build up the file system as a whole, you don't stand a chance in writing a program to do what you're trying to do. ISO9660 is the easy one. Joliet is a slight change in order to support multibyte character sets. UDF is a different ball game, and then there are different version of that, so it's multiple different ball games. Actually, maybe I've assumed wrongly here? When you said you wanted to create an ISO, I assumed you wanted to 'build' one. That would involve you learning about file systems. If you just want to read a pre-existing disc in a drive and save it as an ISO, that's something entirely different. To save you wasting your time on whichever forum you go to next, spell out exactly what you're after. Arrogant people such as myself, don't like to have our time wasted by people who want something for nothing and then get all snotty when they don't get the exact answer they wanted.

The program doesn’t really set the speed, you do. If you leave it on the default setting, it’ll burn at MAX. Regions do not come into it. What you’re seeing there is the players (not) being able to read the disc properly.

Do you want me to write it for you?! There’s plenty of stuff out there if you Google for it. This is not a coding forum. Start with iso9660. Learn which descriptors are required and where they need to be located within the overall iso. Fill them out and build your image.

It all depends on which file systems you want to use in the ISO. Look up the specs for ISO9660, Joliet, UDF etc and build your program accordingly.

Your drive is misreporting info about that disc and it's causing something weird to happen.

If you only have things in 1 big wav or bin file, no, you can’t just remove things from the queue.

This won't be a bug. It'll be your drive not liking the disc you've put in it and not being 'ready' to burn. When it happens again, make note of what's written in the status bar at the bottom of the main window.

@Ch3vr0n Whilst that is one sort of 'lock' (tray lock), the one the OP is referring to is there to stop other programs from being able to access the drive and potentially mess up the burn. It either blocks apps from opening a 'handle' to the device or it blocks all operations on said 'handle'. @Robert333 As it locks for exclusive access before any burning starts, you're quite safe to pull the plug if it gets stuck for ages trying to lock it. I'd actually be interested to see what happens when you do that. Will the OS immediately return an error in response to the locking request (which is then displayed by ImgBurn) ? Who knows!

ImgBurn pre-dates Windows 10 and so doesn't know how to detect it. It's purely cosmetic.

The locking of the drive is a Windows API function, so if it's taking a while, it's because Windows is (still) trying to lock the drive. As for why it's taking a while, maybe some other program/service has an active connection to it? Try unplugging it and plugging it in again. They are probably tools you could use to check for open 'handles' to the drive - something like Process Explorer from Microsoft/sysinternals.

Some liteon drives remember how many discs they’ve burnt. Just dvd and bd though, not down to mid/did level.

If it doesn’t just work (auto reject after a while or whatever), it probably wasn’t something I’d considered during implementation. Perhaps I’ll revisit the code and improve things in this area.

I think it actually just copies the iso as-is to a folder on the usb somewhere. Meaning you can just keep adding boot options (bootable iso) until all the space has been filled up.

To be honest, I’ve only seen it recently and used it once! I used it to stick the acronis rescue disc iso image on usb. I think it allows you to put a menu in front of a bunch of bootable iso files and pick which one you want to load.

Try the YUMI route... on a usb stick. https://www.pendrivelinux.com/yumi-multiboot-usb-creator/ If you must stick with an optical disc, are your programs just DOS EXE files? Boot a DOS image via floppy emulation, make sure it loads optical drive drivers / extensions and then access the rest of the disc that way.

No, there is no option to control it.

I can't see anything that would make it do that, no. Best you could do is make a batch file that you drag + drop the folder on to, which then calls ImgBurn with the appropriate command line instructions.

Copy + Paste the contents of the ImgBurn log window once you've got that verbatim external drive connected.