LIGHTNING UK!

That's what you've called your drive. If you type 'label' from that same command prompt window it should tell you what it is. i.e. label d: You should then see something like: C:\Documents and Settings\[username]>label d: Volume in drive D: has no label Volume Serial Number is 1234-5678 Volume label (32 characters, ENTER for none)? You can press CTRL+C to abort changing the label. Just remember what it says in the first line - you can see mine has no label. You need to enter that in the convert process. It's a kinda double check / fail safe prompt so you don't convert the wrong drive accidentally

Nero always says it's burning at the speed you selected, it doesn't mean it really is. Do you have a log handy? an IBG file? If you can provide those, maybe I can find the root cause. If you set the program to write a 'max', there is no scope for the program / drive to get muddled up. 'Max' is not a number as such, it's just sending 0xFFFFFFFF to the drive for the speed. After that, the speed is totally down to the drive. If it was burning at 4x when you selected 8x I'd say the drive is using the next lowest number - so selecting 10x, 12x etc might make it burn at 8x. This cannot possibly be the case with 'Max'.

If yours is a Dell machine, get the E113 version from here http://forum.rpc1.org/dl_firmware.php?download_id=2279 Also, slowing decent media down to 4x doesn't mean you'll always get the best burn. They may do more work with higher speeds so be sure to try those too.

So you need to use custom and put sectors to load at 4. The boot bit on windows cd's is 2k so it's actually a common size.

rcubed, Are you clicking on the little picture of the camera (actually on the DIP screen) when you take a screenshot?! There's no way those pictures are true png images, it's all blurry around the text and the graphs look blurry too. That 2nd jpeg turned png of yours is over 400k but as a png it's about 90k! (See attached - and notice how much clearer it looks) As you say, the IBG doesn't show anything too weird, not even when sampled. I'm at a loss, sorry. The numbers all add up but it just doesn't make any sense!

Do you ever see the 'Waiting for buffers to recover' message in your log? If not, these won't do anything - and you don't really want them to cut in early. Just make your main buffer bigger if your machine has trouble filling it all the time. Basically though, it's when the main buffer falls below the set level and the device one does too (it has to do this a few times in a row - sampled every 250ms I believe), the program pauses until the main one is full again. It will also wait for disc activitiy to go below the said threshold. You can view this stuff in perfmon.msc

The program isn't going to change what it does on a per instance basis, the lines a hardcoded to send the speed to your drive depending on what you select for the speed. I've never actually heard of that media brand, maybe it's a cheapo one that your drive doesn't fully support. The drive could be slowing the burn down because it knows it won't get a good burn if it burns at full speed.

Thanks. I know we all like to flame and make a stand, but it's gotta end sometime - right? Anyway, I think the original purpose of this thread has been dealt with so I'll close it.

Deleting the IDE controller and rebooting will fix your DMA problem. That'll then fix your speed issues too (as they're one in the same thing). It's pretty simple if you read + try it at the same time. To read it without doing it might make it seem difficult.

I'm going to assume you were typing that as I typed (and posted) my last reply MJ

ConvertXtoDVD is a good one, can't be sure if it'll read asf files though. http://www.vso-software.fr/

It's not really a burning apps job I don't think. I've added support for reading that info - for volume label purposes - but I think that's about as far as I'd go. Sorry

Pllllllleeeease don't turn this into another flame thread, I'm bored of them! Talk technical or don't talk at all please. If you reply, they'll relpy - and vice versa. So just don't!

First things first, update to the latest KS0B firmware... http://forum.rpc1.org/dl_firmware.php?download_id=2056 ...then try again. If it still fails, read the following! The thing with bad media is that you never know how close to failing the ones that 'worked' were. It's easy to go between working / not working several times when going through a spindle of cheapo discs. If you look at the log, it's taken your drive 2 minutes to burn 1690 sectors when it should have burnt closer to a million! So basically your drive is having real trouble with that media and it certainly wouldn't hurt to at least give something else a try. You only need to buy 25 or whatever, so you're looking at spending ?7 odd. Get some Verbatim MMC dye discs or some Taiyo Yuden ones. If you still get the same error with those, THEN you can start messing around with the million other things it may / may not be.

Avoid CMC MAG media. Use Verbatim MMC dye discs or Taiyo Yuden ones.

Nope, scrap that, I see now the LCISOCreator just does a sector by sector read of the disc. That's different to actually building a new filesystem. The size of the ISO should match (exactly) the size of the original disc.

Defen, That LCISOCreator might just do things slightly differently, or might miss a filesystem descriptor here and there. That's not to say the filesystem would then be invalid, just maybe not as compliant as it could be.

No, it will always prompt. Each time you click that calc/build button it creates a whole new instance of the 'ImageBuilder' class and so it has to be told how to be configured. I'm not even going to attempt to remember every little detail between instances (it's just not worth trying!) - hence it'll prompt each time so problems are limited to user selection rather that incorrect guessing on the programs part. The harder you make things to guess, the more it has to prompt - hence it's easier if you put files in VIDEO_TS folders etc like how they're supposed to be.

Hmm working through the logic, the time taken for the actual burn is the difference between the 'Writing Image...' and 'Synchronising Cache...' log entries. So I make that 6 mins, 6 seconds = 366 seconds. The image is 4,681,463,808 bytes. 4,681,463,808 / 366 = 12,790,884.72 bytes per second. 12,790,884.72 / 1024 = 12,491.09 KB/s 1x DVD write speed = 1,385 KB/s, making this ~9.0x. So give or take a little, the average speed value is actually ok. The code states that the max speed can't be lower than the average speed. For that reason, it gets set to the value of average speed - that's why they're exactly the same number (which would be rare otherwise). Looking at those figures, I honestly have no idea where the issue is right now, sorry!

1 probably came from the 'calculate' bit, the other just before the burn. It's intentional to prompt (well, do everything) twice. There is no 'same session' in ImgBurn, it's ALL the same session and you could easily have changed something between doing a calc and then pressing the 'Write' button.

It does look like the average write rate in the log is wrong. Some internal calculation may have failed and hence it's just using the one of 'max' instead.

The one in the log is averaged over 10 seconds or so, whereas the IBG one is a point sample at 100ms intervals. If you uncheck the 'Averaged' button in DIP, you might see the line start to go slightly mad. Move the 'Shift Sampled Position' sider for extra effect. That could account for the differences. If one sample misses a write of 32 sectors on both ends, the one in the middle may have 64 more. Sampling at that rate means 64 sectors is actually quite a lot and so the speeds can jump around all over the place. I've fixed the IBG upload problem now so feel free to post it. btw, do your screenshots as png file, they look much better than jpg ones.

ok, It's now being set to the value of 'creation date / time'.

Surely this is best asked at a DVD Rebuilder forum?!

How big is the boot bit it extracted? The floppy disc emulation sizes should be obvious. For other stuff, the 'custom' sectors to load is the size of the boot image / 512. I guess I should add a log entry to say what emulation type was used on the original disc if it's from a cd. Never really thought of that