so-vits-svc-fork: a discontinued realtime singing voice conversion fork

What the fork changed in so-vits-svc

The upstream project is a singing voice conversion system built on SoftVC and VITS. The fork, based on branch 4.0 (v1) or 4.1 and model-compatible with those branches, lists its own additions plainly: realtime voice conversion, enhanced in v1.1.0; a partial integration of QuickVC; a correction to what the README calls a misuse of ContentVec in the original repository; more accurate pitch estimation using CREPE; a GUI and a unified CLI; roughly twice the training speed; and a pip-installable package that downloads pretrained models automatically and removes the need to install fairseq. The audience is narrow and specific. It is someone who wants to sing or speak into a microphone and hear a target voice come back, or who has a dataset and wants to train a conversion model without assembling a fairseq environment by hand. It is not a text-to-speech system, and it is not a general voice cloning service. The README's own framing is a singing voice conversion fork, and the realtime mode is the feature that distinguishes it from the branch it forked.

The mechanism: ContentVec features, CREPE pitch, VITS decoding

The pipeline visible in the material runs in three stages. ContentVec supplies the content representation, and the fork states it fixed a misuse of ContentVec present upstream, citing issue 206 as the reference. CREPE supplies pitch estimation, which the README describes as more accurate than what the original used. VITS then decodes those features into audio. QuickVC is partially integrated, which the README lists as a feature without describing the extent of the integration. For realtime operation the same feature extraction and decoding path has to run on a continuous input stream rather than on a file, which is why the README separates realtime support from the offline path and why latency is the constraint that matters there. The README does not publish latency figures, buffer sizes, or block lengths, so the realtime claim cannot be quantified from the supplied material. Training is described as roughly twice as fast as the original, again without a benchmark table or hardware specification, so treat that as a claim rather than a measured result.

Installing it: pipx, pip, and the torch index URL

The README gives three installation routes. The first is a Windows install.bat attached to release v1.3.2, which it says performs the manual steps automatically. The second is pipx, which the README labels experimental. On Windows it asks for the development version of pipx because of pypa/pipx#940, then installs the package and injects torch and torchaudio from the CUDA 12.1 wheel index:

pipx install so-vits-svc-fork --python=3.11 pipx inject so-vits-svc-fork torch torchaudio --pip-args="--upgrade" --index-url=https://download.pytorch.org/whl/cu121

The third route is a plain virtual environment on Python 3.11, followed by upgrading pip, setuptools and wheel, installing torch and torchaudio from the same index URL, and then installing so-vits-svc-fork itself. The README notes that installing without a virtual environment can raise a PermissionError when Python lives under Program Files, and that on a machine without a GPU, or on macOS, the torch line should be dropped or pointed at a different index. Python 3.11 is the pinned version across all three routes. The repository is packaged with uv and ruff and runs pre-commit, so the development toolchain is modern even though the README says maintenance has been limited since Spring 2023.

The 4.0 checkpoint boundary is the first thing to check

Model compatibility is the sharpest constraint in the README. It states that the fork is based on branch 4.0 (v1) or 4.1 and that models are compatible, then immediately states that 4.1 models are not supported. Read together, those two sentences mean the supported checkpoint format is the older one, and anything produced by the 4.1 line will not load. The README also says other models are not supported, which rules out mixing in checkpoints from unrelated voice conversion projects. This is not a subtle failure mode. A user who downloads a recent community checkpoint and expects it to work will find that it does not, and the error will surface at load time rather than at install time. The practical consequence is that the fork's usable ecosystem is frozen at whatever 4.0-format checkpoints already exist, and no new ones are being produced by this project.

Alternatives, and how they differ in approach

The README's own alternatives section is unusually direct. It lists the RVC family first: IAHispano/Applio under MIT and described as actively maintained, fumiama's RVC under AGPL, and the original Retrieval-based-Voice-Conversion-WebUI under MIT and no longer maintained. The difference in approach is retrieval. RVC retrieves features from a reference index at inference time rather than relying only on a trained decoder, which is a different architecture from the ContentVec plus VITS path used here. VCClient, under MIT and similar terms, offers a web-based GUI for realtime conversion, so it competes directly with the fork's realtime mode while moving the interface into a browser; the README notes it is not quite actively maintained. yxlllc/DDSP-SVC and yxlllc/ReFlow-VAE-SVC are listed as issuing releases occasionally, and DDSP-SVC takes a different synthesis route entirely. fish-diffusion and coqui-ai/TTS are named for their modularity, with coqui-ai/TTS noted as unmaintained. The README also warns readers to be sceptical of social media enthusiasm about new voice projects, and observes that the 2023 voice changer boom has ended with many developers, not only in this repository, going quiet.

Why the project stopped, and what that means for upgrades

The README devotes a section to the reasons it is no longer maintained, and they are worth reading as engineering history. It says the technology evolved enormously within a year and better alternatives exist; that the author hoped to build a more modular, easy-to-install repository but lacked the skills, time and money; that PySimpleGUI is no longer LGPL; and that Typer has become more popular than using Click directly. Two of those four reasons are dependency and tooling shifts rather than model quality. PySimpleGUI losing its LGPL status affects the GUI path specifically, which is one of the fork's advertised features. The maintenance cost picture is therefore not a slow drift but a set of concrete blockers, and the release history is consistent with it: v4.2.28 and v4.2.29 landed a day apart in October 2025, v4.2.30 followed in February 2026, and the last push to the default branch is dated September 2026. The repository is not archived, so it remains readable and installable, but the README's own statement that updates have been limited to maintenance since Spring 2023 should set expectations for how quickly a broken dependency will be fixed.

Licence status is unresolved in the supplied metadata

The repository metadata reports the licence as NOASSERTION, which means the automated classifier could not match the licence file to a known identifier. The README does not state licence terms for this fork. It does state the licence of several alternatives it recommends, including MIT for IAHispano/Applio and the original RVC, and AGPL for fumiama's RVC, which is a notable distinction: AGPL imposes source disclosure obligations that MIT does not. For the fork itself, the only defensible statement is that the terms are not established by the material available here. Anyone intending to redistribute the package, ship it inside a product, or publish converted audio commercially needs to read the licence file at the repository root and, where the terms are ambiguous, seek their own legal advice. This article cannot resolve that question, and the NOASSERTION value should be treated as a prompt to look rather than as a finding either way.

A narrow case where the fork still fits

The fork's remaining value is concentrated in one situation. You have 4.0-format checkpoints, you want a GUI and a unified CLI over the same codebase, and you want to run conversion offline on your own machine without building a fairseq environment. The pip route and the automatic download of pretrained models remove the setup work that the original required, and the CREPE pitch path plus the ContentVec correction are concrete changes rather than interface polish. Outside that situation the calculus shifts. If you need realtime latency that you can measure and rely on, the README publishes no latency numbers, so you would have to benchmark it yourself before committing, and VCClient is the alternative that targets the same use case with a web interface. If you need new checkpoints, this project will not produce them. If you need active maintenance, Applio is the option the README itself names as actively maintained. The honest summary is that this fork is a well-packaged snapshot of a 2023-era approach, useful for reproducing work in that format and unsuitable as a foundation for anything new.

Editorial conclusion

Adopt so-vits-svc-fork only if you already hold 4.0 checkpoints and need offline conversion with a GUI on a single machine. Do not adopt it for new production work, and do not start a new training run on it: the README states the project is no longer maintained, updates have been limited to maintenance since Spring 2023, and 4.1 models are explicitly unsupported. Before installing anything, verify that your checkpoint directory contains 4.0 config and weights rather than 4.1, and read the licence file at the repository root, since the metadata reports NOASSERTION and the README does not state terms.

Official sources

1. Issues
2. README
3. Releases
4. voicepaw/so-vits-svc-fork on GitHub