Jump to content


  • Posts

  • Joined

  • Last visited


Profile Information

  • Gender
  • Location
    United Kingdom

Recent Profile Visitors

23,687 profile views

LIGHTNING UK!'s Achievements


ISF God (5/5)

  1. It sounds like your drive is occasionally doing a bad job of burning the discs and they’re then unreadable - hence failing at the verification stage.
  2. That would need to have been because of a different issue (like analysing gaps between tracks or something). An unreadable disc is an unreadable disc - they only have access to the same commands (to 'read' a sector) as I do.
  3. If your drive still can’t read the disc, there isn’t much you can do about it. See if you can read it using another drive.
  4. It’s ok, your text version was enough. Thanks anyway though. Not sure how you managed to burn that image with AnyBurn, it rejected it for me. I also tried it with the non-Christmas version of Nights and it made a right mess of the disc (incorrect track sizes etc.)
  5. My cue doesn’t actually match the one from here - http://redump.org/disc/7004/ - but it was the only dump of it I could find easily. Can you post your cue file please?
  6. When I burnt it, it was only the 150 sectors in the pregap of track 2 that weren’t right. That doesn’t affect the actual data, so it might be fine. Does it actually play?
  7. Does your bin/cue image consist of 20 bin files? I take back what I said last night, the image I have here for the christmas version of Nights doesn't specify PREGAP in the CUE, it's making use of INDEX 0 and taking data from the corresponding BIN file. The non-christmas version used PREGAP. Looking at the 2nd bin file (which is the bin for track 2), I can see that byte 15 is set to 01 (in each of the first 150 sectors (of 2352 bytes) of the file), when it should be 02 if it's a mode 2 track - as specified in the CUE file. So in my case at least, the BIN/CUE are wrong.
  8. I will look into it. It would have helped to see the actual error in the log, but going by the CUE I found online, it's noticing differences in a pregap sector - and they're generated by the program.
  9. Somewhere in the product listing you should see the various read and write speeds for the different media types supported by the drive. Are you after a dvd drive or a bd drive?
  10. The speed of the connection can and will limit the speed of the drive. A fast bd drive won’t work properly over a usb 2 connection. I doubt you could buy a recent model that doesn’t have the correct connection type required to achieve what the drive is capable of. Therefore, you probably don’t need to worry too much.
  11. ImgBurn doesn’t instruct the OS to ask you to run it elevated. Apps configured like that have the little yellow shield in the icon. If UAC is disabled, obviously it won’t prompt - because everything then runs as admin. When enabled, it’ll prompt if the app asks to be elevated - which again, ImgBurn doesn’t.
  12. ImgBurn is not a command line tool and the flag to eject is only looked at after an operation (read/verify/burn etc) has completed. There's no way to use it to just eject the disc like that.
  13. Not at all like an idiot, don’t worry [emoji1303] If you’re doing tests and making comparisons, it’s just best to test like-for-like (as much as possible anyway). So the iso must be played from a virtual drive and you must then use the same software player to play the burnt disk.
  14. Are you mounting the ISO as a virtual drive and then playing from the virtual drive, or are you simply loading the ISO in whatever playback tool you've chosen to use? The two methods could cause the playback software to behave differently. If the ISO is really ok, there's no reason for it to behave differently when burnt to disc - subject to the device being able to read the disc nicely / quickly enough. Whilst there are probably people on the forum that could offer some advice, your issue doesn't sound like it's related to ImgBurn... or even burning in general. You might be better off asking for help at somewhere like videohelp.com
  • Create New...

Important Information

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