Finding the Cause with the File Inspector

About 3 min read · 2026-08-04

Sometimes a conversion finishes but the result will not run on the PSP, or a patch is rejected the moment you try to apply it. Without a way to open the file up, there is no telling what needs fixing.

Drop a file into the file inspector and it identifies the format and unpacks the internal structure for you to read. This article covers what information comes out and what you can learn from it.

What you can put in

It accepts anything, regardless of extension. It reads the contents to determine the format, so it can identify files whose extension is simply wrong.

Use by situation

The EBOOT will not launch on the PSP

Feed it the EBOOT.PBP you built. The results are split into header, SFO and PSAR.

• The disc ID in PARAM.SFO — if this differs from the original disc's actual ID, the game may refuse to launch or its saves may get tangled. If automatic detection went astray during conversion, this is where it shows
• Parental level — anything above the PSP's own setting will not launch
• The disc count inside the PSAR — if you built a multi-disc file but only one is in there, a disc was dropped during conversion

A patch is rejected as "not matching"

Feed it the patch file and the original separately.

• BPS — it reports the source CRC32 recorded in the patch. If that differs from your original's value, you have a different version
• IPS — if the range of edits runs past the size of your original, you are applying it to the wrong file
• PPF — when block checking is enabled, the original is verified strictly

On the original's side, check the disc ID and the size against the target version the distributor listed.

I have no idea what this file is

Some files have no extension, or the wrong one. Just put it in: the tool determines the real format, and if it cannot, it shows the opening bytes as a hex dump. Distinctive strings at the start of a file — PATCH for IPS, for instance — are often enough to guess the rest.

I want to know a CD game's track layout

Feed it a .cue and it shows how many tracks there are, what format each is, and which .bin each refers to. This is useful for checking whether a game has audio tracks at all. If it does, you must include the .cue when converting.

I want to compare compression efficiency

Build the same game as both CSO and ZSO, inspect each, and you get the block size and compression ratio for both. That gives you something concrete to weigh when choosing between file size and loading speed.

How to read the results

CRC32 and checksums — a short number summarising a file's contents. If two files share the same value you can treat them as identical. Most patching problems come down to these values not lining up.

Sector sizes of 2352 and 2048 — CDs store data in sectors. A raw copy including audio uses 2352 bytes per sector; data extracted on its own uses 2048. Which of the two a patch was built against can change the result of applying it.

Disc ID — a code in the form SLUS00001 identifying the game and its region. The PSP also uses it to tell save data apart, so it needs to be correct.

Your files go nowhere

Inspection, like every other tool here, happens entirely inside your browser. Nothing is sent to a server, so even a very large disc image costs you no upload time, and personal files never leave your machine.

Summary

• When something breaks, open it up before you start guessing
• EBOOT launch problems usually surface in the disc ID or the parental level
• A rejected patch usually means a CRC32 mismatch — that is, a different version of the original
• It also serves simply to identify a file when you cannot trust the extension

Related reading: How to Apply a Translation Patch · Running PS1 Games on a PSP