Jump to content

LIGHTNING UK!

Admin
  • Content Count

    29,975
  • Joined

  • Last visited

Posts posted by LIGHTNING UK!


  1. Your drive reported a 'Write Error' early on during the burn - right at the start actually.

    I guess it has an issue with the media. If say you've tried multiple different ones (not just different brands, but with different MIDs), maybe your drive is at fault?

    There are firmware updates available for the drive that may or may not help. v1.03 and a recent v1.05.

     

     


  2. I guess because that's just what it defaults to?

    You can't make something from nothing though and 2048 bytes images only contain 'user data'. Nothing that writing in RAW mode would do anything for.

    Should you be so inclined, you can look up the structure of a CD sector and see the difference between 2448, 2352 and 2048 byte sectors. 2448 being the same as 2352, but with the added 96 bytes of subchannel.


  3. I suggest you take a 2nd look at the name of the application you're using.

    What part of 'InfraRecorder' looks like 'ImgBurn' ?

    Getting back to the application this support forum is actually for... ImgBurn... that doesn't offer RAW at all. Your other thread is beginning to make a little more sense now. It seems you have your apps confused.

    btw, as an ISO is meant to just be 2048 bytes per sector, you're wasting your time even looking at RAW writing. You don't have any data in the image that would benefit from being written that way.

     


  4. As verify re-reads the image and compares it at bit level against what's read from the disc, it can actually be better at finding problems. For example, if there's an issue with data corruption when reading from the source drive (but no 'hard' error) or a memory issue (faulty ram), verify would give you a 'miscompare' error. Hardware Defect Management won't notice that kind of thing.

    As you say, it's pointless formatting with spare areas and then turning on fast write. Just format without spare areas.

    Only if I really wanted to make sure everything was ok would I use hardware defect management AND verify. I don't think I'd rely on hardware defect management alone (as in, verify being disabled), but I'd certainly rely on verify alone (as in, without HDM being active during the writing phase).

    Yes, spare areas are transparent to software. The drive handles remapped blocks itself internally.


  5. Can you post the log please?

    If it burnt and verified ok, the disc is ok so far as your burner is concerned. The issue then falls with the image itself or your playback device (being unable to read the disc or something).

     


  6. It's normal for it to perform a 'one time only' full format and zero fill of a new BD-RE. ImgBurn defaults to liking discs fully / properly formatted and there are structures on the disc that (in a non-user data area) that tell the program if it is or not. Once it's been formatted properly, the program just makes use of the Direct Overwrite capability of BD-RE media.

    It's not normal for it to get stuck like that during the zeroing phase.

    Assuming you terminated the program somehow, did you happen to save the contents of the log window before doing so? The log only saves when the program is closed down cleanly.


  7. The problem here is that you're asking for 'help' on something that's actually quite complex... and perhaps you don't fully appreciate that?

    I don't have any code samples, I did exactly what I suggested you do.... located the specs of the file systems, learnt about the different descriptors and then wrote the code to create those descriptors. If you don't understand everything in the file descriptors and how they build up the file system as a whole, you don't stand a chance in writing a program to do what you're trying to do.

    ISO9660 is the easy one. Joliet is a slight change in order to support multibyte character sets. UDF is a different ball game, and then there are different version of that, so it's multiple different ball games.

    Actually, maybe I've assumed wrongly here? When you said you wanted to create an ISO, I assumed you wanted to 'build' one. That would involve you learning about file systems. If you just want to read a pre-existing disc in a drive and save it as an ISO, that's something entirely different. To save you wasting your time on whichever forum you go to next, spell out exactly what you're after. Arrogant people such as myself, don't like to have our time wasted by people who want something for nothing and then get all snotty when they don't get the exact answer they wanted.


  8. Do you want me to write it for you?!

     

    There’s plenty of stuff out there if you Google for it. This is not a coding forum.

     

    Start with iso9660. Learn which descriptors are required and where they need to be located within the overall iso. Fill them out and build your image.


  9. @Ch3vr0n

    Whilst that is one sort of 'lock' (tray lock), the one the OP is referring to is there to stop other programs from being able to access the drive and potentially mess up the burn. It either blocks apps from opening a 'handle' to the device or it blocks all operations on said 'handle'.

    @Robert333

    As it locks for exclusive access before any burning starts, you're quite safe to pull the plug if it gets stuck for ages trying to lock it. I'd actually be interested to see what happens when you do that. Will the OS immediately return an error in response to the locking request (which is then displayed by ImgBurn) ? Who knows!

     


  10. The locking of the drive is a Windows API function, so if it's taking a while, it's because Windows is (still) trying to lock the drive.

    As for why it's taking a while, maybe some other program/service has an active connection to it?

    Try unplugging it and plugging it in again. They are probably tools you could use to check for open 'handles' to the drive - something like Process Explorer from Microsoft/sysinternals.

     

×

Important Information

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