LIGHTNING UK!

Just as in DVD Decrypter, ImgBurn's default settings are/work best. Leave them as they are. FYI: 1. SAO and DAO are the same thing. DAO is the correct term for when talking about DVDs though. 2. This is how DVD Decrypter talks to your drives. The common method is to open them using the path '\\.\CdRomX' - where X is some number. That's the 'Cdrom' class. The alternative is via their drive letter using the path '\\.\X:\' where X is the drive letter. That was mainly added for linux users who use the program via Wine. Any DL burning issues people are having with ImgBurn are exactly what they'd get from any program. They use crap media with crap firmware. The best they can expect from that combo is crap burns! No software can change that. Yes of course it's better to use ImgBurn. You can see the list of changes from the changelog. Of course every version has new features and improvements over the last one.... pulling it further ahead of what it was in the good old days of DVD Decrypter.

I hope to add this one day.

No luck with that but I have found something else. Any chance you could convert those 2 files to their ISO equivalents using the hdiutil program and then post them up too? I can read the parition map ok now and locate the start of the disc image partition, next I need to know exactly what has to go into the resulting ISO file - and hence burnt to disc! If you just burn the entire thing, that's pretty simple! The DMG's you've sent me are just ISO images but have a sector size of 512 instead of 2048. So I just have to expand 512 -> 2048 (I think )

No problem. I did go over all the code to do with that stuff but couldn't find anything that was obviously at fault. Please do let me know if it happens again (not that I would expect it to!)

already running? That's the error message? I don't have such an error message coded within my program. It could be an API call's error but I'd need to know the real error before I comment on that. So basically, before I can help / fix things I need lots more details off you please. A copy of the log would be nice. Screenshot maybe?

Sorry, I looked at the files you posted and that dmg util doesnt work with them. If only I had the code to Apples hdiutil program!

Ok, maybe basic ones.... but no promises

Update your drives firmware. It's on 2.1A now I believe. http://support.necsam.com/optical/downloads/flashfirmware/

lol, mine was a reply to the - 'Is this very wrong?' bit, not 'Am I a bad person'

No, just totally pointless!

Works ok in 2003 (SP1).. I assume XP (SP2) would be the same. That's enough for me I will double check that via VMWare though and if it doesn't work, I'll have to resort to manually setting it back.

Fixed, tried and tested. I also added the 'All' / 'None' buttons for you in the File Association box

Ok, seems it is a current dir thing and the the getopenfilename box takes it upon itself to change it! As I flick through the folders, I can see the folder handles being created / destroyed within Process Explorer for ImgBurn.exe If I cancel, it goes back to the default - i.e. where ImgBurn.exe lives. If I click Ok, it stays on that last folder. OFN_NOCHANGEDIR as one of the flags will fix that. Should have looked into this ages ago... it's annoyed me for years!

Like I kinda said before, it's not my code that's keeping the handle open to the folder. It's part of the 'GetOpenFileName' API call. You would expect the handle to be closed when the box is closed, but it's not. Unless the 'File' entry I'm looking at within Sysinternal's Process Explorer is just a result of the GetOpenFileName box changing the programs current directory, I don't think there is anything I can do (and no I'm not going to 'hack' around with things!) If you drag and drop a file into the 'Source' group box, you'll see that you don't have the same problem with not being able to delete the folder that the image lives in. It only happens when you use the 'Open File' box. Programmatically, the 'browse for file' part just runs a tiny function to initiate the open file box (no file / folder opening at all). Once it's got the name, it runs the same code as the D&D part to actually initialise the image file and get the info about it etc.

I don't think it's the file that's locked, it's the folder. Explorer's 'Open file' box just does that, I can't help it! If it IS the file, that's my problem and I'll fix it.

Replied at cdfreaks.

I always recommend people stick to the default settings. They're the ones I use all the time and so undergo the most testing. SPTI allows for other clever things too that aren't as easy/possible at all under ASPI. The Elby and VSO drivers are quite similar though.

By the looks of things, the DMG format is a compressed image containing multiple partitions etc. To be honest, that's too much of a pain in the butt to get around on-the-fly (at the moment at least).

It would have always been hanging there. You've just enabled I/O Debug mode so it chucks loads of stuff in the log that you wouldn't normally see. You need to turn that off now. Do so by pressing F8. lol I've been doing this stuff so long now, I've seen almost every problem people are likely to come across. Not only that, I actually went out and got one of those ASUS drives back in the DVD Decrypter days to try and solve a problem very similar to your own. Back then it was a firmware problem and I remember that only the 1.08 firmware fixed it - hence why I told you to update yours. Not that it matters now but that ASPI fix is not for you. You're using SPTI so ASPI doesn't even come into the equation.

Firmware updates?!?! Plextor is on 1.07 now. Asus is on 1.08 now. There were huge problems with earlier versions... I even made a point of posting about it on the old DVD Decrypter website. The Asus drive is actually getting stuck when asked to report it's region info. It's certainly nothing SATA related, I've got 4 of them in my box (and 4 IDE and 3 SCSI).

lol that looks shocking!

I've taken a look at vlc, seems like it can just read the first bit of an a/v file if it's in an uncompressed rar.

It might be

The program supports burning onto dvd-r dl just fine. The problem here is why the actual dvd-r dl standard, which doesn't appear to support moving the layer break position - where as dvd+r dl DOES allow it.

ExtractAssociatedIcon Windows API is supposed to work.... but it doesn't