PDA

View Full Version : Verify prob w/ ImgBurn 1.2.0.0 and UDF images + best I/O interface


DARcode
28th February 2006, 18:41
Just after cycling the tray and right before beginning the verify operation ImgBurn 1.2.0.0 gives me a warning about a possible UDF file system error (see below attached example) with all UDF and ISO/UDF images, never happened with version 1.1.0.0, anybody knows what's up please?

Also, what's the best I/O interface to use with this brilliant tool please?

Thanks.

Dc

LIGHTNING UK!
28th February 2006, 23:56
It's a new thing, that's why you didn't get it with 1.1.0.0

(People never seem to think that when reporting things they've never seen before... I can't understand why not?!)

ALL your images give that error? What program do you use to build them?

'Application Identifier' in the log during a burn would probably tell you.

That error should be quite self explanatory. Either the file is supposed to be 500mb in size or it's 1.6gb. You just need to say which it is. It's used to pinpoint which file an error is in - if it happens to find an error of course!

It's caused by some odd UDF image building programs that either fill out the file descriptors incorrectly (where the size is then wrong / illegal), or they add some weird flag to them. It's hard to tell which is which, so that's why you get the box come up - you make the decision rather than me guessing.

If you made the image, hopefully you'd remember if you added a 1.6gb file to it.

The 'best' is generally the default value. All the testing gets done with SPTI.

DARcode
1st March 2006, 02:18
Thanks for your reply.

It's a new thing, that's why you didn't get it with 1.1.0.0
(People never seem to think that when reporting things they've never seen before... I can't understand why not?!)
Couldn't spot it in the changelog so I didn't know it was a new thing, anyway I thought mentioning the last version which doesn't seem affacted by the strange behaviour could've helped, merely trying to provide as much useful info as possible to experts (or authors in your case) willing to help me.

ALL your images give that error? What program do you use to build them?
'Application Identifier' in the log during a burn would probably tell you.Nope, only patched/modded PS2 ones created with Sony CD/DVD-ROM Generator 1.20.

That error should be quite self explanatory. Either the file is supposed to be 500mb in size or it's 1.6gb. You just need to say which it is. It's used to pinpoint which file an error is in - if it happens to find an error of course!
It's caused by some odd UDF image building programs that either fill out the file descriptors incorrectly (where the size is then wrong / illegal), or they add some weird flag to them. It's hard to tell which is which, so that's why you get the box come up - you make the decision rather than me guessing.
If you made the image, hopefully you'd remember if you added a 1.6gb file to it.I'm still a bit confused: the warning pops up at the beginning of the verify operation though not during the write one, does it make sense?
Also the Specified Size is nowhere to be found in the image or on the disc, checked with both IsoBuster and UltraISO and they all report the Corrected Size only.

The 'best' is generally the default value. All the testing gets done with SPTI.Got it, thanks.

LIGHTNING UK!
1st March 2006, 23:46
Well it's pretty weird you see.

File descriptors (extents or whatever they call them) in the UDF file system are supposed to only use 30 bits out of a possible 32 for saying how big a file is.

As such, the largest number you can have is 1073741823 - i.e. ~1GB
(With 32 bits, the largest is 4294967295 i.e. ~4GB)

If the file is bigger than that, they're supposed to use another extent and the values are added together.

Your file is making use of the full 32 and that goes against the specs.

There are cases where bit 31 could well be set to a '1' (in binary terms) and so that's why I had to offer a choice, rather than just assuming the file is making use of the full 32 bits, or just 30 with the flag set for bit 31.

Here is the definition of the 'Extent Length' field from the UDF specs:

Maximum Extent Length shall be 230 – 1 rounded down to the nearest integral multiple of the Logical Block Size.
Maximum Extent Length for extents in virtual space shall be
the Logical Block Size.

So basically, that image formatting program is faulty and should be fixed.

Oh and the reason it pops up during the verify bit is because that's when the program needs to know where the files start / end. It doesn't need that info during the burn and so the ISO/UDF parsing code is not called at that stage.

DARcode
2nd March 2006, 09:32
Thanks a lot for the info and help.

One last pesky question: regardless if I choose Specified or Corrected Size the verify operation always ends successfully, is that correct?

LIGHTNING UK!
2nd March 2006, 20:56
Yup.

The image is compared sector by sector to that of the disc - it doesn't compare the files as files, it knows only sectors.

The only time it works with the file data gathered by the 'parsing' code (the bit you're getting that box from) is when there IS an error on the disc and ImgBurn tells you which LBA address the error was at, and which file that LBA belongs to.

So basically, in your case, the contents of the disc match what's in the image file (as you would expect). The UDF filesystem error present in the image file is also now present on the disc.
You have no errors and (subject to a PIPO scan ;-)) have a good burn.

To show this specified/corrected file size problem in an example, imagine the following:

File in UDF Filesystem with a basic version of your error:

FileName: Hello.txt
File Start LBA: 0
File Length: 20 sectors (real size)

But oh no, there seems to be an error and it's only showing up as 10 sectors (call that the specified size).

So if you get an error at sector 12, going by the specified size of the file, it's not part of 'Hello.txt'.
If you go by the real size, it IS in hello.txt.

That's really all that question is trying to find out. It needs to know the real size so it can pinpoint which file any potential errors are in.

DARcode
3rd March 2006, 08:57
:goodpost: Thanks a bunch m8 :thanks: !

Gonna donate on your site this weekend :) .

DARcode
6th March 2006, 20:35
Just donated :) .

LIGHTNING UK!
7th March 2006, 00:30
Yup, I just noticed... Thank you :)