# Wwise-Unpacker: getting game audio out of Wwise containers on Windows

> Wwise-Unpacker is a pair of batch files and a folder of tools that decode the Wwise audio containers shipped inside games into playable MP3 or OGG files. What makes it more than a script is the file naming: once unpacked, the audio is labelled by episode, character, location, action and mood, so a game's voice lines become a searchable library rather than a folder of hashes.

**Vextil/Wwise-Unpacker** — Unpack game audio Wwise files (pck, bnk)

- Repository: https://github.com/Vextil/Wwise-Unpacker
- Stars: 806 · Forks: 117
- Language: Batchfile
- License: not declared
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/vextil-wwise-unpacker

## Two batch files and a folder of tools

Wwise-Unpacker unpacks game audio Wwise files, the PCK and BNK containers, and the whole thing is delivered as an archive with a very small set of moving parts.

The layout of the archive is the layout you work in. There is a folder for unpacked MP3 files, a folder for unpacked OGG files, a folder called Game Files that holds the containers you want decoded, a folder with the tools used for the unpacking process, and two batch files, one to unpack to MP3 and one to unpack to OGG.

That is the entire product. There is no configuration file, no command line parser and no option screen. You put files in one folder, you double-click one of two scripts, and the decoded files appear in the matching output folder.

The guide is explicit that this is for 64-bit Windows only, and it uses a specific game as its worked example. The example is not a restriction, though, because the README says the unpacker can be used for any game that uses Wwise audio.

The interesting thing about the design is that the tools are shipped with the archive. The unpacker relies on the vendor's own unpacking utilities rather than reimplementing the container format, which is the pragmatic choice and also the fragile one, because a format that changes with each engine version will break a bundled binary that nobody can easily update.

## Finding the containers is more work than the unpacking

The README spends a good part of its length on how to locate the audio in the first place, and the advice is practical rather than technical.

You can search for the container extensions across the game folder, but the author prefers another route: go to the game directory and search for the Wwise audio folder, which shows the audio folder for each chapter.

Inside each of those folders the file types are self explanatory, with folders for music, ambience, cutscene and sound effects, and the voice files in an English locale subfolder whose names start with a voice-over prefix.

The next paragraph is the one that tells you what to expect. These are containers, and inside each there could be either one or hundreds of audio files, with some of the largest voice containers holding over five hundred.

That number matters for the practical reason the README gives later, because the decoder's runtime depends on the number and size of the files. It also matters for expectations: someone who expects a folder of tracks will find a container with a single file in it, and someone who expects a folder will find five hundred voice lines.

So the workflow the README describes is to find the containers you want, copy them into the Game Files folder, and then run the script. The unpacker handles either container type, and it is the same tool for both.

## The naming scheme is the reason the output is worth keeping

The most valuable thing the unpacker produces is not the audio itself, it is the names.

The README explains that the files are properly labelled with episode, character, location, action and mood after unpacking, and gives a long example filename that encodes all of those: an episode and scene, a cue, the speaking character, the location, an emotion, the take number and the file extension.

That is a big deal for anyone who wants to find a particular line later. A raw game container gives you a set of opaque identifiers and a table you have to look up, and a long voice container gives you five hundred of them. Once the names carry the episode, the character, the place and the mood, the folder becomes a searchable corpus of a game's dialogue, and that is the difference between a decoding exercise and a resource.

The author is also clear that these are containers rather than finished assets, so the quality of what comes out depends on the source, and that the labelling is what makes the result usable.

The closing note of the readme is worth repeating because it tells you what the maintainer thinks the tool is for. If you end up doing something with the audio, videos for example, let me know, and the author says they really enjoy looking at other people's work. That is the framing: a tool for making something with the audio, not an extraction scheme with an audience of none.

## Running the decoder, and the two prompts you will meet

The decoder's behaviour is described with the sort of detail that only comes from having watched it run many times.

First, it can take a while, depending on the number and size of the files, and the instruction is to let it run until you see the ASCII tornado. That is the progress indicator, and knowing what it looks like saves you from killing a run that is working.

Second, the decoder will offer to delete the files in the Game Files folder, so that you do not accidentally decode the same files again. This is a reasonable convenience and a sharp edge, because it means the input folder is treated as a work queue that is consumed as it goes. If you want to keep the containers, copy them from somewhere else.

Third, and the one that catches most people out, there can be filename conflicts while decoding when several files share a name. The prompt asks you to type the letter r and hit enter, which renames the files so you can keep all of them. Two different voice lines with the same name in different containers is not a hypothetical in a game with five hundred voice lines per chapter.

The output then lands in the MP3 or the OGG folder depending on which script you ran. The repository carries both output folders, which is a reminder that the archive was distributed with example results in it, or at least with the empty directories ready.

## MP3 is a conversion on top of OGG, and the README says so

The quality question has a clear answer in the readme, and it is worth knowing before you decode a large library.

When decoding MP3 files they are first unpacked as OGG and then converted with FFmpeg and the LAME MP3 encoder. So the MP3 path is the OGG path plus a lossy encode, and the README's advice follows directly: if you want the best quality possible, do not use MP3, unpack it as OGG.

That is a small but real point about the tool. The unpacking is lossless, and the quality loss is entirely in the optional convenience step. A user who reaches for the MP3 script by default, because it is the more familiar format, is adding a lossy generation to files that did not need one.

For listening, the README suggests a player that supports the format and mentions foobar2000 as the author's own choice, with a note to look around and find what suits you. Any player that reads OGG will do, and that is most modern ones.

The two facts together, the intermediate OGG and the recommended output format, mean the tool is really an OGG extractor with an MP3 convenience wrapper. Which is fine, as long as you know which one you are using.

## A project with an unusual age profile

The repository is small and mostly binary, and its history says something about the tool.

The listing shows the two batch files at the root, the folders for the game files, the unpacked MP3 and OGG output and the tools, and two dotfiles for the repository hygiene. There is no source code directory, because there is no source code: the deliverable is scripts and third party binaries, with documentation.

The release history spans a decade. Version 1.0.1 came in September 2016, 1.0.2 in March 2018, and 1.0.3 in December 2021. The last push to the repository was on 2026-07-18, and the primary language recorded for the project is a batch file, which tells you what the artefact is.

That combination, a decade between releases, a recent commit, and no code to review, is the honest profile of this project. It is a working tool for a specific job, distributed in the form the author found useful, and the risk with it is the one that comes with shipping binaries: the Wwise format moves, and when it does, the bundled tools are what will stop working, and there is nobody maintaining a source tree that could be patched to follow it.

For an evaluator the practical questions are therefore about provenance rather than architecture. Which tools are in the Tools folder, and under what terms they are distributed, are the things to check before running the unpacker on a game's assets, alongside the terms of the game itself.

## Conclusion

Adopt Wwise-Unpacker if you are analysing or reusing audio from a game you have legitimately bought and it uses Wwise, because the labelling it preserves is what makes the output usable a year later. Do not adopt it expecting a cross-platform tool, since the README states the guide is for 64-bit Windows only, and check the terms of the game and of the audio in question before you publish anything derived from it. Before you run it, copy the containers you want rather than the whole audio tree, because the decoder offers to delete the files it processed, and expect a long wait, since the README says to let it run until the ASCII tornado appears.

## FAQ

### What does the Wwise-Unpacker tool do?

It unpacks the Wwise audio containers shipped inside games, the PCK and BNK files, into playable MP3 or OGG files. It is distributed as two batch files and a folder of tools, and the guide is written for 64-bit Windows only, though the README says it works for any game that uses Wwise audio.

### How do I find the Wwise audio files in a game?

Search the game directory for the Wwise audio folder, which shows the audio folder for each chapter. Inside it you will find folders for music, ambience, cutscene and sound effects, with the voice files in an English locale subfolder whose names start with a voice-over prefix. Copy the containers you want into the Game Files folder of the unpacker.

### Why should I unpack to OGG rather than MP3?

Because MP3 decoding first unpacks the files as OGG and then converts them with FFmpeg and the LAME MP3 encoder, so the MP3 path adds a lossy encode. The README says that if you want the best quality possible, do not use MP3 and unpack as OGG instead.

### What happens if two files have the same name when decoding?

The decoder prompts you, and typing the letter r and pressing enter renames the files so you can keep all of them. The README also notes that the decoder offers to delete the files in the Game Files folder so you do not decode the same files again, and that you should let a run finish until the ASCII tornado appears.

### What does the Wwise-Unpacker repository contain?

Two batch files for unpacking to MP3 and to OGG, folders for the game files, the unpacked MP3 and OGG output and the tools used for the unpacking process. The project is mostly binaries and documentation, and its releases are version 1.0.1 from 2016, 1.0.2 from 2018 and 1.0.3 from 2021, with the last push in July 2026.

## Sources

- [Issues](https://github.com/Vextil/Wwise-Unpacker/issues)
- [README](https://github.com/Vextil/Wwise-Unpacker/blob/master/README.md)
- [Releases](https://github.com/Vextil/Wwise-Unpacker/releases)
- [Vextil/Wwise-Unpacker on GitHub](https://github.com/Vextil/Wwise-Unpacker)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/vextil-wwise-unpacker
