Support for the RVZ file format.

[laetemn]

Add support for the RVZ file format used by the dolphin emulator.

Check if it is possible (and necessary) to add support for this file format.

Information about the RVZ format: https://github.com/dolphin-emu/dolphin/blob/master/docs/WiaAndRvz.md

[sjohnson1021]

Was looking at this myself, also looking at reversing GCIT and doing scrubbing natively.

[laetemn]

The inclusion of support for RVZ files may be added in the future when the program is rewritten for WPF or even MAUI (seems to be more interesting and cross-platform).

Was looking at this myself, also looking at reversing GCIT and doing scrubbing natively.

Regarding GCIT, if we can get the source code of the program from the original developer (FIG / FIG2k4), it would be great. Regardless, I have source codes from other programs that do exactly the same as GCIT, however, they are written in C/C++.

[jmynes]

.nkit.gcz format (older) would also be appreciated, if RVZ is not yet possible at this time. https://wiki.gbatemp.net/wiki/NKit/NKitFormat

It seems that .nkit.iso works, but there are often substantial filesize differences, as shown below:

[sjohnson1021]

@hardlevel Feel free to chime in here as well.

So this is going to happen. It's just going to take.. well. a lot.. and.. doing it.. There will be headaches along the way I'm sure.

This is a pretty commonly requested feature, and one that I'd like to see as well. Looking up resources, and making a test-app as a development playground so I can break things freely and hopefully come out of the rubble with a diamond.. I'll settle for it just working though.

Let's get this conversation headed in a meaningful direction, and get some plans laid out, or at least a clear vision of what we would like to see accomplished?

Like, currently we have:

• 1:1
• • Lossless direct copy of the file, with the exception of being renamed. Data remains untouched.
• • • Produces .iso file
• Scrub
• • Removes garbage data and leaves the rest of the ISO intact, which preserves compatibility with both Dolphin and the original GameCube / Wii hardware
• • • Produces reduced size .iso file

If we are looking at Nkit. NKit Format images contain the bare minimum of data. All junk and scrubbing is removed. Non-uniform (NonJunk) data is preserved in 256 byte blocks with a 4 byte header. Wii encryption and hashes are fully recreatable and removed. Meaning any remaining data is as compressible as possible. We also have:

• Nkit Raw
• • Same as compacted GameCube iso
• • • Produces .nkit.iso file
• Nkit Compressed
• • Compresses the image into a block seekable compression format developed by the Dolphin team.
• • • Produces .nkit.gcz

Are We looking basically to be able to recreate gcit? .. while. .. using gcit? Should I look into how hard it would be to also tack on implementing native scrubbing functionality and ditch gcit?

That aside, If we are going to support .nkit.gcz, is that going to be a one way trip or .. ideally you would want to also be able to revert back? Just in case.. ... actually no, I have no clue why you'd want larger files, but.. hey.

Currently slapping together a rough test UX, but still kinda want to make it .. presentable , and not just garbage to be discarded. Not to mention MAUI's structure and patterns are going to take a minute to get acquainted with. And then finally there is learning from essentially 0 past experience with compression or small-scale file structure ( structure within a single file, or custom extensions, etc.).

Yeah.. It's going to be fun... Wouldn't do it If I didn't love doing it though. 👍