Jump to content
Sign in to follow this  
var3gen

UDF Version display

Recommended Posts

Hey,

I created an UDF (ISO13346) image like so, with the Linux user space tools package

udftools 1.0.0b2: mkudffs -r 0x150 --lvid=test --media-type=hd --u16 /dev/lofi/1

(This was done on Solaris 9 which has a loopback type file device, think "Daemon Tools" if you like)

 

Now, when I load this image to look at it in ImgBurn 1.3.0.0, the tooltip says

Volume Identifier: test

Application Identifier: Linux mkudffs

Implementation Identifier: Linux UDFFS

UDF Revision: 1.80

 

That "8" is wrong, there's no such thing as UDF rev 1.80. Now, either this is a bug in

mkudffs 1.0.0b2 (I have looked in the sources and see nothing) or it is ImgBurn that

misinterprets what it reads out. I highly suspect that it is ImgBurn, because Solaris support

rev 1.50 (only) when using native tools: mkfs -Fudfs -o label=test /dev/rdsk/c4t0d0s2 [...]

 

If I create a similar image with -r 0x0102 or -r 0x0201 ImgBurn displays what I expect.

But if I choose rev 2.50, i.e. -r 0x0250, ImgBurn displays 2.80 :/

There's something fishy with this 5 vs 8...

 

Cheers,

/M

 

PS. Thans for ImgBurn, great program one needs no other for image burning. Ever.

Share this post


Link to post
Share on other sites

One more thing: I'd be nice if the tooltip info gave correct information on wheter the FS

in the image is Bridge format or not. I.e. if it contains version 1.02 UDF with ISO9960 as well

in "parallel" describing the same FS structure.

 

This would normally be so for all DVD Video, i believe it would also be true for all PS2 DVDs.

Cheers,

 

/M

Share this post


Link to post
Share on other sites
That "8" is wrong, there's no such thing as UDF rev 1.80. Now, either this is a bug in

mkudffs 1.0.0b2 (I have looked in the sources and see nothing) or it is ImgBurn that

Please supply a download link for the software version numbers that are apparently being misreported and I?ll have a play with it.

Share this post


Link to post
Share on other sites

Cheers, I didn't realise that field was written in the format that is it.

 

v1.50 is actually written as 0x0150.

So when I read the '50' byte, I get 80 in decimal - hence where 1.80 came from.

 

I'd not seen any discs other than those using v1.02, which of course doesn't suffer from that problem!

Share this post


Link to post
Share on other sites

Shamus_McFartfinger wrote:

> Please supply a download link for the software version numbers that are apparently being

> misreported and I?ll have a play with it.

 

Hm, I don't understand what you mean. Define "SW version numbers" in your context.

Perhaps you're wondering where to find udftools 1.0.0b2 (or 1.0.0b3 which is the current)?

https://sourceforge.net (just search for it). The b3 is very Linux specific, quite a lot

of code re-write (cleanup) there compared to b2 so even though I got it to build cleanly after

some work, I failed to get it to work on SPARC Solaris 8 and 9 :-( It crashes very early with a

Segmentation Violation no matter what I do... :angry: Oh well.

There are no functional changes between b2 & b3 anyway that I can see, and only the very

odd bug that has been fixed.

 

You might also mean links to ISO-image files containing the different versions of UDF: 1.02, 1.50,

2.00, 2.01, 2.50, 2.60 http://en.wikipedia.org/wiki/Universal_Disk_Format (note the passus about

Bridge Mode in the text there.)

I don't have that, you'll have to create such images yourself -- which is what I did using mkudffs --

and then try them out in ImgBurn.

 

Cheers,

/M

Share this post


Link to post
Share on other sites
Cheers, I didn't realise that field was written in the format that is it.

 

v1.50 is actually written as 0x0150.

So when I read the '50' byte, I get 80 in decimal - hence where 1.80 came from.

 

I'd not seen any discs other than those using v1.02, which of course doesn't suffer from that problem!

 

I suspected as much. You're welcome. :-) Now, all DVDMovie and all PS2 DVD images that I've seen are in 1.02 Bridge Format, i.e. contain an ISO9660 FS as well as UDF 1.02. This is detectable, but I'm afraid I cannot provide you with details on exacly how to program it in ImgBurn. Sorry to be using Solaris 9 (UNIX) examples here, I know you guys are likely MS Windows only but bear with me, these are very basic

 

If I create a test UDF-image like this:

 

1. Create an ordinary file of 100M size called /tmp/test.iso

2. lofiadm -a /tmp/test.iso (this will create a block device called '/dev/lofi/1' pointing to the file)

3. mkudffs -r 0x102 --lvid=test --media-type=hd --u16 /dev/lofi/1

4. mount -Fudfs /dev/lofi/1 /mnt *success* (udfs = ISO13346)

 

If I take an image of any PS2 DVD, which ImgBurn will show as being UDF 1.02:

 

1. lofiadm -a /tmp/killzone.iso

2. mount -Fudfs /dev/lofi/1 /mnt *fail*

3. mount -Fhsfs /dev/lofi/1 /mnt *success* (hsfs = ISO9660)

 

So it sees that the latter image is Bridge Mode, it is mountable as an ISO9660 filsystem and I can access the files. But I cannot mount it as a UDF 1.02 filesystem. It would be very elegant indeed if ImgBurn can show this "Bridge" info as well in that tooltip!

 

Cheers,

/M

Share this post


Link to post
Share on other sites

I've done that too.

 

It now include the text:

 

'File System(s):'

 

and lists them like

 

'File System(s): ISO9660, Joliet, UDF'.

 

Hopefully that's what you were after.... if not, tough because that's what I've done :P

Share this post


Link to post
Share on other sites
Shamus_McFartfinger wrote:

> Please supply a download link for the software version numbers that are apparently being

> misreported and I?ll have a play with it.

 

Hm, I don't understand what you mean. Define "SW version numbers" in your context.

Perhaps you're wondering where to find udftools 1.0.0b2 (or 1.0.0b3 which is the current)?

I know where to find udftools. What I wanted (hence my asking) was a link to the version you were using for 2 reasons. The problem may have been specific to a particular version of udftools or specific to the Solaris compiler. 99% of the bugs reported for ImgBurn are not bugs but problems associated with or caused by other software. As Lightning_UK has acknowledged that it was a bug, it''s immaterial now. :)

Share this post


Link to post
Share on other sites
I've done that too.

It now include the text:

 

'File System(s):'

and lists them like

'File System(s): ISO9660, Joliet, UDF'.

 

Hopefully that's what you were after.... if not, tough because that's what I've done :P

 

Absolutely, that's what I was after. Now if I'm to be *really* picky :ermm: , that information, though 98% correct (see below), is a bit obscure for ppl who don't know or can be bothered to learn, about UDF versions and what FS(s) is actually on a DVD (image). Since DVDMovie (and more) in particular is UDF 1.02 + ISO9660, this is called 'Bridge Mode'. That's why I suggested you use that term.

On the other hand... not many ppl know or would care I suspect, about understanding what 'Bridge 'Mode' really means either...

The way you've done it now is totally fine by me :D

 

One thing though: Since Joliet is not a FS, but rather a non-standard (or de-facto standard) extension to ISO9660, that should be called 'ISO9660 w Joliet'. Compare the UNIX variant, it's still ISO9660 but then it should be called 'ISO9660 w RockRidge'.

 

Cheers,

/M (who never uses nothing but ImgBurn to write to DVD~R [DL] when on a Win32 computer :) )

Edited by var3gen

Share this post


Link to post
Share on other sites
I know where to find udftools. What I wanted (hence my asking) was a link to the version you were using for 2 reasons. The problem may have been specific to a particular version of udftools or specific to the Solaris compiler. 99% of the bugs reported for ImgBurn are not bugs but problems associated with or caused by other software. As Lightning_UK has acknowledged that it was a bug, it''s immaterial now. :)

 

OK I see, fair point. I did state udftools 1.0.0b2 in my 1st post. But I did not state what I used to build it (on Solaris 8), that's true. Nor exactly what I did to make it compile correctly. One has to change stuff in the source code, at least some of the header files and of course this can break things even if the build goes through. And aye, there might be bugs in GCC as well... though 99% of... (a.s.o.) :P

 

With this fix that L.UK. now has done, ImgBurn is even better for me! :w00t:

 

Cheers,

/M

Share this post


Link to post
Share on other sites
:o Someone ELSE fooling around with the Label fields as much as I do?! Oh, my god! It must be the end of the world! :death:

Share this post


Link to post
Share on other sites
Sign in to follow this  

×

Important Information

By using this site, you agree to our Terms of Use.