Dolphin Introduces RVZ as a Lossless, Emulation-Ready Disc Format

On July 5, 2020, the Dolphin project detailed support for WIA and its new RVZ format in development build 5.0-12188. RVZ was designed to compress GameCube and Wii images efficiently while retaining the ability to reconstruct verifiable disc data and maintain real-time emulator performance.

The problem with “unused” disc data

GameCube and Wii optical images contain more than obvious filesystem files. They include partition structure, encrypted Wii data, update content, alignment, and large regions that can look like random padding. Generic compression performs poorly on high-entropy bytes, while older space-saving formats often removed or normalized areas presumed irrelevant to gameplay.

That can be convenient and still unsuitable for a preservation master. Data considered unused today may matter for a full-disc hash, forensic comparison, unusual software behavior, future research, or reconstruction of the original layout. Once discarded, it cannot be recovered from the derivative merely because every familiar game scene still boots.

Dolphin’s report explains that GameCube and Wii “junk” is generated predictably. A format can describe those regions compactly and regenerate them during decompression rather than storing every pseudorandom-looking byte. It can also compress data in chunks designed for random access so the emulator does not need to expand an entire disc before play.

WIA, RVZ, and real-time access

WIA supplied a flexible Wii/GameCube archive design, but Dolphin found parts of its compression behavior too expensive for smooth on-demand emulation. RVZ revised the layout and compression choices for faster random reads and practical real-time use. The development build could convert images through Dolphin’s graphical interface and DolphinTool.

RVZ supports compression methods and configurable compression levels. Higher settings can reduce storage while taking longer to create and potentially more work to read. The useful setting depends on CPU, storage, archive scale, and whether the file is an active-play derivative or a preservation object. Format support does not guarantee every third-party tool implements every option correctly.

“RVZ” alone does not prove losslessness

The project contrasted RVZ with formats that scrub or omit unused-looking content. Wii update partitions, encrypted data, and apparently meaningless padding can matter to preservation, future verification, determinism, or obscure game behavior. RVZ reorganizes data for compression without making the archival master irrecoverable when used losslessly.

Dolphin’s conversion tools also expose options such as removing junk data. Selecting a destructive option makes the result lossy even when the filename ends in .rvz. Preservation records must retain the exact conversion settings, Dolphin build, source and output hashes, and verification result. An extension identifies a container family, not the quality or provenance of its contents.

The safe acceptance test is a round trip. Start with a verified canonical image, convert it to RVZ using reviewed lossless settings, convert it back to the canonical image representation, and compare the expected cryptographic hashes. For Wii images, use Dolphin’s verification features and preserve partition information and keys lawfully required by the workflow. Test more than whether a game launches.

Compatibility is part of format stewardship

Compatibility was a real boundary: older Dolphin builds could not read RVZ. The release therefore illustrates a broader preservation rule-record the tool and format version, retain verification hashes, and keep a documented path back to a canonical image.

An archive should preserve format documentation and open decoder source in addition to files. Keep a known-good Dolphin or DolphinTool build and test restoration periodically on supported host platforms. If the archive retains only RVZ, its recovery plan depends on a future decoder; retaining the verified canonical source as a separate master removes that single-format dependency at the cost of storage.

For active collections, RVZ can be a useful lossless master or derivative when the organization has validated round trips and tools. Some archives may instead keep raw canonical images immutable and generate RVZ access copies. Both approaches are defensible when documented; silently replacing a source and deleting the evidence is not.

Why the 2020 release mattered

RVZ aligned two goals often treated as opposites: strong compression and retention of the defined disc image. It showed that “emulation-ready” does not have to mean scrubbing data, while still acknowledging that user-selected conversion settings can cross into lossy territory.

The format is not a substitute for acquisition. A perfect RVZ conversion of a bad, incomplete, or incorrectly dumped disc preserves the bad input exactly. Verify source provenance, use current platform-specific dumping guidance, preserve logs and metadata, and then validate the container transformation.

Define what “lossless” means for this format

RVZ is lossless relative to the supported GameCube/Wii disc-image data Dolphin can reconstruct and verify. It is not a raw optical-drive capture of every physical property of a pressed disc. It does not by itself document the disc’s condition, drive read behavior, lead-in/lead-out behavior, or acquisition errors. A conversion cannot recover data that the original dumper omitted, and no container can make an inaccurate source dump authentic after the fact.

The 2020 Dolphin report describes RVZ as built from WIA but adapted for on-demand emulator performance and complete disc-data preservation. Its important design choice was to represent predictable unused-looking regions compactly rather than remove them as a lossy scrub. Wii disc partitions are stored in a representation that allows efficient compression while keeping enough information to reconstruct the expected disc image. The project specifically called out update data and IOS content as reasons not to discard material simply because current gameplay appears unaffected.

“Junk data” is a dangerous label outside the exact format rules. Some repeated or generated regions may compress dramatically, but a game can read data that its developer did not expect to use, and future software or tools can depend on update content. Do not hand-edit a disc image or remove blocks based on a filesystem view. The safe question is whether the format’s documented lossless decoder reconstructs the source image according to Dolphin’s verification rules.

Validate the conversion in both directions

Keep the acquired source image, its verified hash, physical disc identifier, region and revision notes, drive/tool versions, and dump log unchanged. Convert a working copy in Dolphin’s supported interface or DolphinTool, and capture the Dolphin build, compression selection, and any option that removes data. A setting that scrubs or omits data changes the preservation claim even if the output still has the .rvz extension.

Then use Dolphin’s verification capability to compare the RVZ against the expected source-image identity and convert a copy back to an ISO when the workflow calls for a round trip. Compare hashes using the same canonical image definition. For Wii media, distinguish encrypted and decrypted partition representations; a hash of a reconstructed ISO is meaningful only if the source and reconstructed output use the same representation and verification method. Do not compare a whole-container RVZ hash to an ISO hash and expect equality: compression, metadata, and storage layout intentionally make those files different.

Three checks answer three separate questions: the external SHA-256 confirms that the RVZ container did not change during storage or transfer; Dolphin’s verifier checks whether its recognized disc contents agree with a known reference; and round-trip extraction tests whether the chosen decoder can reconstruct the expected image. A game boot is only a compatibility smoke test. A title may start despite a missing update partition, wrong region, or other dump defect.

Choose master and access-copy policies intentionally

An archive can keep raw ISO files as immutable masters and create RVZ files as play copies, or keep validated RVZ as a preservation master if its format and recovery procedures are documented. The first policy consumes more storage but keeps a simple interchange baseline. The second can save substantial space, especially on discs with compressible regions, but depends on a compatible decoder and a trustworthy manifest. Either policy should retain the source hash, conversion command/settings, Dolphin version, output hash, and result of verification.

Maintain at least two independent copies and perform periodic fixity checks on both the source and container. A successful RVZ verification today does not prove that a future installation or toolchain can read the file. Periodically restore a sample into a clean Dolphin profile, reconstruct the source image, and re-check its hash. Keep a tested Dolphin or DolphinTool build and its provenance with institutional records where policy permits.

Compatibility must be stated by version. Dolphin’s 2020 report introduced RVZ support in development build 5.0-12188 and warned that older builds could not read RVZ; those builds required conversion back to ISO. Current Dolphin documentation still describes converting a game from the game list, but third-party applications may not support RVZ or may implement it differently. For interoperability, provide a verified ISO derivative where rights and storage allow, and never assume that every emulator accepts a Dolphin-specific container.

A compact acceptance record

For each disc, record source SHA-256, acquisition tool and drive, RVZ-producing Dolphin version, chosen compression/options, RVZ SHA-256, verifier output, reconstructed ISO hash if tested, target Dolphin version, and a compatibility result. Record what the test did not establish, such as subchannel capture or physical-disc authenticity. This makes the format’s strength clear: it can reduce storage without the deliberate content loss of a scrubbed image, while leaving acquisition quality and preservation provenance visible rather than hidden behind a filename.

A durable record includes physical disc identifier, region and revision, acquisition hardware and software, canonical hashes, RVZ format/tool version, compression method and level, destructive-option status, output hash, round-trip result, and storage fixity history. Those facts make “lossless” independently auditable rather than a claim inferred from a filename.

Related:

Sources: