WDF = Wii Disc File
Wii ISO images has a size of about 4.4 GiB, but much space is unused and have to be filled with zeros. Some games need less than 100 MiB and that means about 4.3 GiB waste. The linux ext2/3 file system can handle such files very good because it do not allocate disc space for such (zero-)holes. Such files called "sparse files".
For me there is no need to store Wii ISO images in the old way filled with zeros. And the handling with large sparse files is not effective and needs always special options like 'ls -s' or 'cp --sparse=always'. Also it costs much time because the holes have to be scanned again.
One way is to compress the data. But compressing works only for the holes but not for the crypt data. And random access (needed by the WBFS framework) is very difficult for compressed data. The direct support of holes seems to be much better.
Because of this all I have defined a new file format, the WDF format. There are some main issue for me:[*] The WDF format should handles holes effectively to save disk space.[*] It should support splitted files because small files can sometimes be handled more effectively than whole large files.[*] There must be a WBFS tool to handle this kind of files. I have already implemented the WDF support im my 'WWT' (Wiimms WBFS Tool). The WWT package contains some more tools to handle WBFS.[*] Other WBFS manager should support the WDF too. And this means that the implementation must be done by the well known wrapper functions 'rw_sector_callback_t' and 'read_wiidisc_callback_t'. That makes transfering the code very easy.I have already implemented this (but not splitted WDF) in my WWT tools and it works fine. The tools are:
CODE---------------------------------------------------------------------
id6 image size WDF size % name of disc
---------------------------------------------------------------------
RTYP01 4482 MiB 27 MiB
Wii ISO images has a size of about 4.4 GiB, but much space is unused and have to be filled with zeros. Some games need less than 100 MiB and that means about 4.3 GiB waste. The linux ext2/3 file system can handle such files very good because it do not allocate disc space for such (zero-)holes. Such files called "sparse files".
For me there is no need to store Wii ISO images in the old way filled with zeros. And the handling with large sparse files is not effective and needs always special options like 'ls -s' or 'cp --sparse=always'. Also it costs much time because the holes have to be scanned again.
One way is to compress the data. But compressing works only for the holes but not for the crypt data. And random access (needed by the WBFS framework) is very difficult for compressed data. The direct support of holes seems to be much better.
Because of this all I have defined a new file format, the WDF format. There are some main issue for me:[*] The WDF format should handles holes effectively to save disk space.[*] It should support splitted files because small files can sometimes be handled more effectively than whole large files.[*] There must be a WBFS tool to handle this kind of files. I have already implemented the WDF support im my 'WWT' (Wiimms WBFS Tool). The WWT package contains some more tools to handle WBFS.[*] Other WBFS manager should support the WDF too. And this means that the implementation must be done by the well known wrapper functions 'rw_sector_callback_t' and 'read_wiidisc_callback_t'. That makes transfering the code very easy.I have already implemented this (but not splitted WDF) in my WWT tools and it works fine. The tools are:
- 'wwt' is a general WBFS manager that may import WDF files directly to a WBFS and may export discs from WBFS directly to WDF files.
- 'wdf-dump' dumps the data structure of a WDF file.
- 'iso2wdf' converts ISO images into WDF files.
- 'wdf2iso' converts WDF files into ISO images.
- 'wdf-cat' is a 'cat' like program with special handling of WDF.
CODE---------------------------------------------------------------------
id6 image size WDF size % name of disc
---------------------------------------------------------------------
RTYP01 4482 MiB 27 MiB