Discord voice bot

The problem

I wanted to understand voice cloning up close, and the way to understand it is to build it. The scope was deliberately tight: run on CPU, with no GPU and no paid service, inside a Discord bot my friends would actually use.

Running on CPU is not a cost-saving detail. It is the constraint that defines the project: it changes which model is usable, it changes how much reference audio is needed, and it changes what counts as acceptable latency.

Technical decisions

Consent before code

Against what: cloning the voices of people on the server and apologising later, which is the natural path of a weekend project.

A voice is biometric data, and under Brazilian data protection law it is personal data; the model licence also forbids use without explicit consent. So the rule was written into the README itself, ahead of the setup instructions: ask permission in the group before recording.

What it cost: the project became dependent on people saying yes, which is slower than pulling audio from an old call recording. And it limited the voice set to those who agreed.

No voice, audio or history enters the repository

Against what: versioning the prepared voices alongside the code, which would be far more convenient to reinstall.

The voices (.safetensors, ~270 MB), the audio samples, the generated output and the log of who said what are all kept out of version control, by an explicit rule in .gitignore.

What it cost: anyone cloning the repository gets nothing that works: they have to record their own samples and redo the preparation. Reproducibility dropped on purpose, because the alternative is publishing someone else’s biometric data in a repository.

Two separate Python environments, and the separation is mandatory

Against what: a single requirements.txt, which is what anyone would try first.

The bot runs on the system Python; audio preparation runs in a virtualenv with Python 3.11 and pinned versions.

What it cost: a two-step setup with an explanation attached, which is terrible for a newcomer. But the pinning is not superstition: deepfilterlib only publishes a wheel for 3.11, torchaudio 2.2 removed a module the audio-cleanup library imports, and setuptools 81 removed the pkg_resources another dependency needs. Every pinned version is pinned for a reason written next to it, because the alternative is someone upgrading in good faith and breaking everything without knowing why.

What was left out

The bot does not use FFmpeg; only the preparation tools do. And there is no database and no web framework: it is three Python files. The scope was kept small on purpose, because the goal was to understand the model, not to build a product.