# 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](format/legacy.md).

## Usage

**How do I verify a conversion?**
```bash
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](testing.md) for how the semantics are pinned by tests.