Separate names with a comma.
Discussion in 'Wii - Hacking' started by Wiimm, Aug 27, 2010.
Thanx to giantpune for the crash course ...
I didn't mean to be that glib, but I kinda had to point out that shrinking the buffers just creates new problems
I'm not sure it's worth even bothering thinking about until someone actually makes a CIOS that loads WIA files. I'm assuming most disc partitions end up with only 2 entries in the map: the stuff at the beginning of the partition (header, fst, dol) and the stuff at the end (all the data)? Simply implementing supporting a plain old WIA file would provide what should be a small space saving (1/32nd) and let people use the exact same format for USB loading and archival with whatever compression they like. You should see if people will get on board with that before worrying about a more complicated format that relies on testing the limits of the ARM processor/IOS memory space.
We talk about saving 20-40 percent disc space for a usb loader compatible and complex format. The loading time increases and the developers have to spend much time in this project. On the other side hard drives becomes larger and larger and cheaper and cheaper.
The advantage is minimal and only pirates with multiple hundreds of games have a real advantage, because they can store all 1000 games on 1 hard drive.
My question: Is it all worth it?
(This includes the already ready WIA)
i like it mainly as a conceptual problem, and it could become the new standard for images.
yes, it'd primarily benefit pirates, but what doesn't?
DIOS MIOS! Good thing I have 28+ real GC discs.
Tomorrow should start the open beta of DIOS MIOS.
Nice. So now, here's what i think makes sense(yes fstfix is very close to that already...):
- Align all files by 32KB within the .iso. This is a requirement for audio streams, if an audio stream is not aligned at 32KB, then the game will most likely crash when trying to play the stream. .adp files should always be audio streams, but .trk and .snd can be audio streams too. Just to be sure align all files by 32KB and everything will work. For disc loading with NeoGamma aligning all files at least at 2KB results in a better read speed as it's only able to read sectors directly, so 32KB for everything is good for this too.
- Shrink .isos. GC .isos can have any size, so it should be possible to move all data to the beginning and just cut the .iso.(that's what i think all other shrinkers do)
- Expand .iso size for optimised reads for disc loading. There you some different options would be nice, optimised for 1/2/3 games on disc. If a single game would have a .iso with 4.37 GB and all the data is at the end, the reads are faster than a 1:1 copy.
- Optional: Check if the file is fragmented. SD-Boot requires that .isos are in one fragment.
Well extract/replace files is also nice, but the above is what i think most people will need. Well that is if you want to write this at all, i don't want to push you or something.
Loading a GC multiboot disc doesn't always work with softmods, right?
All commands (DUMP, LIST, COPY, DIFF, EDIT, MOVE, RENAME, EXTRACT, FILES, ...) works with gamecube discs and only for some I need minimal changes and a little bit fine tuning. That means, extracting, patching, scrubbing ans converting into WDF, CISO or WBFS (but not WIA) is available. Adding to a WBFS partition is also possible.
For your aligning I have to implement a relocation module into the wiidisc module. This will take a while.
P.S.: Beta version comes tomorrow.
September's a long month. Keep in mind he never gave a specific date.
Please don't make tools that create something else than .iso file for gamecube games. Gamecube games are not encrypted, and there are no hashes to throw away, so if you shrink the .iso, it's nearly as small as possible(32KB alignment increases the size a little). And .iso files can just be burned, put into multi game discs, using existing tools, or can be played via SD-Boot. If you see any advantage in another format for gamecube games, please take you time and make it one format that does everything you want. Also if you create .wbfs files, people will bug around why the games don't work in their usb loaders.
PS: You don't have any relocation tool yet? Hmm, it would be nice if you could do something like this:
join game.iso foldername
And this overwrites all files in game.iso with files it finds in foldername. If there's no matching file the folder, it takes the file from the .iso. And since the sizes can be different, it relocates all files of course. I don't know if wii games have any specific requirements for alignment, so 2KB* as default and 32KB as optional alignment would sound good to me. Maybe that's why file replacment doesn't always work with current tools?
*Backup loaders that use discs use the dvd video read command, which should only be able to read sectors, so the aligment should be at least 2KB
PPS: When relocating files in wii .isos then of couse make sure the "hole" is at the beginning of the disc. And yes, i will try to think first, and then write next time.
WDF, WBFS, CISO and WIA are only containers (like tar or zip). They are handled in the file layer of my tools. The commands don't see the details and read from/write to the virtual file. So support for all formats is automatically available (WIA needs only a little extension).
Please continue the GameCube discussion here: WIT (Wiimms ISO Tools) GameCube disc support
Just want to say thanks to Wiimm for the hard work. ANY ANY development at all for the WII (heaven forbid new effective containers and compressions schemes) should be treasured and appreciated to the nth degree. Thanks
Thanks for releasing wit with WIA support. What are your plans with that format. When do you think it is stable and will not be changed?
Do you plan a support for WIA in usb-loaders?
i was stupid and accidentally installed 4.3U!!!! when i try to run WAD Manager 1.7 my wiimote goes off, when it gets to nand device (disable)
i dont know whats wrong.... and also usb loader wont even come up when i click on it
WIA is only an backup archive format. USB loaders will never support it because of the complex data structure.
EDIT: forgotten stable answer:
I think is is already stable. I'm waiting for test with a big endian machine to declare it as stable.
You are off topic here. Don't expect an answer.
The test with a big endian machine are positive. It seems that the current format is the final one. In the next days I start a script to convert to wia and back and compare if there are no differences. I will post the bash script if it is ok.
Ok so do you think it is ready to start backup my wbfs-drive with WIA?
I think "yes" but I say "no" until I have finished my (long time) tests.