FAQ

Formats

What is RVZ? Dolphin’s modern disc container (introduced 2022, successor to WIA): partition data is stored decrypted with hash exceptions, PRNG junk is packed with a recovered seed, and every table carries SHA-1 checksums. RVZ files are typically smaller than the source formats and decode byte-exactly to the original disc.

What is the difference between RVZ and WIA? WIA is the older container (Purge/Bzip2/LZMA/LZMA2, no Zstd, no junk packing, version compatible 0x00080000). RVZ adds Zstd, chunk packing and the rvz_packed_size field, and drops Purge. RVZSharp reads both and writes both (RvzWriter / WiaWriter).

Can RVZSharp write the legacy formats too? Yes, except NFS: GczWriter (16 KiB zlib blocks by default), CisoWriter (all-zero blocks stored absent), WbfsWriter (Wii only, all-zero clusters share one zero cluster) and TgcWriter (GameCube only, ISO stored verbatim) — also available as convert -f gcz|ciso|wbfs|tgc. NFS is read-only (writing it needs the Wii U ticket/HIF key handling); converting to ISO and back through RVZ/WIA/GCZ is the recommended path for NFS.

Can Dolphin open files created by RVZSharp? The writer mirrors Dolphin’s ConvertToWIAOrRVZ byte-for-byte at the container level (same headers, tables, exception offsets, group layout), so yes — Dolphin should open converted files. Cross-checking with real Dolphin is part of the open validation work.

What are GCZ/CISO/WBFS/TGC/NFS? Legacy GameCube/Wii image formats (compressed GCZ; simple block-compressed CISO/WBI; Wii Backup File System; Tiny GameCube images; encrypted Wii U–era EGGS/NFS images). All are decoded to the same canonical ISO view — see Legacy formats.

Usage

How do I verify a conversion?

rvzsharp decode game.rvz game.iso --sha1 $(sha1sum game.iso | cut -d' ' -f1)

or, for an original source image: compute the SHA-1 of the source ISO once, then use --sha1 on every decode. The suite itself proves byte-exactness via round trips. For Wii discs, rvzsharp verify -i game.rvz --partitions walks the partition hash trees and TMD/H3 tables like Dolphin’s verify tab and reports per-partition problems.

Can I script the CLI? Yes — add --json to convert or verify for one machine-readable object on stdout, use -i - / convert -o - to pipe disc images through stdin/stdout, and generate shell completions with rvzsharp completions bash|zsh|fish|powershell. Logs and progress go to stderr, so stdout stays clean.

Why is WBFS conversion slow? WBFS has a fixed ~9.4 GiB logical size; converting reads the whole logical image even when the file is mostly empty clusters. Prefer decode then convert game.iso.

Can I get the files out of a disc image? Yes — rvzsharp extract (DolphinTool-compatible) lists or extracts the FST tree and the standard system data (boot/BI2/apploader/DOL/FST, Wii disc header/region, ticket/TMD/cert/H3). The library equivalent is DiscFileSystem + PartitionReader. CISO, WBFS and other containers work as inputs because everything decodes to the same disc bytes.

Does decoding use multiple cores? Full-image RVZ/WIA decode does (convert -f iso --threads 0, or CopyTo(..., maxThreads)) — chunks are decompressed on a worker pool and written in order, so the output is byte-identical to sequential. Random-access ReadAt calls stay sequential.

Why does NFS need a content directory? Dolphin treats NFS files as …/content/hif_000000.nfs with the AES key in …/code/htk.bin. RVZSharp follows the same convention; use Blob.Open(stream, nfsKey, …) or the library API to supply the key directly.

Which compression should I use? zstd (default) for most cases; lzma2 for the best ratio on compressible data; none for speed. Levels 1–9 (Zstd −131072..22, like Dolphin’s CLI).

Technical

Does RVZSharp decrypt games? It decrypts partition data with the key found in the image itself purely to re-encode it compactly or to read the file system — the decoded ISO is byte-identical to the original encrypted disc. The ticket stores its title key AES-CBC encrypted with the Wii common key (a public constant also used by Dolphin, not a per-console secret); RVZSharp decrypts it exactly like Dolphin’s TicketReader::GetTitleKey (WiiVolume.GetTitleKey), and RVZ/WIA inputs use the container’s stored key directly. No console-specific keys are used or required.

Why does the junk look periodic every 32 KiB? The padding PRNG’s stream position is defined as offset % 0x8000; junk at any offset is the generator output at that remainder. That’s the format’s definition (Dolphin, the Go reader and RVZSharp all agree), and it’s what makes seed-based packing possible.

What happens if junk detection fails? GetSeed is best-effort: non-PRNG data is stored literally. The output stays fully valid — just less compressed.

Why CSharp_RVZSharp.sln and not .slnx? The repository uses the classic .sln solution format, which the .NET CLI fully supports (dotnet build, dotnet test, dotnet sln add). The slow test project (RVZSharp.Slow.Tests) is intentionally not part of the solution, so solution-level test runs are always fast-only.

How are warnings handled? TreatWarningsAsErrors is enabled — the build must stay at zero warnings.

Where do the format details come from? Dolphin’s C++ source (References/dolphin-master, especially Source/Core/DiscIO/WIABlob.cpp and WIACompression.cpp) is the source of truth; the Go reader (References/rvz-1.0.3) and docs/WiaAndRvz.md are cross-references. See Testing for how the semantics are pinned by tests.