var3gen

That's what I thought when I tested it today with some images I have. Good, that's that confirmed once and for all. If you say so. Not sure what this really means, but fair enough. OK. There already are such freeware tools for Win32 (Open Source), cdrtools (works very well under cygwin) and cdrdao are the ones that spring to mind. They've existed for >5 years, being able to read and write sub-chan data. The only drawback(?) with those is that Win32 GUIs for them are scarce, if not non-existant... I'd agree with this. Multitrack usually implies CD-DA tracks on the CD. I don't see why you'd have to do anything special with MP3 -- unless you mean that you'd have to decode MP3 files into a DA stream for burning a CD-DA from .mp3-files? If so, I'd call that a can of worms alright, but I'd not do that ever if I were you, the motive more or less being "it's simply not required for the type of reading/writing ImgBurn is aimed at" Thanks again for an excellent program, I use it all the time and there are two people at the top of my list of trustworthy SW authors in this area: you and J?rg Schilling. Now, before all you ppl here in this forum start flaming me for even mentioning his name: he writes good code that works and he maintains it properly -- whatever else I might think of him. Right, I'll send some money (again ) via Paypal very soon Cheers, /M

Thanks for 2.2.0.0 this is really an excellent program. I think I shall donate again... done it twice so far, at release of new version One thing though about ISO Read Mode and CD's. It seems that what ImgBurn does, is default to a raw sector reading method which creates an image usually called MODE[12]/FORM1/2352 (the last figure being the no of bytes in each sector read). But I haven't seen anything anywhere in the program or here in the forum about sub-channel data. If that is read as well, the result should be a (example) MODE2/FORM1/2448 image -- that would be for reading raw or packed R-W sub-chan data. ImgBurn can parse and then write (burn) such an image no prob, but it doesn't seem to be able to create one at all. Not all drives can read sub-chan data, or can only read it in packed form (de-interleaved and error corrected) but many can. Yes, I'm aware that not that many CD writers allow 100% SW control over raw sub-channel data creation, but still... I'm guessing that ImgBurn 2.2.0.0 does not bother with sub-chan data in write mode either at all. When will it, if ever? Also, it would be good if it did support multi-track CD's in Read Mode. Multi session is pretty unnecessary though IMO. What are the plans here, if any? Cheers, /M

Right. Fair enough, I'll use UltraISO then... I have it, just not installed it yet. I suppose the purpose of DT is slightly different, it's meant to be an aid/tool for playing games 100% from HD with the images of CD's (& DVDs?) being put as files there. I guess the author(s) feel no need or point in that context to have antything RW... Cheers, /M

I saw this recommendation to mount the image via Daemon Tools before and tried it. It didn't work because PGCEdit needs to modify the source files (IFO/BUP anyway), and it cannot do that with a virtual DVD-ROM because it is read-only. Is it really true that there is no way to use Daemon Tools to mount an ISO13364 (UDF) image file RW? That's a grave dissapointment for me, since it is a very useful thing. (Though not for DVDMovie in connection with Layer Break issues, I know that.) Very easy to do on Linux or Solaris, with built-in support for loop-back mounting udfs. I was planning to get and install the lastest Daemon Tools on my Win XP at home to be able to do stuff like that on that computer as well, but then I should perhaps go look elsewhere for this functionality?? Grmpf. /M

> THERE CAN BE ONLY ONE Heh, I'm a clone... 8-) /Smith

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.) With this fix that L.UK. now has done, ImgBurn is even better for me! Cheers, /M

Absolutely, that's what I was after. Now if I'm to be *really* picky , 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 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 )

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

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... 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

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

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.