LiveTranslate: an overlay, six ASR backends, and a file tree that stops short

Four batch files carry the entire install story

Windows is not a preference here, it is the install path. The root holds `install.bat`, `start.bat`, `update.bat`, `install.ps1` and `build_release.ps1`, and the setup section walks through them by double-click rather than through a package manager. Cloning is the only command on the page:

git clone https://github.com/TheDeathDragon/LiveTranslate.git
cd LiveTranslate

From there the work moves to the file explorer. `install.bat` detects Python 3.10 to 3.12 and installs it through winget if it is missing, creates a virtual environment, auto-detects an NVIDIA GPU and asks whether to take CUDA or CPU PyTorch, then installs dependencies. `start.bat` launches. `update.bat` pulls the latest code, updates dependencies, and installs Git through winget if Git is missing. Both PowerShell scripts sit next to the batch files, so the same steps have a command-line form that the page never names.

The parallel route is the portable archive. Download `LiveTranslate-portable-*.zip`, unzip it, double-click `start.bat`, and the first run downloads a portable Python 3.12 and installs GPU-aware dependencies by itself. That path is described as requiring no Python installation, which is accurate about the system Python and quiet about the interpreter it fetches instead. Whoever cuts a release also decides what goes into that zip, and `build_release.ps1` is the script that does it.

The architecture listing ends mid-word at model_manager.py

Architecture is drawn twice: once as a flow of stages, then as a file tree. The tree is where the page runs out.

main.py                 Entry point & pipeline
├── audio_capture.py    WASAPI loopback + mic mix-in
├── vad_processor.py    Silero VAD
├── asr_engine.py       faster-whisper backend
├── asr_funasr.py       Unified FunASR model selector backend
├── asr_sensevoice.py   SenseVoice backend
├── asr_funasr_nano.py  FunASR Nano backend
├── asr_anime_whisper.py Anime-Whisper backend (ja anime/galgame)
├── asr_remote.py        Remote Whisper client (→ asr_server.py, see REMOTE_ASR.md)
├── translator.py       OpenAI-compatible client (streaming, JSON schema, context)
├── model_manager.py    Model do

The final annotation is half written. `model_manager.py` is described as `Model do` and nothing follows it, which is where the listing ends. It names eleven files; the repository root has forty-two entries and twenty-three Python modules. Twelve of those modules appear nowhere in the tree: `control_panel.py`, `dialogs.py`, `log_window.py`, `subtitle_overlay.py`, `subtitle_settings.py`, `subtitle_window.py`, `transcript_writer.py`, `benchmark.py`, `i18n.py`, `test_audio.py`, `asr_client.py`, `asr_worker.py` and `asr_server.py`. `config.yaml` sits at the root as well, and no page names a single key inside it.

What the listing does make plain is the shape of the recognition layer. It is five separate modules rather than one switch statement, plus a remote client: faster-whisper, a unified FunASR selector, SenseVoice, FunASR Nano and Anime-Whisper, each in its own file and all reached from the same entry point.

Silero is bundled in the wheel, yet the first launch says it downloads

First launch is three steps. A setup wizard asks for a download source, ModelScope or HuggingFace, and a cache path. Silero VAD and SenseVoice download automatically, about 1GB. The main UI appears when ready.

That first step conflicts with a comment sitting in the dependency list:

numpy>=1.24.0,<2.3
numba>=0.59.0
PyYAML>=6.0
httpx>=0.28.0
openai>=1.0.0
psutil>=5.9.0
PyAudioWPatch>=0.2.12
faster-whisper>=1.0.0
funasr>=1.3.28
silero-vad>=5.0
modelscope>=1.20.0
huggingface_hub>=0.20.0
PyQt6>=6.5.0

The comment attached to `silero-vad>=5.0` says the wheel bundles the Silero v5 model so there is no download from GitHub or torch.hub. The first-launch steps list Silero VAD among the models that download automatically. Both statements cannot describe the same install. Either the roughly 1GB is SenseVoice weights plus something a transitive dependency pulls, or the wizard reports a Silero download that already arrived inside the wheel. A reader cannot tell which from the page, and the difference decides whether the app can run without reaching the model hubs at all.

The wizard's two-hub choice is the other loose end. ModelScope and HuggingFace are both installed as clients, and the dependency file carries a note about VAD deliberately avoiding a torch.hub route, so the offline story depends on which weights end up being fetched from where.

Torch stays out of requirements.txt and needs one of three index URLs

PyTorch is not in the dependency list. A trailing comment says to install it separately with CUDA support and then offers the choice:

pip install torch torchaudio --index-url https://download.pytorch.org/whl/cu126  # CUDA
pip install torch torchaudio --index-url https://download.pytorch.org/whl/cu128  # CUDA (RTX 50xx)
pip install torch torchaudio --index-url https://download.pytorch.org/whl/cpu    # CPU only

The second URL exists for Blackwell cards, and the requirements section states the same split from the hardware side: NVIDIA with CUDA 12.6 recommended, with Blackwell cards such as the RTX 50xx needing CUDA 12.8. The third line is the answer for anyone without an NVIDIA GPU, and choosing it gives up the CUDA acceleration feature without giving up the overlay.

The NumPy ceiling in the same file explains a failure nobody has to guess at. The pin is `numpy>=1.24.0,<2.3`, held below 2.3 so that uv cannot backtrack into Numba and llvmlite releases that do not support Python 3.12. Being written down in place is the right way to handle it, and it also means an existing environment carrying a newer NumPy gets downgraded during install rather than left alone.

The rest of the file is Windows-specific in the same quiet way. `PyAudioWPatch` is what makes WASAPI loopback capture possible, which is why the operating system line is a hard requirement rather than a suggestion.

Six ASR backends, and only one of them has a guide of its own

Recognition is where the pipeline has real variety, and the file list is where it shows. `asr_engine.py` is the faster-whisper backend, `asr_funasr.py` is the unified FunASR model selector, and `asr_sensevoice.py`, `asr_funasr_nano.py` and `asr_anime_whisper.py` cover the rest, the last aimed at Japanese anime and galgame audio. That is five engines running locally.

The sixth is `asr_remote.py`, a remote Whisper client that sends audio to `asr_server.py` over HTTP so recognition can run on a GPU machine, with its own file `REMOTE_ASR.md`. Two things stand out. The remote path is named for Whisper specifically, so nothing on the page says it also carries SenseVoice or the FunASR pair, and `asr_client.py` sits at the root as well without a note explaining how it differs from `asr_remote.py`. The cost is also structural rather than technical: capture, VAD, translation and the overlay on one machine, recognition on another, turns the latency budget into a network budget, which is the whole reason to remote it in the first place.

The upstream projects the page credits are the same set the file names imply, faster-whisper running through CTranslate2, FunASR behind SenseVoice and Fun-ASR-Nano, Anime-Whisper for Japanese, and Silero for voice activity detection.

Four fields on the Translation tab and four switches per model

The translation side is configured in one dialog. Settings, then the Translation tab, exposes four fields: API Base, API Key, Model and Proxy. The example row fills them with `https://api.deepseek.com/v1`, your key, `deepseek-chat`, and a proxy choice of `none`, `system` or a custom URL. The engine list is any OpenAI-compatible API, naming DeepSeek, Grok, Qwen, GPT, Ollama and vLLM, so a local server and a hosted one are the same kind of target.

Per-model settings add four switches: streaming, structured output as JSON, context history, and disable thinking. Each belongs to a model rather than to the application, which is what lets a local Ollama model and a hosted one run side by side with different behaviour from the same dialog. Streaming is what puts tokens on screen character by character instead of sentence by sentence, and structured output is the escape hatch for any endpoint that will not return bare translation text.

What is not written down is where any of it lands. `config.yaml` is at the root of the tree, no key path inside it is given, and the page describes these values as dialog state. Anyone scripting a model switch, or anyone moving settings between machines, has to reverse the format from the source.

Capture runs at 32 ms and the overlay has three unlisted files

The flow is one line, and it is the shortest useful description in the repository:

Audio (WASAPI 32ms) → VAD (Silero) → ASR → LLM Translation → Overlay
         ↑ optional mic mix-in

Thirty-two millisecond chunks come off a WASAPI loopback device, Silero decides what is speech, recognition turns speech into text, the model translates it, and the overlay draws the result. A microphone can be mixed into the recognition input without joining the capture path, which is how someone translates their own voice over a stream they did not produce. The feature line for the detector adds adaptive silence detection on top of the Silero model, so the gate is not a fixed energy threshold.

The overlay is what a viewer actually watches, and it has three modules of its own in the root, `subtitle_overlay.py`, `subtitle_settings.py` and `subtitle_window.py`, none of which appears in the architecture listing. Its feature line is specific about behaviour: always on top, click through, draggable, fourteen colour themes. Click through and draggable sit in the same sentence without an explanation of how they coexist, since a window that passes clicks through does not receive pointer events. Fourteen themes is the only number in that line, and there is no screenshot on the page to show any of them.

A benchmark is advertised and the screenshot section is empty

Two headings promise more than they deliver. The `## Screenshot` heading is followed by nothing at all, and the single visual reference on the page is one bilibili link under `## Video`. The tree does contain a `screenshot/` directory, so the images exist somewhere the page does not reach.

The other is the final feature bullet, a built-in benchmark for comparing translation model speed and quality. `benchmark.py` is at the root of the tree. No command, no settings path, no description of the output and no mention in the architecture listing. It is the only entry in that list whose entry point cannot be found from the documentation, which is an odd gap for the feature that would otherwise be the way to choose a model.

The documentation that does exist sits in the repository: changelogs at `i18n/CHANGELOG_en.md` and `i18n/CHANGELOG_zh.md`, the remote recognition guide at `REMOTE_ASR.md`, a Chinese README at `README_zh.md`, and a `CLAUDE.md`. Releases use a dated scheme, and the two most recent tags, `v2026.08.17.1` and `v2026.08.17`, were published about seventeen minutes apart on the same morning of 2026-08-17. The default branch `main` was last pushed on 2026-08-17, and the license file at the root is MIT.

Editorial conclusion

LiveTranslate solves a narrow problem well on one operating system: it puts a translated overlay on top of whatever is already playing, without touching the player. Everything that makes it usable is concrete, WASAPI loopback capture, six ASR backends, an OpenAI-compatible client, a 32 ms chunk budget, and a portable zip for people without Python. The cost of that focus is documentation. The architecture listing stops mid-word, twelve of the twenty-three Python modules at the root never appear in it, the advertised benchmark has no entry point, and the dependency file and the first-launch steps disagree about whether Silero is downloaded or bundled. Someone following the page top to bottom will end up with a working overlay. Anyone planning to build on it should read config.yaml and the unlisted modules before assuming anything.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. TheDeathDragon/LiveTranslate on GitHub