LIGHTNING UK!

No. and it works fine here... but then I use the links and not the back button.

There's no such thing. It's just what people who don't know anything tell other people that know even less.

In theory, no.

Some people just do.

No, never. It doesn't know, care or understand what it's being told to burn, it's just a bunch of data.

It's impossible for me to say. Try another one (made in Singapore) and see if it's any different. If it isn't, try another drive.

Well, you don't, so it's a moot point. I can't override something the OS blocks. If you want D+D in Build mode, use Advanced input mode and use the built in Explorer type pane.

No - unless you click the right things and press the right keys manually.

You should only need FHT and Smartburn enabled. You can leave everything else on default - oh and you only need to clear opc history before the first burn with those settings, leave it alone after that. If you're still having problems, it's probably your drive or the discs at fault.

Consider yourself deleted.

It just looks like buggy drive firmware to me. It's accepting the modified layer break position but then when asked what the layer break position is set to, it's returning the original / unmodified one. The verify phase seems to show the modified one did actually take though.

It works with certain proper changers/autoloaders and robots that work with the semi generic command set. If you want to make a home made robot arm that responds to that generic command set in the same way, it'll work right out of the box. Otherwise, there's no chance.

It already does that. It's the autoloader stuff.

oops, my mistake! I knew what I meant It's byte 80 (starting at 0) - the ecma-119 pdf shows the values as starting from 1 (so it's byte position 81) and that's what I (badly!) tried to make clearer. What's in the 9 blocks at the end of that ISO? Just zeros? That number is only useful if it was right in the first place (and if other file systems are present, they could make it wrong). There should be no constant overhead, no. If there was, you'd kinda expect it to be 16 sectors worth (meaning it didn't include what's before the PVD). The 9 is probably just rounding up the image size to a multiple of 16 sectors (1 ECC block).

Try reading the 'Volume Space Size' in the 'Primary Volume Descriptor'. It's 4 bytes long, starting at offset 0x080. The PVD is typically in sector 16 (check for at 1 in byte 0x000 and the 'CD001' signature at offset 0x001).

Batch build mode is too much like hard work, sorry. You could use a normal batch file if you have another little app that can move the discs around (via the robot) between burns (builds).

They aren't, it's just picking up a signature from a sector on the drive. When there are x million of them, that's bound to happen eventually.

because that's how Windows works. You can't drag from a non admin app onto an admin app. MS blocks it.

You're ok to 'use' it, yes.

Why would it be? You've got a drive you're trying to recover that you know is (was) formatted using NTFS. Why would you bother looking for other filesystems?

The correctness of an image has absolutely nothing to do with whether or not it'll burn.

It's 1 checkbox... that's it.

Don't run it as admin, you won't be able to D+D from Explorer if you do.

Going back to r-studio... When you tell it to scan, just tell it to only scan for NTFS stuff (I assume that's the FS used on the HDD?). I'm pretty sure I remember there being several random things listed on the one I did years ago, you need to find the 'most correct' branches from what's listed. Recover is hardly ever going to be perfect.

This isn't your thread darkavix, don't hijack please.