In short
- The error means your source file isn’t byte-for-byte identical to the file the patch was created from.
- The xdelta project documents the wrong source file as the only normal cause.
- Fix it by verifying your file’s checksum against the patch notes and getting the exact version they list.
- Turning off checksum validation won’t fix it. It just produces a broken file.
What the error looks like
In Delta Patcher 3.1.2 and later, a dialog appears:
The patch could not be applied:
The file you are trying to patch is not the right one.
The log (bottom-right button) shows the underlying xdelta3 message:
An error has occurred: xdelta3: target window checksum mismatch: XD3_INVALID_INPUTThe xdelta3 command line and other XDelta tools show the same target window checksum mismatch text, sometimes followed by “normally this indicates that the source file is incorrect.” Delta Patcher shows the same friendly dialog for a related error, source file too short, which has the same root cause.
What “target window checksum mismatch” means
An XDelta patch doesn’t contain the finished file. It contains instructions that rebuild it, mostly “copy this range of bytes from the source file” plus some new data. xdelta3 rebuilds the output in chunks called windows.
When the patch was created with checksums (the default), it stores an Adler-32 checksum for every window of the correct output. As xdelta3 rebuilds each window from your source file, it calculates the checksum of what it just produced and compares it with the stored value:
A mismatch means the bytes copied from your file aren’t the bytes the patch author had. The patch itself is usually fine; the source is different. That’s why the xdelta documentation says this error “almost always means you supplied the wrong source file.” Hardware faults and corrupt patches are possible, but rare.
What about “source file too short”?
This is the same problem caught earlier. The patch asks for bytes beyond the end of your file, so your file must be smaller than the real original. Wrong file, trimmed file, missing header or incomplete download are the usual reasons.
Why a file that looks right still fails
“But it’s the right game!” is the most common reaction to this error. A patch doesn’t care about the title, only the exact bytes. These all produce different bytes:
| Difference | Example | Why it breaks the patch |
|---|---|---|
| Region | USA vs Europe vs Japan release | Different text, timing and code throughout the file |
| Revision | Version 1.0 vs 1.1 or “Rev A” | Bug fixes change and shift data |
| Dump or rip | Two copies of the same disc made with different tools or settings | Different padding, sector data or file order |
| Header | A cartridge ROM with or without an extra copier header | Every byte is shifted by the header’s length |
| Trimming | Unused space removed from an image | The file is shorter than expected |
| Format conversion | A raw image converted to a compressed or container format | The data is stored completely differently |
| Already patched | The same file patched earlier, perhaps with a different patch | It’s no longer the original |
| Corruption | An interrupted download or bad read | Random bytes differ |
How to fix a checksum mismatch
-
Find out which file the patch needs
Read the patch’s README, its download page, and the Patch info tooltip Delta Patcher shows when you load it. Look for a file name, region, revision, file size and a checksum (CRC32, MD5, SHA-1 or SHA-256).
-
Calculate your file’s checksum
Use the same algorithm the author lists. On Windows, PowerShell can calculate SHA-1, SHA-256 and MD5:
Get-FileHash ".\Game (USA).iso" -Algorithm SHA1For CRC32 and other systems, see how to verify a source file.
-
Compare the two values
If they match, your source is correct; skip to if the checksums match. If they don’t, your file is a different version, and no setting in Delta Patcher will change that.
-
Get the exact version the patch expects
Work through the table above: check the region and revision, remove or add a header, undo trimming or conversion, or make a fresh copy from media you own. Re-check the checksum after each change.
-
Patch a clean copy with validation on
With a matching source, apply the patch to a fresh copy, tick Backup original file, and leave Checksum validation on. It should now succeed.
If the checksums match but the patch still fails
- Patch order: if you’re applying several patches, each later patch must be applied to the previous output. How to stack patches.
- Wrong patch variant: some projects ship separate patches for different regions or formats. Make sure you downloaded the one for your file.
- Damaged patch: download the patch again and check any checksum the author publishes for the patch file.
- Hardware problems: if checksums match and the patch still fails on your machine but works elsewhere, test your drive and memory.
Should you turn off checksum validation?
Almost never. Delta Patcher’s Checksum validation option (in the gear menu next to Apply patch) tells xdelta3 to skip the check. With a wrong source file, the patch then “succeeds” and writes a file containing the wrong bytes. Without Backup original file, that broken file replaces your original.
| Situation | Validation on | Validation off |
|---|---|---|
| Correct source file | Patch applied | Patch applied (same result) |
| Wrong source file | Stops with an error; original untouched | Produces a corrupt file; may replace your original |
The only reasonable use is diagnosis by an experienced user, on a backup copy, to see where the output diverges. It never turns a wrong source file into a working patched file.
For patch authors: prevent this for your users
- Keep Add Checksum to patch on when creating patches.
- Publish the exact source file name, size and a checksum in both your README and the patch description.
- Say whether the file should be headered or unheadered, trimmed or untrimmed, and which format it should be in.
- If several source versions are common, provide a patch for each, clearly named.
More in writing a useful patch description.