you're right, I guess I misread his post. So if I understand, there's really no advantages to implementing WDF support in loaders since we already have .wbfs file support?

 

I really don't know anything but what about a tiny space to fake a game's barcode one the disk (or whatever. BCA or something). It would stop MANY anti piracy checks...

 

I have added the member 'bca_data'.

And what's about:
- preferred_ios
- preferred_title
- load_counter

 

No, you don't wbfs backup manager reads rar files and unpacks scrubs and transfers files to HDD.



So, if I'm reading this stuff correctly the wdf file isn't compressed so to speak but yet trimmed of the data that doesn't need read by the Wii ?? Wouldn't that speed up the read times possibly preventing or helping lag in some games ???


Thanks for all the good stuff your putting out there for us.

 

To clear the cISO lack of info a little bit, ... I too was confused by it, and the reason is because there are 2 different cISO formats floating around:
- one is by pismo tech: http://www.pismotechnic.com/ciso/
which supports all kinds of compression and encryption and who knows what more
- the other one used by hermes wbfs_win and wii backup manager and I think nubecoder ncWBFS tool (which uses the extension .wbi instead of .ciso exactly because a different .ciso format already exists)
The two formats are not compatible in any way.
The .ciso format by hermes (not sure if he is the original implementator) is very simple, does not support any kind of compression - only skipping of unused blocks (scrubbing), it's more similar to WDF and WBFS but much simpler, so this format too allows random access and is suitable for direct loading (which uLoader also supports)
Basically cISO by hermes looks like this:

4 bytes: CISO
4 bytes: block size (int32) (usually 4MB)
32k-8bytes: byte map of used blocks
DATA BLOCKS

in other words:

struct ciso_header {
char tag[4];
int32 block_size;
char map[32*1024-8];
};

So, data is 32k aligned and scrubbed.
btw, I looked into how .ciso looks like only recently, since the only place where i could find this info is source code of hermes wbfs_win.

 

WDF is a more refined format... it really SHOULD become widely supported by USB loaders, IMO.

 

I have taken a look into the uloader sources. If extracting from WBFS the block size is the same as "wbfs_sec_sz" (WBFS sector size).

And after analyzing the CISO format I think there is only need for WDF V2 when additional info like BCA should be stored. Without more info CISO is a good container for scrubbed ISOs if the block size is a multiple of 32768 (the wii disc sector size). To keep the mapping table small greater minimal block size or a maximal block number might be required.

 

Is there any USB-loader which is able to use wdf?

 

I know about that, but wia will never be used to load games in usb-loader because of the compression, but i think wdf could be used to load games.

 

I agree mostly.

But WDF was there before WBFS files are used by USB loaders. I developed WDF to save disc space. Since the beginning of wwt/wit I'm using WBFS files instead of WBFS partitions for test purposes. If I remember right some month later oggzees has the idea to use WBFS files with only 1 image for USB loaders.