LIGHTNING UK!

There's nothing to say you have to maximise on the directory name length. You've a directory name length limit, a file name length limit and an overall path limit. All other limits are still in place if you modify the 'Allow more than 255 characters in path' option. That option simply tells ImgBurn not to check for paths that might exceed that limit. Rather than mess around with ISO9660 options, why not just use a modern file system like UDF? Are you absolutely limited to using ISO9660 for something?

https://www.ecma-international.org/wp-content/uploads/ECMA-119_2nd_edition_december_1987.pdf 6.8.2.1 states 255 is the limit.

All drives behave differently. Standalones are typically better at skipping problem areas, but the PS3 is designed for playing games from pressed discs, so it's more like a standard optical drive (PC drive or whatever) in that respect.

Yes but if you turn the monitor off, maybe Windows thinks it has been disconnected and is then using this emulated one, which has the wrong resolution. I don't know, I'm just clutching at straws! haha My log window was where I left it when I turned monitor back on this morning. I'm on an nvidia gpu though, not onboard.

Problem: You get an error in the ImgBurn log window saying remote sessions (RDP) aren't allowed direct access to removable storage devices. Answer: This is the default behaviour of Windows. You can allow direct access to removable storage devices in remote sessions by doing any of the following... 1. Reinstall ImgBurn using the official installer and enable the option saying 'Enable SPTI access in remote sessions". You may need to reboot your computer for the changes to take effect. 2. Load the Local Group Policy Editor (Run 'gpedit.msc') Navigate to - Local Computer Policy -> Computer Configuration -> Administrative Templates -> System -> Removable Storage Access Locate the entry called - "All Removable Storage: Allow direct access in remote sessions" Double click it so you can edit it and then set it to 'Enabled'. 3. Make the adjustments directly in the registry. You'll want to set the value of 'AllowRemoteDASD' to 1 (i.e. Enabled). Registry Hive HKEY_LOCAL_MACHINE Registry Path Software\Policies\Microsoft\Windows\RemovableStorageDevices Value Name AllowRemoteDASD Value Type REG_DWORD Enabled Value 1 Disabled Value 0

Maybe something like this will help? https://answers.microsoft.com/en-us/windows/forum/all/windows-are-resized-and-moved-after-waking-pc-with/35084e25-1b78-4cff-94e9-e9157334bb2f

Sorry, I thought you said some sort of resize is going on and that other windows are being moved too? Is your machine set to go into standby / hibernation mode when left for a while? Do you use a screensaver?

There's probably nothing I can do about it then. When Windows changes screen resolution, it'll probably move windows so they aren't inaccessible.

I currently have ImgBurn open (and not doing anything) with the main window at the top and the log window at the bottom (which is default behaviour). I'll shortly be turning off my monitor and will see where the log window is when I turn it back on in the morning. Does it need to be the active (foreground) app when turning off the monitor? (does that make a difference?) When you turn your monitor on again, do you notice windows doing any sort of resizing / changing of resolution etc? If you're using an onboard video port, can I assume it's just an Intel controller of some kind? What do you see under 'Display Adapters' in Device Manager?

When I visit the page that Imgburn.com links to, I see this. If I then click on 'Click Here To Download', it downloads 'Setup_ImgBurn_2.5.8.0.exe' and there doesn't appear to be anything wrong with that file - it shows up as 3,030 KB in Explorer.

You missed the burning bit out from the log. Your screenshots suggest you're burning at max speed, which is 6x for your drive with that media. It might be worth trying one of the other supported speeds - listed in the box on the right when you're in Write mode with a blank disc in the drive. Using MAX / 6x, your drive appears to have done a bad job of burning the disc and it's unable to read it back nicely / properly. To rebuild an ISO with a problem like that, mount it in Explorer, fire up ImgBurn and go into Build mode. Point the 'Source' box at the virtual drive now visible in Explorer (from you mounting the ISO), click 'Start'. No need to copy anything anywhere else etc or make another ISO - unless you want to do that of course.

I was going to mention that but I couldn't be sure it didn't then try and remove them... which might have caused the same problem!

This is a bit of an impossible problem to fix (nicely). Your drive is returning some bogus info as the program tries to detect the real start of the track (what would be knowns as Index 0 / the pregap). D 18:52:11 Sub-Channel - LBA: 146991 (32:41:66), Raw Data: 01 16 02 04 4E B2 00 64 82 CC 00 00 00 00 00 00 D 18:52:11 Sub-Channel - Original: 146991 (32:41:66), Wanted: 146991 (32:41:66), Got: 294132 (65:23:57) D 18:52:11 Sub-Channel - LBA: 146991 (32:41:66), Raw Data: 01 06 02 04 4E B2 00 64 82 CC 00 00 00 00 00 00 D 18:52:11 Sub-Channel - Original: 146991 (32:41:66), Wanted: 146991 (32:41:66), Got: 294132 (65:23:57) D 18:52:11 Sub-Channel - Bogus response data! D 18:52:11 Sub-Channel - LBA: 146992 (32:41:67), Raw Data: 82 02 02 C0 01 74 00 32 41 67 54 0C 00 00 00 80 D 18:52:11 Sub-Channel - Wrong Type! D 18:52:11 Sub-Channel - LBA: 146993 (32:41:68), Raw Data: 01 04 00 00 01 73 00 32 41 68 00 00 00 00 00 00 D 18:52:11 Sub-Channel - Original: 146991 (32:41:66), Wanted: 146993 (32:41:68), Got: 146993 (32:41:68) D 18:52:11 Sub-Channel - LBA: 146993 (32:41:68), Raw Data: 01 04 00 00 01 73 00 32 41 68 00 00 00 00 00 00 D 18:52:11 Sub-Channel - Original: 146991 (32:41:66), Wanted: 146993 (32:41:68), Got: 146993 (32:41:68) D 18:52:11 Sub-Channel - LBA: 146993 (32:41:68), Raw Data: 01 04 00 00 01 73 00 32 41 68 00 00 00 00 00 00 Your drive is returning invalid subchannel info for sectors 146991 and 146992 and that info is causing the program to loop as it attempts to find the real start of track 4 by applying an offset based on what the drive is reporting. For example, the '16' in the top line's 'Raw Data' is supposed to be the track number. Well... there aren't even 16 tracks on the disc! It also then magically changes it to 6 and yet everything else is the same. (6 is still wrong) That bit of code that is responsible for 'Analysing Tracks' is actually quite a complicated due to the fact that some drives have to be told to return info on sector X to get info on sector Y. It isn't just a case of trying sector Y and if you don't get the info, moving on. You have to work out what it's given you after your initial request and then apply an offset to what you ask it for the 2nd time. Some also jump around, so you'll ask for X and it'll give you Y+10. Then you'll ask again and it'll give you Y-5. It's a real pain in the a***. The best thing I can probably do in this situation (and what I've now done) is to implement a timeout whereby if no progress is made into narrowing down the true start of a track (and therefore end of previous track) within 30 seconds, it times out and moves onto the next one. I can see the current code narrowed yours down to just being left with those 2 problems sectors pretty quickly (around 3 seconds), and if the pregap is out by 2 frames (2/75th of a second) due to those issues, so be it. It's better it moves on (using what it has successfully figured out) than gets stuck for all eternity trying to perfect it. D 18:51:57 Session 1 -> Track 4 -> ISRC -> None Found! D 18:51:57 Sub-Channel - Previous Track End LBA: 0 (00:02:00), Current Track Start LBA: 147142 (32:43:67) D 18:51:57 Sub-Channel - LBA: 147141 (32:43:66), Raw Data: 01 04 00 00 00 00 00 32 43 66 00 00 00 00 00 00 D 18:51:57 Sub-Channel - Original: 147141 (32:43:66), Wanted: 147141 (32:43:66), Got: 147141 (32:43:66) D 18:51:57 Sub-Channel - New Current Track Start LBA: 147141 (32:43:66) ... D 18:52:00 Sub-Channel - Previous Track End LBA: 146990 (32:41:65), Current Track Start LBA: 146993 (32:41:68)

That setup option just manipulates a few reg keys. Reinstalling over the top and enabling the option is fine. You won't lose your settings. You could follow this instead if you prefer... https://www.tenforums.com/tutorials/156422-enable-remote-access-removable-storage-devices-windows.html

Sorry to be a pain... can I get 1 more log please?! Load the program and go into Read mode. Press the F6 key to enable Program Debug Mode (you'll notice a log entry) and then start the read again. *do not enable I/O debug mode (F8)* You don't need to leave it repeating the same thing over and over when it gets to track 4, just long enough to capture whatever it's looping on. I'll need the complete log of that session please. Don't crop it as I want to follow the program logic right from the start. Thank you!

Thank you. Can you now go into Read mode and copy + paste all of the info from the box on the right when that disc is in the drive please.

It errors out like that because it predates UAC and used to be able to write to HKLM in the registry. Now it can’t. Run as admin and you won’t get the errors.... or ignore them as you have been doing. iFO RC is IFO file region code. It’s just a byte in the file where you can set which region the disc is for. That’s in addition to the regional code the disc itself might have.

That doesn’t sound right. Lba out of range means it’s beyond the end of the disc. Can you provide a log showing that stuff at all please?

I don’t know what you’ve downloaded there, but it certainly isn’t the ImgBurn setup program (installer). What exactly did you click on when over at the digital digest website? Screenshot that site for me please and show me what you clicked on.

I wonder when the discs were manufactured? Maybe they’ve deteriorated and the drive can’t reliably burn them now. You could try enabling the ‘perform opc before write’ option in the settings and see if that makes a difference.

That info is beyond the 2048 bytes of user data in a CD sector and therefore not included in an ISO. As for making the drive burn as-is (errors and all), that's where RAW mode burning would come in - which ImgBurn doesn't support.

Yes, a properly connected ssd would be fine.

The success one was too loud (it used to scare people), so I’m pretty sure I adjusted it down slightly.

They could be important if the game checks for bits that are intentionally wrong. If your drive corrects them, it’s actually made them ‘wrong’ - and then the game may not play correctly. It could also just mean your image isn’t great in the first place.

Well... there’s only ever 1 active drive in the program at any time, so you can only burn to 1 drive at a time. Different instances can burn to different drives simultaneously, but your storage device(s) would need to be fast enough to support it.