Separate representation problems from game semantics
A fail-closed PlayStation 1 Memory Card Image troubleshooting guide for distinguishing representation problems from unsupported semantics and for selecting read-only integrity checks before any repair attempt. The existing format hub describes the representation as: Standard 128 KiB original PlayStation memory-card images and the specifically supported complete VGS/MEM and PSX wrappers. SaveEditor validates the embedded card structure and never treats wrapper recognition as permission to synthesize game payload, directory, checksum, or allocation data.
Start by asking whether the failure is at the representation layer or inside game-specific data. Representation checks can establish framing, parseability, fixed markers, checksums, redundant metadata, allocation structure, or wrapper relationships only when an existing verified parser implements those checks. They do not automatically explain unknown inventory, progression, account, encryption, or title-specific fields.
Use read-only evidence before repair
Existing verified Tool context includes: DuckStation Save Converter, PS1 Card Block Chain Analyzer, PS1 Card Checksum Auditor, PS1 Card Directory Auditor, PS1 Card Free Space Map, PS1 Deleted Entry Inspector, PS1 DexDrive GME Container Extractor, PS1 DexDrive GME Fingerprint and 20 additional verified Tool(s). Use read-only inspectors, fingerprints, forensic reports, or validators first when available. A Tool listed for the format can still have a purpose narrower than the format as a whole, so its individual support and refusal rules remain authoritative.
Record the source size and SHA-256 where practical, then work from a copy. Compare structural reports before and after any authorized change. If a wrapper contains an embedded save, distinguish wrapper damage from payload damage. If a card image contains filesystem metadata, distinguish directory or allocation problems from bytes inside an individual game save.
Fail closed when the correct bytes are unknown
A failed checksum does not automatically reveal the correct replacement bytes. A broken directory does not prove which allocation chain should win. Two valid redundant copies may still be ambiguous if neither has an independently established precedence rule. Likewise, encryption or digital signatures cannot be regenerated merely because the outer structure can be parsed.
Do not synthesize missing payload bytes, rewrite unknown metadata, select a newer or better save from timestamps alone, or promote a file because its extension and size look plausible. Use repair, migration, conversion, signing, decryption, or editing only when an existing verified Tool explicitly owns that exact operation and its prerequisites are satisfied.
Verify any authorized output
After an authorized repair or edit, compare the output against the original and verify that only the documented byte scope changed. Reopen the result through the strict parser, re-run the relevant checksum or structural checks, and retain the original backup. A successful download alone is not proof that the target game or emulator will accept the result.
If multiple defects remain, if the result cannot reopen, if integrity checks disagree, or if the format requires account-bound signing or other unsupported protection, stop at diagnosis. Preserve the evidence report and source copy rather than escalating to a broader mutation that the verified Tool contract does not authorize.