# SymphonyRecomp: a static recompilation of Castlevania: Symphony of the Night for modern PCs

> SymphonyRecomp turns a legally owned North American PSX disc into a native PC build using RecompOne, the same toolchain the README names. It is an open beta with known crash risk, and the README itself points to the SOTN Decomp project as the eventual de facto PC port.

**BlackLabelHQ/SymphonyRecomp** — Recompilation project for Castlevania: Symphony of the Night

- Repository: https://github.com/BlackLabelHQ/SymphonyRecomp
- Stars: 796 · Forks: 31
- Language: C#
- License: not declared
- Published: 2026-09-17 · Updated: 2026-09-17 · Language: en
- Canonical page: https://hysenlabs.com/projects/blacklabelhq-symphonyrecomp

## What SymphonyRecomp solves, and who it is actually for

Sony's original hardware limits Symphony of the Night to its console's resolution, its memory, and its disc read behaviour. SymphonyRecomp attacks that limit by statically recompiling the game into C# so it runs as a native program on a modern computer. The README states the goal plainly: bring the game to modern computers "without some of the limitations of older consoles." The repository is C# and the default branch is master.

The audience is narrow. You need a legally owned North American PSX copy of the game in bin/cue format, a GPU with OpenGL 2.1 support, .NET 10, OpenAL and Git. If you only want to play, the README points at the releases page rather than the build instructions. If you want to contribute code, the README asks for Visual Studio 2026 or VSCode and states that AI-written pull requests are rejected and can get you banned from BlackLabelHQ repositories. That policy is unusual enough to mention: it shapes who can participate at all.

## How RecompOne turns a PSX disc into a C# program

The mechanism is static recompilation, not emulation. According to the README, the project was made using RecompOne, which processes the game and produces game code you then compile yourself. The build scripts reference a sotn.json configuration, and running RecompOne against it is the manual path the README describes.

The README also says the project used references from the decompilation effort to name functions and make patches. That is the interesting architectural detail: the recompiler produces the executable code, while names and patches borrowed from the decomp give the result something closer to readable source. The repository layout reflects this split, with a RecompOne directory, a config directory, patches, mods, wrappers and a disc directory that holds your ripped files.

This is also where the project's identity gets confusing for newcomers. The README spends several paragraphs insisting that a recomp is not a decomp, that SymphonyRecomp is not the SOTN Decomp project, and that support questions belong in the BlackLabelHQ Discord rather than the decomp server. Treat that as a real constraint: the two communities are separate, and the README says the full SOTN Decomp release will become the de facto modern PC port once it ships.

## Building SymphonyRecomp from source on Windows

The README gives a short build path: clone the repo, add legally owned game files to the disc directory, then run one of the batch scripts or invoke RecompOne against sotn.json manually. Dev builds do not auto-update, so you are responsible for pulling changes yourself.

Start by cloning and placing the disc files. The README says the files must be hard named and placed inside the disc directory in the main project directory:

```bash
git clone https://github.com/BlackLabelHQ/SymphonyRecomp.git
cd SymphonyRecomp
ls disc
```

The listing should show the three files the README names: Castlevania - Symphony of the Night (Track 1).bin, Castlevania - Symphony of the Night (Track 2).bin, and Castlevania - Symphony of the Night (USA).cue. If any name differs, the build will not find them.

With the files in place, run the initial build script from the repository root:

```bash
windows_initial_build.bat
```

That script drives RecompOne against sotn.json, which per the README produces the game code. After that, windows_run.bat builds and launches, while windows_run_no_build.bat skips the build step. A run.sh exists for non-Windows use, though the README's prerequisites and script names are written around Windows. Expect the first build to be the slow one; later runs are just compilation and launch.

## The beta warning is not boilerplate

The README labels this an open beta and states that stable version 1.0 has yet to be released. It goes further: "You may experience disastrous game breaking bugs!" The project says every effort was made to prevent that, and then warns you anyway.

Take that at face value. A static recompiler translates machine code in bulk, and any region it translates incorrectly can produce a fault far from the original instruction. That failure mode looks like a crash or corrupted state rather than a clean error message. The README offers no rollback procedure and no way to pin a known-good dev build, so the practical safety net is the tagged releases, the most recent of which is v0.5.1b from 2026-08-19. The last push to the repository was on 2026-09-06, so the master branch moves between tags.

There is a second limitation that has nothing to do with code quality. The build is tied to one specific disc revision: the North American PSX version in bin/cue. The README does not describe support for other regional releases, and the filenames are hard-coded, so a European or Japanese copy is not a supported input.

## SymphonyRecomp versus a decompilation port

The obvious alternative is the SOTN Decomp project, and the README names it directly, saying its full release will be the de facto means of modern PC port efforts. The difference is in what each approach produces.

A decompilation reconstructs the game as human-readable source, which means the resulting port can be refactored, extended and understood function by function. A static recompilation translates the original binary into generated code, which is faster to produce but leaves you working with output that mirrors the original machine code rather than clean source. SymphonyRecomp sits between the two: it recompiles, and it borrows names and patches from the decomp to make the result more workable.

That middle position explains the project's own framing. It exists now, in beta, while the decomp is still incomplete. If you want to play on a modern machine today and you are comfortable with beta software, the recomp is the available option. If you want a port that can be maintained and modified at the source level, the README itself tells you to wait for the decomp.

## Maintenance, releases and the missing licence

Development is ongoing. The last push was on 2026-09-06, and three releases landed in August 2026: v0.4.3b on 2026-08-09, v0.5.0b on 2026-08-18, and v0.5.1b on 2026-08-19. The README states that dev builds do not auto-update, so anyone building from master carries the cost of pulling and rebuilding by hand.

The repository has no licence file listed among its top-level entries, and the README does not state a licence. That matters more here than in a typical project. The code is one thing; the game assets are another, and the README requires a legally owned copy of the game to build at all. It also asks that you not raise SymphonyRecomp in the SOTN Decomp Discord. None of this is legal advice, but the absence of a stated licence means you cannot assume terms for redistribution or reuse, and you should confirm them with the maintainers before building anything on top of the code.

## Conclusion

Adopt SymphonyRecomp if you own the North American PSX disc, have .NET 10 and an OpenGL 2.1 GPU, and want to build a native PC version from source with RecompOne rather than wait for the full SOTN Decomp release. Do not adopt it if you want a finished, stable port: the README states stable 1.0 has yet to be released and warns of disastrous game-breaking bugs, and it is the wrong tool if you cannot supply the disc files under their exact hard-coded names. Before building, verify that .NET 10 and OpenAL are installed, that the three disc files sit in the disc directory with the exact filenames the README lists, and that your GPU reports OpenGL 2.1 or higher.

## FAQ

### How does recompilation work in SymphonyRecomp?

The README states the project was made using RecompOne to statically recompile the game, and that running RecompOne against sotn.json produces the game code, which you then compile yourself. Some references from the decompilation effort were used to name functions and make patches.

### What is the difference between decompilation and recompilation for Symphony of the Night?

The README insists a recomp is not a decomp and treats them as separate projects. SymphonyRecomp statically recompiles the original game into code you compile, while the SOTN Decomp project is reconstructing the game as source and, per the README, will become the de facto modern PC port once fully released.

### Is Castlevania: Symphony of the Night being rereleased through SymphonyRecomp?

No. SymphonyRecomp is a recompilation project that requires you to supply a legally owned North American PSX copy of the game in bin/cue format; it does not ship the game itself. The README describes it as an open beta and says stable version 1.0 has yet to be released.

### Why is Symphony of the Night so expensive?

The README does not discuss pricing or the second-hand market for the game. It only requires that you own a North American PSX copy legally, because the build reads your own disc files rather than shipping them.

## Sources

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

---

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