LIGHTNING UK!

Cool. I’ll keep an eye out for it. [emoji1303]

As you pointed it at a hdd (your c: drive), it would have saved a copy of your entire hdd - so you’re probably lucky it didn’t work. As for why it failed, no idea. Maybe Microsoft have replaced that ioctl with something else now.

Yeah, you're doing it wrong. There are guides for building OS install discs. If you aren't doing anything non standard with your current USB, why not just download a fresh/up-to-date image from Microsoft and use that?

Make a dummy file and add it to your compilation.

That would probably be a chipset / firmware thing. If the drive seems to be reading slowly, it could be because of it having difficulty reading, so it’s automatically slowed itself down. They can also slow themselves down if they determine it’s a video disc of some sort - so the drive is quiet and it doesn’t interfere with you watching a movie or whatever.

Technically, yes

2.5.8.0 knew how to detect usb 3.0 (as it was at time of release), but Microsoft then changed their minds on how they wanted to do things and now there’s another way to detect it. That’s what 2.5.8.0 can’t utilise. It’s purely cosmetic though and your drive / enclosure will work at whatever speed they’ve negotiated at with the chipset.

Different disc formats use different descriptors for the info.

They're the same thing (in my eyes). One disc format may favour naming the fields in the descriptor for that format as disc id and another may prefer manufacturer id.

Verify mode would normally do a byte comparison of the sectors on the disc Vs the sectors in the file. That's just turned off by default for CD-DA sectors. So for CD-DA sectors, it's basically just a test to see if the drive can read the sector on the disc - which is in itself not guaranteed to be accurate and that's why you can re-read the same disc in one of your drives and get a different image each time, but without the drive ever actually telling you there's any sort of problem. Again, that's due to the lack of error correction available in CD-DA sectors. The 'Ignore CD-DA Data' option is exactly the option you'd be turning off if you want the program to perform byte level comparison of CD-DA sectors. I won't pretend to know why the whole read/write offset thing exists for CD-DA sectors, it just does. Different chipsets within drives use different offsets. The offsets are in bytes... normally something around 10 - 20. So that's 10 - 20 bytes within a single sector... which is only 1/75th of a seconds itself, so a few bytes is nothing. The offset basically shifts everything (the entire track) a bit. All the data is still there (I think), it's just a few bytes earlier/later. For audio, that doesn't really matter. Obviously it's a complete deal breaker for data tracks and they do not suffer from this 'offset' stuff. Like I said.... minefield. No, ImgBurn doesn't have any special handling of offsets. If it tells the drive to write some data to a sector, it expects to be able to ask it to read that same sector back and get exactly what it wrote. I vaguely recall favouring my LiteOn drives for CD-DA stuff because they were one drive where I could use them to read an audio cd, burnt it in the same drive and then read it back again to a new image and it would match perfectly. The offsets a drive uses doesn't change, so if your pioneer constantly gives you a different image when reading anything with CD-DA tracks, that's just down to it being a bad reader. If you aren't already doing so, maybe limit the speed when reading audio tracks - it could help. I think the default used to be 8x.

Sorry, when I suggested to use Verify mode and compare the image made by one drive to the disc in another drive, I'd totally forgotten about the program defaulting to not verifiying CD-DA at byte level. That's why verify passed - it was essentially just testing the optical drive could read all sectors on the disc. CD-DA causes a real headache when it comes to verifying because drives have a read and write offset for it. The data I tell the drive to write to a sector won't always be what it returns when I read it back (unless the drive's write/read offsets cancel each other out) If you want to explore that minefield, take a look here - https://www.exactaudiocopy.de/en/index.php/support/faq/offset-questions/

Audio sectors don't have the same error correction capabilities that data sectors do - because it's using all 2352 bytes for CD-DA. Therefore, it doesn't really know that it hasn't read it correctly. Your findings, where the LG performs the best, matches with what I remember from many years ago. For problem discs, I always had (still have, actually) a collection of LG drives to fall back on. It might be interesting to verify the disc in the pioneer against the LG image to see which sectors are different. The MD5 or whatever being different doesn't really tell you much. As 1 sector is 1/75th of a second's worth of audio, you're very unlikely to notice if just a few bytes or sectors have changed.

You shouldn't be having problems if you're using good discs. If the drive can't burn at 8x on MCC / MKM dye media, you should probably replace the drive. What you're asking for would indeed require modified firmware. I don't suppose anyone modifies firmware these days, but you could ask over at the MyCE forums. https://club.myce.com/ If you can't find any mention of your drive anywhere, you'd probably need to provide the firmware binary by reading from your drive (with the correct tools).

It doesn't need to be in multiple bin files... and that isn't how ImgBurn would have ripped it, you'd have still ended up with a single BIN / CUE file combo. Your disc is just unreadable, that's all.

The program asks the drive to return data for a range of sectors. If it returns an error, it then asks for 1 at a time. That then narrows down the problem sector. You can have it ignore the bad ones by clicking continue or whatever, where it’ll then move on to the next one and the bad one is zero filled. Once you have your image with as much of the data as you can get,, you can start looking at more aggressive disc cleaning techniques. I think it was Skip Dr. that made a disc resurfacing tool. Such tools were popular with the rental companies.

I was thinking more along the lines of a friend or family member that might have a computer. I wouldn't go spending money on it, as chances are, it still won't work. It's probably easier to just find an existing image online somewhere and use that.

I looked, but it wasn't really long enough. What I could see is that it was going ok until it tried to get the subchannel info for sector 107657, at which point your drive must have been struggling to read the disc and started returning info for totally different sectors. It was also taking 5 or so seconds to return said info. There was probably something else going on behind the scenes, but can't see that without an additional I/O Debug mode log. Not to worry now though... you know the disc is essentially unreadable. It might be worth trying it in another drive if you have access to one. Some are better readers than others.

Try some other discs, your drive doesn’t appear to like those.

This will be because your drive is returning some invalid subchannel data and it's causing a loop. If you take a look at post 5 onwards in this thread, you'll see the logs that can be helpful in me trying to diagnose your specific issue.

Oops, my bad! That pinned thread was on the old forum (from the DVD Decrypter days). I'm afraid it isn't available here.

Do you still see it changing size / going into that back box in the top left corner? Disable the screensaver.

I will just point out that the suggestions you tried prior to posting are all nonsense. Don’t believe the Internet. Reset to default settings and continue with dbminters advise. There’s a pinned thread for semaphore timeout issues.

That's where my initial link would come in handy. From what I could make out, it's just a reg key that holds the config of your monitor(s). You clear it out, get your physical monitor back in there, turn it off and leave it so the emulated one gets created, turn it back on and then copy over the physical one's settings to the emulated one. That way, when the emulated one kicks in, it's running at the same res and nothing gets moved around.

I have a question for you... as your email address seems to link back to the Foxburner SDK, can I ask why you are on here asking me questions about ImgBurn? Fair enough if you're actually using ImgBurn, but if you're trying to enhance your own product, you could at least be upfront about it.

Yes, this would be a feature request. Normally, you'd want to keep as close to the original name as possible - as permitted by the file system. Truncating the name when there's no real reason to just hadn't occurred to me - nor has it come up as a request from anyone else... until now