LIGHTNING UK!

Yes

The standard command to fully format a DVD+RW will wipe the disc clean, but it doesn't appear to on BD-RE (or certainly it didn't when I first implemented support for erasing such discs). That's why the 'zeroing sectors' phase exists for that media. The remapping of bad sectors is not something ImgBurn does itself, the drive controls all that stuff and it only happens if you've opted to format with spare areas enabled. Can't say that I've ever tried issuing the SMART ERASE command to an optical drive, I don't recall it being covered in the MMC docs, so I've never had a reason to. A drive will reject 'WRITE' commands if the DVD+RW / BD-RE disc hasn't been formatted first., so yeah, ImgBurn will do it if you haven't. It's up to you if it's formatted properly or not. Formatting it properly gives the drive a chance to check the entire disc - although as it's all handled by the drive and done in the background, so I don't know exactly what it's doing. All I know is that it reports something is still in progress and I wait (by default anyway) until it says it's finished

You should speak to primera and see if they can help.

I would try setting the write speed to 8x and giving it another go. If it can't burn any DVDs, you'll have to try sending it back or something. Maybe try some different discs and/or it in another machine (if possible) first though.

I hear what you're saying, but it just doesn't work like that If you can get a bootable floppy image and add your file to it (so it fits within 1.44mb), you can run it straight from a bootable CD that emulates a floppy. Trouble is, 1.44mb isn't very big! So then you're left with making a bootable image that loads CDROM drivers (giving you access to it via another drive letter) and adding your files to the normal bit of the disc. Any machine that can't boot from a USB stick probably isn't really worth messing around with anyway... it must be pretty ancient. And don't forget, lots of new machines won't have an optical drive at all. Your CD isn't much use then

The error is that their drivers can't find your device. D 11:39:23 PTRobot_EnumRobots - Robot Count: 0, Return Code: 502 502 = PTROBOT_INVALID_ROBOT PTROBOT_INVALID_ROBOT if no robots found So I'm afraid I can't really help as it's an issue outside of ImgBurn. Has the device installed itself correctly if you look in Device Manager? Maybe there's something these with a yellow triangle by it. Perhaps try different USB ports too.

No, you must do exactly as asked... please I need the whole log and a screenshot won't do that.

You need a boot image that loads CDROM drivers. Forget your ISO file, find a boot image (a floppy boot image) that loads those, add that as the boot image within Build mode (so *do not* add it to the 'Source' box) and then add the other files you want to be able to access (once the cdrom drivers have loaded correctly) to the 'Source' box. You'll be accessing said files/folders via a different drive letter.

Copy and paste everything from the box on the right when you're in 'Write' mode please.

I agree, there's no problem to read the entire drive, it just wasn't written to do that. It only opens \\.\C: or whatever and so doesn't have access to the MBR. I spent a bit of time yesterday adding 'Physical Drive #x' entries to the list, so now there is indeed a method dumping the entire drive. The warning about unknown signatures isn't an issue (for people that know their MBR is correct), it's just to give people a heads up that things might go wrong. Seeing that message doesn't substitute in the program's built in MBR, so if you extracted your own dump of a full physical disk, that's what you'd have ended up with in the ISO - unedited. I was playing around with SeaTools on a 4GB stick yesterday doing various things and I couldn't get it to boot in vmware (at all), which is a shame. I guess I need to dig out a 2nd real machine to test it on - mine never really gets rebooted. I didn't ever get a message about missing OS though, it just came up with a syslinux message and sat there forever. That was with an ISO made where I'd only fixed the 'number of sectors' issue and ISO's where the full physical drive was being dumped and used as the boot image. Maybe I should give VirtualBox a go too to see if it behaves differently.

SeaTools Legacy is the one you want for it being a bootable ISO. Regarding the program, I don't think anything other than floppy and optical drives have really been used / tested with the extract boot image stuff - although I guess at the time of implementation, I must have done something or the code wouldn't exist at all. The program doesn't actually dump the entire drive, it only dumps the partition (corresponding to the drive letter) you select - partition is specifically mentioned in the message box that pops up. So that's why the MBR is different to that of the actual drive, it doesn't read the one on the physical drive - It has its own within the code... one from MS I guess, as that's what I'm running. I do not know the ins and outs of the MBR and I guess I hoped one would work for all.... obviously that isn't the case. There is no way to read the entire physical drive to a raw image within the program, but it sounds like that's what you're after. Thank you for reporting the issue with the partition's 'number of sectors' field in the partition table. I was using a variable containing the size of the entire boot image rather than just the size of the partition. That has now been corrected.

Did you burn a DVD Video disc? Post the log please. Generally speaking, this is nothing to do with ImgBurn. It burns what you give it, so if your system can autoplay that type of content, it'll autoplay.

Digital Digest have been in contact and I understand the link should be 'clean' now. Again, I can't test it because it's always been 'clean' for me - must be a location thing.

The Disc/Manufacturer ID itself should not change between programs. ImgBurn queries the drive for a particular chunk of info and the DID/MID is contained within it. Having discs in the same spindle with different MIDs is very unusual.

I do not get the same download page you do (mine is fine) and I’ve passed on user concerns about the one offering the download manager bundle on multiple occasions. That’s why I’m recommending you contact them directly yourself. Removing them from the mirror list isn’t an option. They host this website - always have done.

Indeed, all 3rd party mirrors were sent perfectly clean installers. You should complain to digital digest if they're messing with things or offering harmful files.

Unfortunately, I have no way of finding out what ASC 0x44, ASCQ 0x07 actually means. As it's showing a range of sectors and then nothing after it for an individual sector, it means reading the block failed (for that 0x44, 0x07 reason) but when it then retried each sector in that block individually, they were all readable. So in theory, nothing to much to worry about. I wonder if subsequent reads would produce errors in the exact same places? Worth a try maybe?

Can you post the log please? That error is from your optical drive, not a storage device (hdd/ssd or whatever).

Looking at an old ISO of Hirens (v10) I had laying around, it boots IsoLinux.bin.... so that's what you'd be looking for, not the bootable file from an OS installation type disc. v15 seems to boot grldr and the PE version (made by users), boots to a couple of methods (EFI and normal I guess) that don't have an actual file within the file system. You'd have to extract them from the ISO itself. Oh and you may have to relax the ISO9660 restrictions to allow files without file extensions. BOOTMGR may well be one of those files that can't be found unless you do. It does exist within your source files though yeah? It's in the root of the image on the one I'm looking at.

It's not something I've ever had to do, so I can't really help. As they all come as actual ISO files though, I'd just download from the source again and burn the real thing. Why waste time trying to recreate it?

ImgBurn has to use the sample grabber and null renderer.... I'm not 'playing' the file and instead have to capture the output from the LAV splitter/decoder. Playback would use the 'default directsound device' that graphstudio shows - i.e. outputting to your soundcard / speakers.

ImgBurn uses DirectShow for audio decoding. It specifies the source file and tells it the output format required. Everything else is pretty much automatic. Yes, source will be the file... or something that can read the file. For this stuff, ImgBurn is querying DirectShow for everything it’s using to create the ‘graph’. The vendor info stuff is again, coming from DirectShow. Some filters fill it in, others don’t.

Well, it depends on a few factors. ImgBurn attempts to read those last 2 sectors before deciding if they should really be part of the image. If they're unreadable, it won't include them. Sometimes it'll add stuff to the CUE file too, so it knows a bit more about the image and can adjust what it responds with accordingly.

That's not quite what I said. I said that specific line in the log was based on the 'Disc Capacity'. The values in the warning message are based on TOC information and Track Information. You can't just use 'Disc Capacity' when reading a disc unless it's single session/track.... and ImgBurn isn't just designed to read those, hence it never uses the 'Disc Capacity' value to decided on how much to read. The problem is, either number (Track Info, TOC Info) could be incorrect and you can't 100% rely on either of them.... which is why the warning exists. Your 'Track Information' and 'Disc Information' (Disc Capacity) would both suggest that Track 1 (as it's the only one on the disc) is 93122 sectors in length, but the TOC has other ideas and thinks it's 93124. That's common when dealing with discs recorded with the TAO method. So... if there's a difference between what your drive is reporting via the two methods, the program warns you about it. This is not a bug in the program (as the thing you linked me to would suggest), it's there for a reason.

Actually, I think your log shows it is creating the image correctly. >> I 17:12:44 Source Media Sectors: 93,122 ^^ That's from the disc capacity and is basically there for cosmetic reasons. I 17:13:04 Reading Track 1 of 1... (MODE1/2048, LBA: 0 - 93123) ^^ That's from the TOC (or Track Information, one of the two). It's 2 sectors larger and therefore should be correct... if that's what you're saying? ImgBurn doesn't use the disc capacity when making the image. It does however, like to tell you about potential issues when it notices that something isn't right. Copy and paste the disc info text from the box on the right when you're in Read mode please as it'll quickly tell us where the problem is coming from. Firmware bugs are more common than you'd think.