Jump to content


  • Content Count

  • Joined

  • Last visited

Posts posted by LIGHTNING UK!

  1. 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.

  2. 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.

  3. 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.

  4. 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.


  5. 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.

  6. 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.

  7. 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 :)

  8. 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?

  9. 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.

  10. 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.

  11. FAQ


    You get an error in the ImgBurn log window saying remote sessions (RDP) aren't allowed direct access to removable storage devices.


    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


  12. 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?

  13. 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?


  14. 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.



  15. 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.

  16. 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)





Important Information

By using this site, you agree to our Terms of Use.