LIGHTNING UK!

If it's just empty space at the end of the ifo anyway, I can't see as it's all that important. So long as the real size matches what the IFO's say (i.e. if it's 32k, the ifo says it's 16 sectors), that should be all that matters. It looks to me as though the IFO tools are just wiping out the empty space at the end.

No offence but they've all been suggested before, all been answered before! 1. Maybe one day. 2. Eventually. 3. Same as above. I doubt there are really all that many discs these days that make use of multiple tracks. It's basically just for CDDA and even then, a lot of people have moved over to MP3's in a standard data disc. I don't think I'd even bother with it but I'd like to get VCD/SVCD's working properly and they require 2 tracks. Basic bin/cue files (where the bin is really just 1 session/track) can be burnt anyway. Just ignore that the cue is there.

Whilst funny (on some level), replies like that won't help you! You have some good ideas Defenestration, it's just shame you rub everyone up the wrong way by going on and on and on and on. As you've been told before, if you want a tool to do exactly what you want it to and how you want it to, write it yourself. I have no problem adding things if I (we) can see they'd be useful to anyone other than just yourself. I think my first post said everything it needed to regarding this suggestion - use the 'Modified' column to sort them into order.

Sorry, I've fixed it but it hasn't been released yet! That will happen this weekend.

Oh, I thought the LG one WAS official now. I downloaded that one too (ages ago), but I don't remember exactly where the file linked back to.

No v2.0.0.0 has this fix, it's only in the betas. Well if the problem is not what blu and I have been talking about, it's not something ImgBurn would/should really fix. If your input files are wrong, they're wrong! You'd have to blame that on whatever made them in the first place. I could implement some basic checking but then it could easily get out of control and I'd soon find myself attempting to do the same job pgcedit does - which of course is not the idea of ImgBurn. Yes you should stick with PgcEdit until I release the fix if you're doing images that require padding. Oh and about changing size to match other sizes... I'd change the data in the IFO to match the physical size of the file. Your IFO processing tools are probably correct in the way they change the size to match the ifo data. We're just attacking problems from different angles.

Well it's been an ongoing thing since dvd dec days and since you're not the first / only person to mention it, I figured what the hell! It was more important to stop the OS butting in back in dvd dec days because we'd both be trying to parse the filesystem at the same time. That made it take ages and occassionally even fail. As ImgBurn doesn't have to deal with that, I see no problem on just disabling it when it really needs to.

It is from hitachi, as you mentioned earlier. I just found it over at cdfreaks and put it on for testing on another reported problem.

Sorry, no. It's burning tool, not a shrinking one.

Yeah that's how it is now. value at 0x0c is just last lba in bup - first lba of ifo. I believe that was was already ok. For Last Sector of VMGI, I'd taken sectors in IFO (-1) and added amount of padding (in sectors) applied to BUP. I honestly have no idea why! lol As it's normally 0 unless there's no VOBs or a small VOB, it's not a problem that occurs every time you build. Oh and I don't always remember everything - again I'm only human - when that happens I just look on mpucoders site!

It's all part of the fix vts sectors bit of code. I have to update 0x0C offset for end of BUP, I then just updated this one too for good measure - the two seem to go hand in hand. I made a mistake and calculated it all wrong. Silly me! I guess I am only human after all

I did notice you're burning via some other program, unless you're actually manually setting the layerbreak position in the settings - is that correct? Just wondering if you get the same problem loading the ISO manually in the program. I (nor any othe beta team) have reproduced this error so it's tricky to fix. Code wise, everything looks as it should do. If you can find v1.3 on the web, try that version and see if it does the same thing. (You'd have to test it a few times to be sure it wasn't fluke!)

I know we posted at the same time blu but this is one of the bugs fixed in the betas you're now using.

I think this is the same problem mentioned in the 'bugs' forum. Namely, incorrect (or in my case, very weird!) calcualtion of IFO size, as then written to offset 0x1C in VIDEO_TS.IFO / BUP. It wouldn't matter if you had run the files through PgcEdit. If the 32k padding comes into play, ImgBurn would change stuff and put the wrong value in the IFO.

Maybe one day, there are certain things beyond my control that need to be considered though.

1. Fixed. 2. You can now use the '|' character to seperate multiple entries (files/folders). 3. I've added a /rootfolder cli command for this purpose.

Your JL11 is supposed to have updated strategies in it I believe. Perhaps one of those 'updates' messed it up?!

Ok, it might be wm_quit instead then! anyway, now that you've gone to all that trouble, I've gone and added a /closeinfo cli switch that will close the app down once the info has been written to the file. You are of course free to continue using the alt+f4 method if you so wish

-R has always been more compatible with players. I doubt you'd find one now that can't read them. btw, did you say all your ricoh discs have this error in the middle of the burn/verify? I've burnt that same dye on mine and never had a problem - that I can recall. I am using the JJ11 firmware on mine though, not the other one. http://forum.imgburn.com/index.php?s=&...ost&p=19071

1. Although the documentation appears to be wrong, it is actually correct! The path without the trailing backslash is passing the CLI parsing code ok because it looks like a file. The folder is blocked (well, ignored) because it's failing some other check. I'll fix that. 2. No, sorry. 3. No, sorry. There is now (ready for next release), but only for gui purposes. If you set it in advance, even when you load ImgBurn with CLI parameters it'll still use that value. I guess I could add an extra cli switch now though and I'm sure that would be the better way of doing it.

You probably have to get the right window handle, I'm sure it should work... not that I've tested it of course! Borland apps have hidden main windows so you may need to send it to that one - or vice versa if that's what you're doing already. Also, try it with a delay after finding that the info file exists - incase it's busy with other stuff and so I'm not letting it close.

I've had a little mess around with where the 'Disable MCN' stuff kicks in, and basically moved it to the places that count rather than being active from the second the program is loaded. So now it just disables it during write/verify/erase. Once re-enabled at the end of a burn/verify/erase, I also refresh then drive handle (close / reopen). That makes Windows spring into action and read the drive - hence refreshing it properly. This all happens just before you click the 'ok' button to the 'operation successfully completed' messagebox. It all seems to work ok on my pc, now to let the beta team have a little play.

HDD Tools could benchmark it db! If you get over ~1mb/s, it's running usb 2.0 hi-speed.

I would prefer to read the log without the debug info, it doesn't actually 'add' anything here and infact means I miss other bits I want to read. It's very odd that the entire program locks up... that 'waiting' is done inside a thread and so would have no effect on the GUI at all. Out of interest, are you able to cancel a burn without this problem? Try it on a -RW/+RW, or use 'Test Mode' on -R media. Just set it burning and then stop/cancel it after a minute or so.

Not during the burn it won't and so it's pretty pointless in this situation.