LIGHTNING UK!

Open the program properly and copy + paste everything from the log window please.

No, it's all automated once you've configured it.

You can't use Build mode with the autoloader as a source in an automated fashion. Use Read mode if you want to make ISO files of numerous discs that are in the autoloader.

Please post the log

It's not normal for programs that attempt to create an accurate cue, no. ImgBurn does, AnyBurn doesn't appear to. I don't think burning each of those would result in identical looking discs (and that's just taking the basic TOC into consideration), so I wouldn't say they're the same.

What you want is a white bag inside a black bag. Wrap the whole thing in tissue paper and package it in a cardboard box that you then completely seal with sellotape. Then wrap the box in tin foil.

Have you only tried burning at 2.4x? As it would appear your drive can't produce a decent burn on 'MCC-004-00' at that speed, it might be worth trying the remaining supported speeds. Start with 8x.

Copy and paste everything from the log window please.

Yes, post the log. Make sure the verify option is enabled so the program can do that after the burn.

That's not a domain I'm familiar with. Which mirror did you download from?

I haven't scanned with anything else for a long time, so I wouldn't know how accurate the results were or how they compare to what a LiteOn would report. So if you don't have a LiteOn to do it with, don't worry about it - especially if they won't even get through a complete scan without getting stuck

You do need the right hardware for scanning really. A LiteOn drive is what I use as they're still readily available and I have a fair few of them.

That's covered by the PRE flag in the CUE file and the drive gets told about it in the 'send cue sheet' command.

The program usually asks the drive to return 32 sectors worth of data at a time - it's quicker. If that request fails, it asks for 1 sector at a time from the same range to try and read as much as possible and find the actual bad sector. It's possible (as is the case here) that the drive manages to read the 'problem' sector(s) when asked to read them again. So think of it as a built in 'retry' mechanism - but it's not a real 'retry' and doesn't get logged as such. I'd still be a little curious as to how well that disc actually burnt though and how readable it is. PIPO scan it if you're so inclined.

ImgBurn sets its own timeout as part of the I/O request, but it's being ignored by the driver I expect - if that timeout in EV was directly related to a command sent by ImgBurn. I can't explain why the thing that's happening is happening, I just know it is it takes a lot more messing around and I/O snooping with various discs to work out what's going wrong.

https://en.wikipedia.org/wiki/Compact_Disc_subcode Sometimes they'd make use of the subchannel area as part of copy protection. I expect Quake predates that though. ImgBurn reads and writes ISRC, MCN and CD-TEXT, so you aren't really missing anything - unless it's something 'unusual' that's stored in the R-W channels. With the exception of CD+G Karaoke discs, that's not going to be anything you'd ever see or use.

Yes, they check you have the required hardware before installing. If you don't have any hardware matching the device identifiers in the INF file, it won't install. The processor isn't an issue here. It means what it says A device didn't respond to a command within the timeout period. I don't know what that timeout period is though or what command it failed to respond to.

If your drive can't read the disc, it could be due to the media you're using. Can you post the log please so we can take a look? You can find it via the Help menu.

It does appear to be having trouble reading the 2nd layer... right from the very first sector on it. The layer break cannot be moved on BD media and you're meant to treat multiple layer BDs as giant single layer ones - i.e. No special treatment.

That's what 'Build + Burn an Image using ImgBurn' does. I'm not really sure why it was ever written / phrased like that, it should match the wording of the Ez-Mode picker screen more closely really.... which would then make it say pretty much what you mentioned.

Depending on how much is now bundled under that 'structural protection' umbrella, I'm still not convinced. If everything that needs unscrambling gets unscrambled and everything is in the same place (file system wise and therefore LBA wise on the backup), I don't see why it wouldn't behave like the original disc. The only thing I can think of right now that would stop it from working is if the unreadable sectors *had* to be there - as although they could be emulated via software, they wouldn't be present on the backup itself. Obviously I know you're very active at the RedFox forums (the world thanks you for that), but until you actually develop software for this field, there's a good chance you're just repeating what others have said and what you've 'discovered' / 'interpreted'. That may not be the whole story. Now if you can tell me of an actual case where a playable disc has been correctly unscrambled, bad sectors ignored (and aren't required) and a ~1:1 backup wasn't playable, I'm all ears. That's isn't quite the challenge it sounds, I'm genuinely curious.

People have lost interest now. Please move on.

Now I could be wrong as I don't deal with structural protection these days, but it's not going to cause you any trouble if you're reading the disc to an image file and only ever intend on using it as an image - mounting it or burning it. Obviously those extra 'dummy/duplicate' VTS sets don't cause an issue on the original disc, so why should they cause an issue on your backup? If you hadn't tried to look at the files on the disc, you'd never have known any different and a proper 'licensed' player will handle it all just fine. I guess there's always the possibly that leaving it in tact is better than partial or incorrect removal.

Yes, it looks to be as I said. I'd need to mess around with an odd bin/cue file like that to implement support for it. Is it available anywhere?

I'm pretty sure I've never seen a bin file where there's a mix of 2048 and 2352 byte sectors in the same file. How did that even happen?! That's probably messing things up and the file is running out of data (assuming the program is using 2352 bytes for everything), which in turn makes the last few tracks have weird sizes (or no/negative size). Most drives will reject tracks less than 4 seconds in length. Can you please go into 'Write' mode, load the CUE and then click the 'View Image Information' button in the 'Source' box. Take screenshots of that please (it scrolls and I'll need to see it all) and attach them in a reply. Thank you.