Comparison with similar tools
The useful distinction is the job each tool handles: a single patch, an embedded patcher, a disc conversion, or a complete ROM workflow. Format counts alone do not show whether a tool fits that job.
The tools
| Tool | Main purpose | Trade-off |
|---|---|---|
| rom-weaver | Extraction, patch chains, checksums, compression, and bundles in a browser or native CLI | More controls than a single-purpose patcher; browser storage limits still apply. |
| RomPatcher.js | Browser and Node patching, including embedding in another website | A useful fit for a release page with its own patch button. |
| Floating IPS (Flips) | IPS and BPS patch creation and application | A focused alternative when those formats cover the job. |
| MultiPatch | A native macOS app for several patch families | Fits a desktop macOS workflow rather than a browser workflow. |
| xdelta3 | General binary differences using VCDIFF | Works beyond ROMs; it does not choose a ROM's header or byte order. |
| chdman | CHD creation, extraction, and verification | Provides the reference CHD tooling, including operations outside rom-weaver's CLI surface. |
| Dolphin tool | GameCube and Wii disc conversion | Includes GCZ and WIA output, which rom-weaver does not create. |
At a glance
An existing patch usually decides the format for you. The remaining choices concern the interface, input preparation, and checks. Supported formats owns rom-weaver's capability tables; each linked project documents its own support.
Applying a patch
For a single uncompressed ROM and a supported patch, a focused patcher can be sufficient. rom-weaver becomes useful when the input needs extraction, several patches must run in order, or a bundle carries expected checksums and optional patches.
Creating a patch
A patch creator must reproduce the intended Modified file from the documented Original. Different creators can encode different patch bytes for the same result. A smaller patch or a familiar encoder does not remove the need to test reconstruction.
Choosing a patch format explains the format trade-offs. BPS implementation references records the encoder differences relevant to rom-weaver development.
Containers and disc images
chdman and Dolphin tool handle disc conversion directly. rom-weaver combines supported container extraction, patching, and compression in one workflow. When the required output is unsupported, a separate converter remains necessary.
Parity tests compare reconstructed payloads. They do not establish that every compressed container or patch stream is identical across tools. Performance describes the parity harness.
Checksums
A displayed checksum identifies the bytes a tool read. Validation compares those bytes with an expected value. These are different capabilities: an IPS patch, for example, contains no expected source checksum for a patcher to check.
rom-weaver can take expected checks from a bundle or explicit command options. How patching works explains the limits of that evidence.
Headers and byte order
Two dumps can represent the same game in different byte layouts. Patching needs the layout the author used. rom-weaver can compare supported variants and infer some layouts when a patch lacks checksums. An unresolved case still needs the author's release information; automatic handling is not a guarantee.
Patching features
Patch order, optional choices, and expected intermediate results are part of a release. A bundle records them in a machine-readable file. With separate single-patch runs, the user or a script must preserve that information and manage intermediate outputs.
Beyond patching
rom-weaver also identifies, hashes, trims, and compresses supported inputs. These features can reduce the number of tools in a workflow. They do not replace all operations in specialist disc or emulator tools.
Delivery and platforms
A browser patcher avoids installation. A native application avoids browser memory and storage limits. An embeddable patcher serves a different need again: integrating patching into a release author's own page. Browser and CLI explains rom-weaver's two interfaces.
Which one should you use?
Keep a tool that already handles your input and produces the result you need. Consider rom-weaver when repeated extraction, patching, checking, and compression are the work you want to combine. For a patch button embedded in another website, RomPatcher.js documents that use directly. For unsupported disc output, use the reference converter.
How this page was checked
The project descriptions above use the linked upstream repositories and official chdman documentation, checked on 2026-09-05. rom-weaver's details are checked against this repository's command, format, and parity-test implementations. The links are the source for current upstream capabilities.