Hello list, I prefer to keep libdvdread as a library that can read all versions of UDF filesystem (Up to 2.60) and ISO files. I find it very unattractive to use multiple libraries, one to test if it is a "VIDEO_TS" style UDF, and if not, use a whole different library to handle this type of UDF device/file. (which also interfaces with libdvdcss and/or libaacs) I decided to take a look at libdvdread again, with regards to reading generic UDF devices and ISO images. libdvdread already could handle DVD UDF levels, and I already did some work to enable higher UDF levels like that of blurays. But it generally mostly worked for images created with ImgBurn, and not always for retail blurays or generic UDF. (Linux mkudffs or OsX Newfs_udf). So, with that in mind I made the following changes: * Proper LogVolume parsing, and scan the defined partitions + Handle Sparing Table + Handle Metadata partition; main, mirror and bitmap locations. * Handle ExtFileInfo 250,251,252 (Metadata; Main file, mirror file and bitmap file) * Fix math to find logic block for FSD, based on FSD for metadata not partition start, and/or influenced by Metadata entry. It no longer "loops" looking/hoping for the right TagID. * Fixed "ICBTag.flags&7 = 3" type, "file content data" is stored at AD! (In the same block) The ICBTag logic in dvdread, for flags type = 3, is completely wrong. But this sort of "data compression", to store content in the actual ExtFileInfo block, is probably not used for media volumes normally. * File location (as opposed to Directory location) are from partition.start, not FSD location. (Of course, for DVDs the FSB is at +0 offset.) * Tested IO export functions to (still) work with libdvdcss and libaacs. Now since dvd_udf.c is nearly "unrecognisable" to the original (although backwards compatible), and our past history, I feel it is probably not worth working with patches any more. Perhaps it is better if I simply spin off my own fork of libdvdread. I'm sure we all agree here. Should I take a new library name, dvdread.plus or dvdreadX or libudfread, something, or just different version strings? Let me know what You think so we can come to something everyone is happy with. Lund Optional TODOs. * If metadata-mail-file fails, use metadata-mirror-file. * Ignores freetable bitmap too, but then, it is a readonly library -- Jorgen Lundman | <lundman@lundman.net> Unix Administrator | +81 (0)3 -5456-2687 ext 1017 (work) Shibuya-ku, Tokyo | +81 (0)90-5578-8500 (cell) Japan | +81 (0)3 -3375-1767 (home)