LIGHTNING UK!

Happy Birthday Spinner! (Glad we got the forum back online just in time )

The drive doesn't care about the content of your image, it could be all zeroes for all it cares. The problem here is just that it can't read back (full stop) what it just wrote. Of course, that should NEVER happen unless: 1. your media is rubbish 2. your drive is rubbish 3. the drive doesn't support the media By 'rubbish' I mean it could be rubbish in general, just a 1 off fluke or that it needs cleaning.

If someone wants to provide me with such a device, that's fine by me

Load ImgBurn Select 'Read' mode. Read disc to image file. Select 'Write' mode. Write image file to blank disc. It should all be pretty straight forward!

Yup. Obviously you have to remember that you're not backing up the attributes... they're not stored in the file or anything. It has to be something that's also available in the filesystem you then use on the optical media. From what I could find, the ISO9660 filesystem only allows for a very basic set of attributes - and by 'very basic' I mean 1 attribute - the 'hidden' one! I guess 'system' just wasn't really considered for ISO9660 as it's an optical disc and not your hdd where you'd run the OS from. It could be different for UDF if you add structures for extended file attributes, I've really can't remember and reading filesystem specs isn't my idea of a good time

8 bad sectors in a row (at least)... are you sure you can't see any visible defects on the media? There's not a different colour ring around the 2/3rds mark on the disc? Like I say, I couldn't make the program burn a sector that then couldn't be read back even if I tried! Whatever's going on there, it's out of my control. If the buffers are dying and the drive coughs and splutters, it's burnproof stuff will kick in. If that's not doing it's job properly and isn't zero loss linking as it should do, that's where your errors might be coming from.

As this is major, I'm working my arse off to get it ready (2.3.1.0) within 24hours. I've had a few other bits to sort out too

Covered in the bugs forum (and has now been fixed). Sorry!

It's remembered your settings for ages. Previously, you must have been uninstalling then reinstalling - that of course would wipe out your settings.

I couldn't see such an attribute in the filesystem specs.

Oops, no, scrap that! At the level I was bodging the support for the old style shortcuts, the windows messages don't seem to differentiate between upper and lower case letters. That must come later or something. My 'case' statement however was checking for: case 'b': case 'B': { // do some stuff } break; But really, I only needed case 'B': { // do some stuff } break; The 'case 'b'#39; was the cause of the issues as 'b' as a value is the same a the numeric keypad '2' key. In any case, it's fixed now. Thanks

lol for some weird reason the numeric keypad keys have the same values as some normal letters on the keyboard! So, keypad '1' is actually 'a', keypad '2' is actually 'b', '3' is 'c', '4' is 'd' etc etc. In modes that don't generally accept keyboard input (for file names and a like) I let the old style 'mode' shortcuts still work - i.e. 'b' for build mode, 'l' for the log window etc. (rather than ctrl+alt+ So keypad 2 wont work because it switched to build mode. Keypad 4 won't work because it switches to discovery mode. I obviously need to use some other part of the windows message to find the difference between a real 'a' and keypad '1' etc. It's ordinal number clearly isn't enough! Alternatively I'll just ditch the old style shortcuts where people could switch modes with a single keypress.

Only old games tend to have multiple tracks. CDDA is a major waste of space so most would now use compressed audio formats (i.e. MP3 or their own version of it)

The program can't make bad burns like that, it's just not possible. All it does is supply the drive with data, the drive does the burning and has full control of the burn quality. If you get a read error during a verify, it means the drive failed to write to the disc / those sectors properly - again, there's nothing the program can do about that. It's a shame you don't have the logs... those and the IBG (Graph Data) files can really help in situations like this. It's odd that you say both buffers were emptying towards the end of the burn, that would indicate a problem reading from the hdd. If it was just the device buffer, I could perhaps understand it.

If it's estimating a burn time of 35 mins, that's about 2x speed. You should be burning at 8x so that's way to low. As such, I'd say you have DMA issue and should therefore checkout the post in the FAQ that tells you how to fix them.

It looks like the drive is producing duff burns and is unable to reinitialise the disc properly after ejecting / reinserting it. This sort of stuff is beyond the control of software. The drive just isn't doing what it's told.

Why don't you set the eeprom values, then you won't have to touch it again?!

Isn't it 'Normal (3)' ? I don't have the official specs for booktyping on LiteOn drives so I don't actually know what '3' means. I expect it to be a 0 or 1 I think, but 3 is typical of a drive where no setting has been configured.

Count the slashes, not the folder names. You don't see the 'Root' folder but it IS there! The original image breaks the specs in more ways than just directory depth. All of the options can be adjusted to get a working image though - including one to get around that initial problem.

It's probably too late now but I'd have like to see the info from the panel on the right within ImgBurn when the disc was booktyped to DVDROM. ImgBurn doesn't care about the booktype value, it's looking at the 'Current Profile' field most of the time - and that's what the drive thinks the disc is. I bet what actually happened here is that you've got Alcohol emulating DVDROM for writable media and so ImgBurn never sees the disc for what it is. Turn the option off in Alcohol and your problems will go away. Alcohol does this itself automatically when IT wants to burn a disc, that's why it works when nothing else will.

This is covered in the FAQ anyway. In vista, the sidebar is also known to use the drive and hence prevent ImgBurn from obtaining exclusive usage of it.

Only if you load a project with that info stored in it. You can manually edit the project file and remove anything you don't need / want to change.

your drive doesn't think there's a disc in it - or at least that's what it's reporting.

well i did just say it was a cosmetic issue and the button i made up was quite cute

Have you tried IsoBuster? It's designed for this type of thing.