LIGHTNING UK!

There is never any dummy data, the drive does the padding.

Do you get that access violation error every time you try and erase a disc? What does the log window say? Try a full erase and copy + paste the full log please.

Sure thing, no problemo

Speaking from experience (programming wise).... making little (ISO9660) names from long ones is a pain in the arse, especially if you're doing a lot of them. It's slooooooooooooooow I'm finding these things out the hard way by attempting my own ISO creation util.

Billy, try actually burning at 8x. It's quite possible the write strategy for TYG02 @ 2.4x is worse than the 8x one. Hopefully they are real TY discs too

The only program you can use for DL images is PgcEdit.

Not with ImgBurn, no. Search google for 'ConvertXtoDVD'

Just to get something clear... it burns CD ISO images just fine. It won't burn CD-DA images or any other images that are mutli track/session images.

It doesn't matter what made the image, if you burn it and verify it in one go, you shouldn't get a miscompare. If you did: 1. your drive didn't burn it properly or 2. your drive can't read it properly or 3. some other program is changing data on the fly (i.e. AnyDVD). (or and combination of the above).

Erm yeah I think that's right! If LB is passed via CLI, I don't analyse the IFOs so therefore I don't update them. (This applies to all versions). In the betas (i.e. POST 1.3.0.0) , I've done the following: Via the standalone method, you will get a dialog box (all the time now - even if only 1 LB position was found) where you can tell the program not to update IFO files, or to revert to NAV packet/ECC boundary search (which also appears to work on non fussy players and will give 50/50 split between layers most of the time).

probably, I don't have the specs for the nrg file format so it's all a bit of guess work and I can't say as I've ever made a Nero cd image so wouldn't have ever tested it!

(I Think!) I've already made the changes this requires as a result of someone else bringing it to my attention. From what I've read, it appears the LB positions is still exactly the same as where it would have been in previous version of PgcEdit (i.e. at the start of a new cell, chosen by the user), but now the flag isn't set (or is set.... one of the two!). Previously, ImgBurn would have just then set the flag again before doing the actual burn. I've added a tickbox to the 'potential layerbreak position' dialog box so you can tell it not to update the ifo's.

Indeed, if you need to edit the contents of an image, DT is not the tool for you. I believe people use things like UltraISO.

Unicode is not an option at the moment I'm afraid.

I must admit, what you're seeing there, specifically the 'Unable to recover TOC' error message, is exactly what I kept getting when my PX-716A broke the other month. I just filled out an RMA form on Plextor's site and they sent me a new drive. I assume you've tried burning at 2.4x too? (Even though 6x should be fine with that drive).

There is a standalone verify mode within the program - under the 'Mode' menu at the top You can't set the read speed though - well, not at the moment anyway. It's something I'll add in later on probably.

1) DVDInfoPro is supposed to update a certain reg key/value each time it's opened/closed. It's that key/value which I use to locate the main program exe - there is no process of remembering where the exe lives. Normally, it's 'HKEY_CURRENT_USER\Software\SWN\DvdInfo' and the value I read is 'Installation Directory' ImgBurn then takes the path in the reg value and appends '\\DvdInfo.exe' to it. That should in theory give me the full path / filename with which to run DVDInfoPro. Only YOU can tell me why that's not working! If there is a problem I can fix, I will. 2) When you tick the 'shutdown computer' option, it goes hand in hand with the program closing down. i.e. you can't have 1 without the other.

I've done that too. It now include the text: 'File System(s)#39; and lists them like 'File System(s): ISO9660, Joliet, UDF'. Hopefully that's what you were after.... if not, tough because that's what I've done

xt5, look in the settings. If you know where it should be, use that. Obviously that can't get around the problem that OTP Layer 0 must be >= L1.

I'm not sure how to test and see if that symbol can/is supported! I guess I could check the regional settings and only use that symbol if it's set to 'english (something or other)'. Even then, I'm not sure if that would make it worse for other people who would then be forced to see '+-' or something.

1) If only 1 errors out, the other 2 should be ok. 2) As we've always said, Ritek DL discs are awful. Changing the i/o interface wont change that!

Cheers, I didn't realise that field was written in the format that is it. v1.50 is actually written as 0x0150. So when I read the '50' byte, I get 80 in decimal - hence where 1.80 came from. I'd not seen any discs other than those using v1.02, which of course doesn't suffer from that problem!

I think he/we were talking more about you just using those as the source files - i.e. rather than having to actually extract them and taking up another 7gb of space. Then of course you'd have to write the new ifo files to a temp directory and merge them back in (logically of course!) with the remainder of the (read only) source files from the mounted image, ready for mkisofs to build a new iso.

I assume you've checked for firmware updates etc?

That scan is just fine! Couldn't really ask for much better! I'd be interest to see one of the disc that errored out during the verify. As for the exact meanings of the PIE and PIF, you're probably better off searching Google.