LIGHTNING UK!

If you've never seen 'Father Ted' you probably wouldn't 'get' that one

Most people that visit this place do so in order to get an answer to a question - when they've got it they vanish. I'm not going to put my foot down for people that are here one day and gone the next. If the regular posters (i.e. me and the beta team) start complaining, that's when I'll put a stop to it. It's not like the images are hardcore porn, it's only what they'd see at any beach on holiday.

How you have the options set depends on how you like to work. If you want all the CUE's in one folder and the audio files in another, you need the preserve full pathnames option ticked or it won't be able to find the files (it only looks in the current folder for them). If you want to burn the CUE straight away, yes add it to the queue via the appropriate checkbox. Skipping is where the player can't read the disc. The only way to get away from that is to use decent media. Taiyo Yuden probably make the best CD's. They're all I ever use. btw if your discs are coming out blank, make sure you don't have the 'Test Mode' option ticked in the main window.

Does it play in the PC via media player?

You can't interrupt it, ImgBurn isn't actually doing anything. It's just asking the drive 'Are you done yet?' every second and yours is saying 'No' with the reason being 'Logical Unit not ready, Long Write in progress'. At this point (after 15 mins on a CD-R) you should probably remove the power from the PC to turn it off by force. Try the KPEY firmware update from here too: http://forum.rpc1.org/dl_firmware.php?download_id=2008

Put it this way, if it doesn't work, it won't be anything to do with ImgBurn. Your drive is fine. Make sure the firmware on it is up-to-date and that you're using decent quality double layer discs - which basically means Verbatim 2.4x DVD+R DL (MKM-001-00 dye) made in Singapore.

That's the thing, there aren't any physical errors on the disc. The program is just telling you that the content in those sectors doesn't match what's in the image file. If DVD43 is messing things up, disable it and see if the errors go away. If the errors move each time you verify then it's probably ram corruption.

Bad sectors would normally cause the drive to error out - yours isn't. Miscompares are generally where a program is modifying the data on-the-fly or you're suffering from corruption due to bad/overclocked ram.

If you're working from an image file I've no idea why one would work when the other doesn't. Compare the state of the disc (via the disc info window) before and after burning with each program. Are they the same? Booktype doesn't apply to BD media.

Well no matter how much data you supply, the program can't write part of a sector so either the PCM data ends perfectly at byte 2351 or it ends before it and the rest are left as zeroes. I don't really know about the whole taking data from other tracks thing... it seems kinda wrong to me. Do you plan to implement something like that? I'm on it right now Oh and I'd never include the filters in with ImgBurn. That's VERY messy.

If you convert to WAV then the gaps aren't added by ImgBurn - the decoded size should be a perfect match to what DS had estimated. I don't know all the in's and out's of audio but if the size isn't a multiple of 2352 (the sector size) then there's always going to be some 'zero' bytes inserted. I guess you're right though, the only way to get a 100% accurate size is to ignore the size reported by DS and do a dummy decoding process.

It doesn't cover the build mode options in the main window though donta... I had to check for myself earlier! lol Maybe we can convince Cynthia to go over those too That said, I'm sure it's been covered somewhere on the forum.

It's deffo a drive thing. Once the 'format' command has been sent to the drive, all ImgBurn does is poll it (via 'Test Unit Ready' and alike) to see when it's done. It's not doing any 'work', just playing a kid in the back seat of a car asking 'are we nearly there yet?' If the polling commands don't get back a typical response - i.e. 'Long Write in progress', it throws up the 'Potential WaitImmediateIO Deferred Error' message with the error the drive reported - in this case' Session Fixation Error'. The errors are 110% out of the software's control. It's purely a drive/firmware/media thing. Nero doesn't wait for the format to finish, that's why the 'Formatted' status is left in limbo. I default to making ImgBurn wait until it's completely done.

It's an easy mistake to make

Why not post the actual error so we can take a look for you?

It's already on high.

You must have 'Preserve Full Pathnames' checked.

I can't think why that would be the case. The slowest part of a PC is the drives I/O throughput and that's not going to change, CPU usage is normally quite low - although I'm not exactly testing it on such an old PC to check. I'd be interest to see what your CPU % usage is during burning on that machine with each version. There's a thread that does all the reading within the program and it should be running as quickly as the drive will allow for. At the end of the day, if the buffer empties out it's because the program can't read from your hdd quickly enough.

The command specs are there for a reason, these things aren't media specific. If the ImgBurn format fails then your drive has the issue with the disc, not the program itself. You might not want to believe that or understand it, but it's true.

Just google 'cue files'. As I've said twice already, the extension you give the file containing the actual data is neither here nor there. cue/bin is probably THE format for CD images - but it doesn't make any difference if it's cue/img or cue/iso... they're all the same thing really. If you don't trust your drive, buy a new one. They're only about

It's impossible to say which is more accurate, you've only included the 2 examples. Use the 'Media Information' screen to repeat the test a few more times. Having said that, the others have a 2 second gap so I would guess the first should be 2 seconds too. Within the program there's no difference between the file extensions - the cue should be the same (allowing for the drive to mess things up). Hell, you could call it *.george for all it cares.

It doesn't matter which file extension you use, the content and CUE should be the same for both. You've just got a different pregap size in track 2 there, that's all. Did you read the disc in the same drive? It's odd that it should return such different info - a few sectors/frames, maybe... but not that much. There's nothing unusual about having some audio tracks after the data one on a game. It'll just be the in-game music.

If you save the CUE file outside of the folder with the songs in it the program should automatically include full pathnames to the files. If you move it manually that'll obviously cause a problem where it can't find them full stop. If the full path name includes unicode characters you'll run into the problem where it won't be able to open the files. If you have no intention of using the CUE file in other programs you can tell ImgBurn to always save in unicode format via the settings window.

Maybe you just had a bad disc? Try another one. Try upping the speed to 4x - the drive might like that more. Where were your Verbatims made ? (look on the packaging) The ones from Singapore are the good ones. The ones from India are said to be inferior.

Care to go into more detail? Where will it not find the tracks? If it's after you've created your CUE and are loading it up again, it's probably because it's a unicode character. The program defaults to saving the CUE in ANSI format as that's all some programs (not ImgBurn though) will read.