ampr-emu-ng: A PS5 Pack Loader With 77 Percent Less Memory

By Indie Kings | November 3, 2026

Updated November 3, 2026: ampr-emu-ng is a hard fork of the PS5 AMPR runtime that reads both zstd and LZ4 game packs. Its own benchmarks show a 77 percent cut in runtime memory and up to 96 percent less waiting per read. Version 0.2.0 shipped on November 2 with USB recovery, case-sensitive module loading and a fix for a corrupted save problem.

Image: a PlayStation 5 with a DualSense controller. ampr-emu-ng replaces a system library on jailbroken consoles. Photo: Osh33m, CC BY-SA 4.0, via Wikimedia Commons.

A drop-in replacement for libSceAmpr

On a PlayStation 5, libSceAmpr.sprx is a system library that games use to read their own data. When a dumped game is converted into a pack format, something has to stand in for that library and serve the game's file requests from the pack instead of from the original disc layout. ampr-emu-ng is that replacement, and it is a hard fork of drakmor's C++ ampr_emu with a focus on speed and stability.

The project is small in every sense except the problem it solves. GitHub lists 24 stars, no forks, no open issues, a GPL-3.0 licence and a repository of about 541 KB. It was created on October 27, 2026, and version 0.2.0 arrived on November 2. The first release, 0.1.0, was downloaded 319 times; 0.2.0 had 42 downloads at the time of writing. This is a specialist tool for people who already run converted PS5 games on jailbroken hardware.

The interesting design choice is that one runtime handles two pack formats. At load it checks for /app0/ampr_zstd.index. If that file exists, it reads zstd packs with an AMPRZPK1 index and AMPRZDT1 volumes. If it does not, it falls back to LZ4 packs with the AMPRPAK4 format. The repository only reads packs; it contains no encoder. Packs are built with a separate tool, ps5-dump-forge, and the zstd layout is documented in the project's docs folder.

That dual-format support matters because it lets the same runtime serve an existing LZ4 library and a newer zstd library without asking the user to choose a build. The console prints a line at launch that names the mode: ampr-emu-ng: vx.x.x (zstd) running, with lz4 or plain in place of zstd when those are what it found. Plain mode means no packs at all and loose files only.

The project is not a general PS5 emulator and does not pretend to be one. It replaces one library inside a game that is already running on real hardware. The README assumes a jailbroken console, a dumped game, a pack built from that game, and ShadowMountPlus to mount it. Nothing in the repository provides game files, keys or firmware.

The benchmark: less waiting, less memory

The README publishes a benchmark that is more useful than a vague claim of faster loading. It uses one game, one level, and multiple runs per runtime, measuring from launch to the level being loaded. The baseline is the original C++ ampr_emu, compared with ampr-emu-ng in LZ4 mode and in zstd mode.

The biggest gain is in how long the game waits for a read. At the start of a load, with about 1.2 GB read, the original waits 19.76 ms per read. ampr-emu-ng waits 0.79 ms in LZ4 mode, a 96 percent reduction, and 0.89 ms in zstd mode, a 95 percent reduction. Once the level is loaded, with about 8.8 GB read, the original waits 10.26 ms per read. The fork waits 1.30 ms in LZ4 and 1.27 ms in zstd, reductions of 87 and 88 percent.

Disk reads follow the same pattern. At the start of a load, the original spends 2.01 ms per read; LZ4 takes 0.79 ms and zstd takes 0.59 ms. When the level is loaded, the original spends 3.38 ms; LZ4 takes 1.23 ms and zstd takes 0.68 ms. The pack job also gets cheaper, from 2.22 ms to 1.27 ms at the start of a load and from 3.35 ms to 1.40 ms once the level is up, in zstd mode.

The memory numbers are the headline. The original allocates a 384 MiB pool with a peak of 267.9 MiB. The fork uses an 88 MiB pool in LZ4 mode with a 79.9 MiB peak, and an 82 MiB pool in zstd mode with a 73.3 MiB peak. Runtime memory, measured from the release PRX segments, falls from 397.2 MiB to 96.4 MiB in LZ4 and 90.7 MiB in zstd. That is a 76 to 77 percent reduction in the memory the runtime holds.

Disk footprint depends on the format. An LZ4 pack stays at 32.43 GiB, the same as the original layout. A zstd pack at level 5 comes to 23.61 GiB, 27 percent smaller. The trade-off is visible in the read table: zstd reads 3.48 GB instead of 4.98 GB once the level is loaded, which is where the 30 percent reduction in disk bytes comes from.

These are the project's own measurements, not an independent review. They come from one game and one level, and the README does not name either. Treat the percentages as a direction rather than a guarantee for every title. Even so, the shape of the result is consistent across every row: the fork spends less time waiting, reads less from disk in zstd mode, and holds far less memory than the runtime it replaces.

What 0.2.0 changed

Version 0.2.0 is the release that pushes the fork ahead of the source it came from, according to its notes. The most consequential fix is in APR WaitOnAddress and WriteAddress. When either is called on an unmapped address, the command now fails with an APR error instead of crashing. The release notes connect that crash to a corrupted save problem, which makes this more than a stability nicety.

The PRX now exports the 19 libc and libc++ symbols that the retail libSceAmpr carries, for 137 exports in total. That matters for games that resolve those symbols at load. Module loads on case-sensitive installs also go through the index, so a game that asks for a file with different capitalization, such as Wwise's AkSineTone.prx stored as aksinetone.prx, can still load it.

USB handling got a set of practical fixes. Pack and index reads retry on EINTR and on short reads. The slow-media EAGAIN backoff now has an absolute cap. If a pack volume read fails with EBADF, EIO or ENXIO, which can happen after the console resumes from rest mode with a USB drive remounted, the runtime reopens the volume once and retries the job. That is the kind of bug that looks random to a player and obvious to a developer who has seen the log.

The /app0 index is more conservative too. A lookup the index cannot answer falls through to the filesystem, symlinks are not indexed, and the shipped index is never replaced after a read error. Those choices favor a working game over a clever cache.

The debug build adds tools that make the runtime observable. It serves plain text on TCP port 9090, one client at a time. /metrics returns pool usage and counters for disk reads, pack jobs, decodes, cache hits and misses, read-ahead and errors. /bench measures raw read speed of pack volume 0. /set?k=v changes tuning knobs and saves them to /data/ampr_emu_tune.txt. /fsfail lists distinct failed calls since load, and /modules lists the modules the game loaded with their segment sizes and fingerprints. The release build ignores the tuning file.

Building the PRX is a Docker job. The first run builds a toolchain image from the project's Dockerfile with Rust 1.99.0, LLVM 19 and ps5-payload-sdk v0.43. The build script produces libSceAmpr.sprx and a debug variant, then verifies them with a Python script. The release assets are small: the main PRX is about 678 KB and the debug PRX about 747 KB.

Installing it on a jailbroken PS5

Installation is deliberately manual. Copy libSceAmpr.sprx into the game's fakelib/ folder, then mount the game with ShadowMountPlus. Disable fakelib update in the settings, or the console may replace the file you just copied. The README repeats those two steps in both the release notes and the usage section, which suggests they are the two places people go wrong.

You also need a pack. The runtime does not convert a game by itself. zstd and LZ4 packs are made with ps5-dump-forge, and the repository has no encoder. The README's build section is for people compiling the runtime, not for people making a pack. If you are starting from a dumped game and no pack, the pack tool is the first stop, not this repository.

Once the game starts, the console line tells you which mode is active. If it says plain, the runtime found no packs and is reading loose files. If it says lz4 or zstd, it found the matching index and is serving from the pack. That one line is the quickest way to confirm the install before you judge load times.

The debug PRX is worth knowing about if something fails. Its metrics endpoint can show whether reads are hitting the cache, whether pack jobs are failing, and which modules loaded. The /fsfail endpoint lists failed path hooks, APR resolves and module loads, which is more useful than a generic crash. Run it on a second install and diff /modules to find a module that did not load.

FAQ

Does ampr-emu-ng work on an unmodified PS5?
No. It is a replacement PRX for a jailbroken console, copied into a game's fakelib folder and mounted with ShadowMountPlus. It is not a PC emulator and does not run on Windows or Linux.

Does it convert a game into a pack?
No. The repository only reads packs. zstd and LZ4 packs are built with ps5-dump-forge. ampr-emu-ng provides the runtime that serves the pack to the game.

Which pack format is faster?
The project's benchmark shows similar read latency for LZ4 and zstd. zstd uses less disk space and reads fewer bytes once a level is loaded, while LZ4 keeps the pack at the original 32.43 GiB size.

Does 0.2.0 fix corrupted saves?
The release notes say an APR WaitOnAddress or WriteAddress call on an unmapped address now fails with an APR error instead of crashing, and they connect that crash to a corrupted save problem. It is a fix for a cause, not a recovery tool for saves already damaged.

What is the debug PRX for?
It serves metrics, benchmark, tuning and failure data on TCP port 9090. The release PRX does not expose those endpoints, and it ignores the saved tuning file.

Is the project open source?
Yes. It is GPL-3.0-or-later, matching the upstream ampr_emu licence, and the source includes the PS5 build files and the verification script.

Bottom Line

ampr-emu-ng is a narrow tool with a strong benchmark. It replaces the PS5 library that serves converted game packs, adds zstd support to an LZ4 world, and cuts runtime memory by roughly 77 percent while making reads wait a fraction of what the original did. Version 0.2.0 adds real fixes for USB remounts, case-sensitive module loads and a crash tied to corrupted saves, plus a debug build that makes failures visible.

The limits are just as important. It needs a jailbroken PS5, a dumped game, a pack made with a separate tool, and a manual install into a fakelib folder. The benchmark covers one unnamed game and one level. The project has 24 stars and a single main contributor, so support is whatever the README and the issue tracker can provide.

Our take: this is for people already running converted PS5 games who want lower memory use and faster loads, not for someone looking for a first PS5 setup. Read the two install steps twice, keep the debug PRX available, and measure your own game before assuming the percentages carry over. If you are already in that niche, the memory reduction alone makes it worth testing.

Sources

• GitHub quer3q/ampr-emu-ng README, performance tables, usage, pack formats, debug endpoints, build steps and licence, accessed November 3, 2026
• GitHub release 0.2.0, release notes, asset sizes and download count, published November 2, 2026, accessed November 3, 2026
• GitHub API metadata for quer3q/ampr-emu-ng, stars, forks, open issues, creation date, language, size and licence, accessed November 3, 2026
• GitHub release 0.1.0, release notes and download count, published October 29, 2026, accessed November 3, 2026

Related: ShadowMountPlus: A PS5 Auto-Mounter That Warns of Data Corruption | Dead Cells: First PS5 Game Runs Natively on Windows via AnyPS5 | RecompStore: A Homebrew App Store for Jailbroken PS5 Recomps