XTool Complete Guide

[Razor12911]

With the release of xtool v0.9.9, there's certain things that were added to assist you in compressing your games and I've created this little guide to help you use xtool somewhat to its fullest potential.

Before you proceed, first visit this thread to see if the game you're interesting compressing hasn't been investigated and if you've researched a game want to post your own findings, post them here.

Topics

Investigation (Simple)
Investigation (Advanced)
Interpreting graphs
Precompressing the game (advanced)
- zlib

[Razor12911]

When you're compressing a new game that hasn't be investigated before, what you first need to do is find out what game engine said game is using.
You do this by using steamdb or by looking at the game structure, if it follows [CodeName]\Content\Paks then it is unreal engine, if there's cas files, then it is frostbite and so forth.
You do this first step because such games already have plugins that can work with those games and can be found here.

If it's a sequel to an already existing game, like Forza Horizon 5 and you're repacking Forza Horizon 6, then it is likely that the 6th iteration of the game uses the same method as the older game in which case, you should visit this thread to see what methods were used for that older game(s).

[Razor12911]

xtool v0.9.9 has added detail stream composition and graphical representation of stream and data. What you need to do is drag and drop game folder to xtool.exe whilst making sure xtoolui.dll is nearby. (Optional, if the ui dll is not present, you just get a summary and not the graphs)

We'll be using Dishonored 2 as an example.

This is the summary you get:

Processing input: E:\SteamLibrary\steamapps\common\Dishonored 2

Streams: 374562
  - zlib = 273263 (60,26%)
  - leviathan = 18 (0,01%)
  - kraken = 16 (0,02%)
  - mermaid = 1 (0,00%)
  - wwise (vorbis) = 101225 (13,48%)
  - bink (v2j) = 36 (6,66%)
  - png = 2 (0,00%)
  - bink (v1i) = 1 (0,00%)

Time: 00:02:34 (CPU 00:22:12)

Less than 1% detections can be considered false positives as this a quick scan.

and this is the graphical representation of the game.
Screenshot 2026-09-21 114933.png

The bar graph shaded in blue represents streams discovered in specific blocks and the line graph in green represents compression ratio for that block.

Now from here it is a question of which data type do you want to handle first, if it is the audio, you then filter the streams from the ui to see which files contain wwise audio.
Screenshot 2026-09-21 115748.png

You get to see what files contain audio, isolate them and use mesa or whatever tools that are available to process this audio.

Screenshot 2026-09-21 120133.png
Isolate the bink videos, good thing for this game they are easily identifiable by extension, isolate and process those using bpk.

Screenshot 2026-09-21 120417.png
And lastly, 60% of the game is zlib streams, for these you just use zlib+preflate and your job is done.

[Razor12911]

There is a total of three scenarios, and each one depicts how much compression you can obtain from any game.

NB: You can actually use your mouse wheel to zoom in if unable to click on points that are closely positioned together and use your right click to pan around.

Scenario 1
Screenshot 2026-09-21 193528.png

A game is not compressed at all and has no streams to be processed; this is indicated by the low hanging green line meaning those blocks are compressible and the blue bar barely visible means there are no streams. For such a game, you just use srep and lzma/lolz and call it day.

Scenario 2

Screenshot 2026-09-21 194429.png

A game is compressed and there are streams; this is indicated by very high green line and the blue bars. High green line means the blocks are not compressible and thus precompression is needed, and you're in luck because streams were detected in the same blocks.

Scenario 3

Screenshot 2026-09-21 194928.png

If you find yourself in this situation, just know that you are cooked if you don't know how to manually investigate game files because this just means two things, either the data is heavily compressed but using an unknown format or the data is encrypted and you need to find ways to decrypt the game.

In this case, you have to do your own investigative work, this scan was taken from The Crew Motorfest which has .bfd and .toc format, do a simple google search "The Crew Motorfest bfd", and you might get lucky and find something like this and then from here, you can take a look around the source and you'll notice this meaning that the game is indeed encrypted, provide your findings on the compression method thread and hopefully someone will provide a working tool for that game in particular.

[Razor12911]

Most of the codecs xtool provides have built in scanners to make precompression easier for the end user this is a list of codecs you can use directly without much issues.

zlib, lz4f, zstd, oodle (kraken, mermaid, selkie), direct storage (gdeflate), wav pcm audio (flac), jpg (brunsli)

png is a preprocessor codec, by itself it doesn't really do anything to the compression but what it does it restructure the stream in such a way that it allows zlib to be able to properly precompress it and that means whenever you use png, you can have to combine it with zlib (preferably reflate or preflate) alongside the -d1 parameter.

Now what is reflate and preflate? Well, both are zlib/deflate precompressor that are used whenever zlib fails to process a certain input and since this is a simple guide, it is better to use both zlib+preflate method whenever the scanners have picked up zlib streams.

What about leviathan and lz4/lz4hc?

These two codecs are very problematic to make universal precompression for, either scanning becomes annoyingly slow or their design just makes it unfeasible.

And the following codecs are placeholder codecs, either meant to help notify you of streams being detected but provide nothing other than that or assist in plugin creation. (Ignore them unless you plan on making a plugin)

xor, aes, rc4, zipcrypto, lz4, lz4hc, lzna, hydra, leviathan, wwise, mp3, ogg, bink

[Razor12911]

Reflate or Preflate? Both on paper serve the same purpose but if you're not sure which one to pick, you first need to know that reflate is typically faster and processes more obscure streams than preflate.
If it is speed that you're after, use reflate.

On the surface reflate seems to have no flaws then? It does it is sometimes prone to errors so if you encounter crc errors after using reflate, switch to preflate and on some data, reflate provides the worst ratio compared to preflate, fast as it is sometimes it is better to go with preflate so how to decide? In the more recent xtool updates, patching sizes were included for you to gauge whether patching is worth it or not so pick any file from the game with zlib streams and process one with reflate and one with preflate and you get results shown below as an example:

-mreflate

Streams: 496 / 510
  - reflate:l6 = 503 (45,56%)
Patched: 503 (45,2 MB)

Size: 665 MB >> 1,17 GB

-preflate

Streams: 496 / 510
  - preflate = 503 (45,56%)
Patched: 503 (37,5 MB)

Size: 665 MB >> 1,16 GB

We take a look at the patched part and here, you have to pick whichever provides the smallest patched size if you're after ratio or just go with reflate if you just want the speed and the size isn't that different.