LIGHTNING UK!

What I'm saying is that you should configure your I/O interface to one that's not installed (basically so no I/O stuff will be initialised). Then see if you still get the error. Then put it back to what it was. btw, is any part of the main window still open when you get this error or is there nothing left on the screen from ImgBurn?

Yeah, there's no reason for a version of ASPI to have any effect on SPTI - or at least not that I know of. Apart from little tools that the cdfreaks people seem to make, nobody uses the 'system wide' aspi now. If you're trying to diagnose problems with someones pc, just tell them to take aspi off! That forceaspi util can be used to remove the relevant files + reg entries.

Without seeing the log (as mentioned above), these are just guesses. 1. You're using Ritek DL media. STOP. 2. Your firmware it old and needs updating. Always use Verbatim DVD+R DL media. If you're already on the latest Sony firmware, try crossflashing to the real LiteOn 1633 version.

That instruction address looks like it's outside of where my programs code would be. Ejecting the disc wouldn't change/breaj anything anyway. Unless you somehow magically modified the exe, reloading it shouldn't do anything. If there is an I/O interface (in the settings) that you DO NOT have installed, select it and then close the program. Reopen + Reclose. Does it still error out? Not that configuration settings should ever cause that sort of problems but at a last attempt, do try and uninstall + reinstall the app. Am I also to assume you're running on Windows 2000 there? or something else? (maybe you just run 16bit colour in XP?)

4.71.2 is quoted (by Adaptec's site) as being ok for XP. However, no up-to-date software should really rely on that now. It only works with IDE and SCSI devices so is useless for people that rely on USB/Firewire for connecting their drives. I don't think ASPI gets listed as a filter driver anyway, it takes its own route to the drive whereby it bypasses everything else.

'no audio data' is a bit of a weird message. I've seen them say 'no disc' etc but not 'no audio'. Does your player support the discs you're using? Have you just tried 1 disc? Did you only save the DTS track or something and your player doesn't support DTS? If you're using DVD+R media, see if your drive supports / is configured for bitsetting to DVDROM. Also check you're using decent media in the first place. Maybe your player just can't read them full stop. If it burns and verifies ok, there is nothing wrong with the actual burn itself, the problem lies elsewhere I'm afraid.

Just to re-iterate, the 500 limit is nothing to do with the number of burns you can make or the number of times the drive can set the booktype on discs. It's the limit on how many times you can change your mind as to whether or not the drive should perform bitsetting - full stop.

Nope, bitsetting is only applicable to DVD+ (plus) format media. Keep clear of DVD-R DL though, they're useless. If you're going to use any double layer discs, go for Verbatim DVD+R DL ones.

Debug mode is for my usage really, not anyone elses. Also, it doesn't log anything during the burn so it wouldn't help anyway! I'm sure unmounting an image shouldn't cause anything odd to happen to the file so I don't know why your buffers were going mad. The write line (yellow) one looks kinda ok to me. The verify is the bit that's all messed up! btw, you need to update your version of DVDInfoPro, you're missing out on new stuff! 4.61.4 is the latest version.

No it won't

ISOBuster is aimed more at file/folder recovery from real drives, whereas I always thought UltraISO was (amongst other things) there for manipulating ISO images.

The image file could have been wrong and you drive may have corrected the data. That or the drive didn't burn properly and so it's not reading properly.

The ISO's taken from the original discs should be the same. The one from the burnt disc might be different if the burning tool changed something during the burn. Also, reading back from a burnt disc will not always produce an image the exact same size as the one you burnt. Drives often round up to the nearest 16 for the overall size of the disc.

One thing I forgot to ask... what was the exact format of this image? Basically, it's the number of sectors in the image and the sector type that I'm after. If you still have the full log of what you posted in your initial post, I need the line above where you copy + paste from. Or you can load the image and just type out what it says on the main screen.

Look at it via ISO Buster.

Verbatim media normally burns fine on all drives... it's the only one that does! Hard to say where the problem lies. Your drive could be faulty or you could have a substandard/fake batch of Verbs. I realise they're expensive and so perhaps you only tried one disc - it might have been a 1 off, so please do try another one at some point!

Read the FAQ, it covers this issue with ASPI.

That's the time reference for the sector. It's in the header part of the full sector, not the data area itself (or in the ecc/edc regions after it). The drive is just correcting it because (as I've now just read), the value should be in BCD, not Decimal. That's why you're seeing one as a hex representation of the other. It's not often my program has to add the header to data and having looked at the code, I think it might be wrong. That said, without knowing the exact details of the image you're loading, I don't know if my programs sector conversion routine is even coming into play! What info does it say on the main screen once you've loaded the image? i.e. what is the sector format / mode. Whatever happens, I'll have a mess around tomorrow morning and if it turns out that my code is wrong, I'll fix it. So anyway, you've nothing to worry about, the disc is fine. * *You said this was a video cd yeah? VCD's contain 2 tracks and ImgBurn can't handle that. It'll burn the whole nrg file as a single track.

Yes, UDF is unicode but DVD Video UDF is not. Even normal UDF does not NEED to be unicode enabled. It's all in the compression byte at the start of the dstring. So yes, UDF 1.02 really is supported but unicode filenames / identifiers are not. Like I said though, unicode is pointless at this stage because the program as a whole just cannot cope with it. There is little sense in going on about it as that fact isn't going to suddenly change overnight! If windows cannot handle the codepage conversion stuff itself, you'll just have to stick with mkisofs or whatever else you use that really does support unicode. Sorry. If/when I get around to ripping the program apart and attempt to make use of those tnt unicode controls + update all existing ansi code, THEN it'll support unicode properly in every place it can. I'm in no real rush to do that as it works fine for the target audience.

I use the Nvidia drivers too (latest nForce4 ones) and have tested quite a few discs for the 'Drives & Media' forum with my new H10N. I've not noticed any weird speed issues as of yet, but I haven't done any DL burns with it on the AMD/NVidia computer yet. The burn I did for this thread was on USB connected to an Intel board/chip. Driver wise, I wouldn't use ASPI/ASAPI at all. If you want to try something other than SPTI, ElbyCDIO or Patin Couffin are the only ones to go for IMO. It wouldn't take 2 secs to stick CloneDVD or something on so that you can test them. It's probably worth giving it a shot, you've nothing to lose! You could try the cdrom class thing, all that basically does is tell the program to seach for drives via drive letters (i.e. C:, D:, E:.....Z:) rather than CdRom1, CdRom2....CdRomX. Maybe that accesses the devices at a different level, I really have no idea, sorry!

No, it really is with your burner. The 'send cue sheet' bit is actually a command you send to the drive. It's that which is failing. Something in the data I'm sending is not supported by your drive and so it's bombing out. You're correct though, bin and cue file aren't really supported. However, that doesn't mean they wont work if the bin is just a simple (single track/single session) image. It's just complex bin/cue files that the program cannot handle - i.e. audio or audio+data where you'd then have multiple sessions and tracks.

Glad to hear you sorted it out

Looks like you have a very old burner there and it just doesn't follow the MMC specs like how the newer ones do. There's not much I can do with this I'm afraid as the only way for me to fix it would be to have access to one of those drives.

Nah, it wasn't saving anything, I'd just used a flag in the 'open' dialog box routine that caused the box to not allow read only files. (probably a cut + paste error from a 'save' dialog box). If you drag + drop the ISO onto the 'Source' groupbox, it would load them ok.

It's all Ansi, none of the controls or dialog boxes are unicode enabled so there's no real way of getting unicode text into the program anyway. As for codepage conversions, that's something you'd probably know a lot more about than I would. I'm English (UK) and it's written for similar folk. I've made no real attempt to get away from that and make it work for non english people.