Model or dataset
TheDeathDragon/LiveTranslate avatar
TheDeathDragon/LiveTranslate

LiveTranslate: real-time Windows audio translation with a local ASR stage and a remote LLM stage

Real-time audio translation, captures system audio + mic, runs ASR (Whisper/SenseVoice), translates via LLM API with streaming display. Perfect for VTubers, livestreamers, and watching foreign content. Windows 实时音频翻译,ASR 语音识别后 LLM 流式翻译显示,适合 VTuber、主播和外语视频观看。

662 stars49 forksPythonMIT

At a glance

What is it?
LiveTranslate captures WASAPI loopback audio on Windows, runs speech recognition locally, and streams translations from any OpenAI-compatible API into a click-through overlay. It is a Windows-only, GPU-favouring pipeline whose quality depends almost entirely on the translation endpoint you point it at.
Who is it for?
Adopt LiveTranslate if you are on Windows 10 or 11, you have an NVIDIA GPU or are willing to offload ASR to a remote machine over HTTP, and you already pay for or self-host an OpenAI-compatible translation endpoint. Skip it if you need macOS or Linux, if you cannot accept a cloud round trip for translation, or if you want a maintained subtitle file rather than a live overlay.
Can I use it commercially?
Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
Is it still maintained?
Yes. The repository last received commits 29 days ago.
What is it written in?
Mainly Python, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.

DEEP OPEN-SOURCE ANALYSIS

The problem LiveTranslate solves is capture, not translation

Most translation tooling assumes you control the text. LiveTranslate assumes you control nothing except the audio that reaches your speakers. It captures system audio through WASAPI loopback, so a video, a livestream or a voice chat is picked up without any player modification, plugin or virtual cable. The README states this directly: it works with any system audio and needs no player modifications. That is the actual contribution here. The translation step is delegated to an OpenAI-compatible chat API, and the speech recognition step is delegated to one of four local backends. LiveTranslate is the glue that turns an opaque audio stream into text, then into another language, then into pixels on screen.

The audience follows from that. The repository topics list VTubers, livestreamers and foreign-content viewers, and the description names the same three groups. A streamer reading chat in a second language, or a viewer watching a Japanese stream with no subtitles, is the target. A developer building a subtitle pipeline is not: there is no batch mode described, no subtitle file export mentioned, and no headless operation documented. The output is a transparent, always-on-top, click-through overlay with 14 color themes. That is a viewing tool, not a production tool.

Audio to overlay: the five-stage pipeline and where each file sits

The README gives the pipeline in one line: audio at 32ms chunks from WASAPI, then Silero VAD, then ASR, then LLM translation, then the overlay. An optional microphone mix-in feeds into the same audio stage, which matters for anyone who wants their own voice recognised alongside the stream.

The repository layout makes the separation concrete. audio_capture.py handles WASAPI loopback and the mic mix-in. vad_processor.py wraps Silero VAD. The ASR stage is not one file but five: asr_engine.py for faster-whisper, asr_sensevoice.py for SenseVoice, asr_funasr_nano.py for FunASR Nano, asr_anime_whisper.py for Anime-Whisper, and asr_funasr.py as a unified FunASR model selector. translator.py is an OpenAI-compatible client that supports streaming, JSON schema output and context history. subtitle_overlay.py is the PyQt6 overlay and control_panel.py is a seven-tab settings UI. main.py wires the pipeline together.

The design choice worth noting is the VAD gate. Running ASR on every 32ms chunk would be wasteful, so Silero VAD with what the README calls adaptive silence detection decides when speech is present. That gate is also the main source of latency and the main source of errors: a VAD that clips the start of a sentence loses words before the ASR engine ever sees them, and no amount of model quality downstream recovers that. The README does not document the silence thresholds or expose tuning guidance, which is a gap for anyone whose audio has music beds or heavy compression.

Installation is bat-file driven, and the CUDA wheel choice is the fork in the road

There are two documented paths. The portable build is a zip from the Releases page containing LiveTranslate-portable-*.zip; you unzip it and double-click start.bat. On first run it downloads a portable Python 3.12 and installs GPU-aware dependencies. No system Python is required.

From source, the flow is git clone, then double-click install.bat. The installer detects Python 3.10 through 3.12 and can install it via winget, creates a virtual environment, auto-detects an NVIDIA GPU, and asks you to choose CUDA or CPU PyTorch before installing dependencies. Updating is update.bat, which pulls the latest code, updates dependencies, and installs Git via winget if it is missing.

The manual path is documented in a collapsed section and is where the real constraint lives. You create the venv, then pick exactly one PyTorch index URL: cu126 for CUDA, cu128 for CUDA on Blackwell cards such as RTX 50xx, or cpu. Then pip install -r requirements.txt, then run .venv\Scripts\python.exe main.py. Getting this wrong is the most likely failure mode for a first-time user, because the README's own requirements section flags that Blackwell GPUs require CUDA 12.8 while the general recommendation is CUDA 12.6. A 50-series card on the cu126 wheel is a mismatch the installer is meant to catch but the manual path leaves to you.

Configuring the translation endpoint and the models you actually download

Translation is configured in Settings, on the Translation tab, with four parameters: API Base, API Key, Model, and Proxy. The README's example values are https://api.deepseek.com/v1, your key, deepseek-chat, and a proxy setting of none, system or a custom URL. The compatibility list is broad: DeepSeek, Grok, Qwen, GPT, Ollama, vLLM and anything else speaking the OpenAI chat format. Pointing API Base at a local Ollama or vLLM instance keeps translation on your own hardware.

On first launch a setup wizard asks for a download source (ModelScope or HuggingFace) and a cache path, then downloads Silero VAD and SenseVoice, roughly 1GB according to the README. That download is the gate before the main UI appears. Model management is handled by model_manager.py with dual sources, so switching source is a supported path if one is slow or blocked in your region.

Per-model settings are where the translation behaviour is tuned: streaming, structured output as JSON, context history, and a disable-thinking toggle. Streaming is what produces the character-by-character display; disabling thinking matters for reasoning models that would otherwise emit deliberation tokens before the translation. Context history is the trade-off knob. Passing prior lines helps with pronouns and terminology across a conversation, and it also means a mistranslation can propagate into later lines. The README lists these settings without recommending values, so the defaults are the only documented starting point.

Remote ASR is the escape hatch for weak local hardware

The README documents a remote ASR mode: offload speech recognition to a GPU machine over HTTP, implemented in asr_remote.py as a remote Whisper client talking to asr_server.py, with details in REMOTE_ASR.md. This is the most interesting architectural decision in the project, because it splits the pipeline across two machines. Capture, VAD and the overlay stay on the Windows box you are watching on; the expensive inference moves elsewhere.

That split has a cost the README does not quantify. Audio has to leave the local machine, which is fine on a LAN and questionable over anything else, and the network hop adds to an end-to-end latency budget that already includes VAD silence detection, ASR inference and a streaming LLM response. The README does not state a latency target for the pipeline, so there is no number to check your setup against. What the README does confirm is that the remote path is Whisper-specific: asr_remote.py is described as a remote Whisper client, so the SenseVoice, FunASR Nano and Anime-Whisper backends remain local-only. If your source material is Japanese anime or galgame audio, the backend tuned for it cannot be the one you offload.

Windows-only, cloud-dependent translation, and a benchmark you have to run yourself

Three limitations are visible in the material and worth stating plainly.

First, the platform. The requirements list Windows 10/11 and the badge says Windows. WASAPI loopback is the capture mechanism, and it is a Windows audio API. There is no documented path for macOS or Linux, and the installer is a .bat file that uses winget. This is not a portability gap to be worked around; it is the foundation of the capture design.

Second, translation is a network call to a third-party API by default. The README's example is DeepSeek. If your source audio is private, a voice chat for instance, sending the recognised text to a hosted endpoint is a disclosure decision. The Ollama and vLLM entries in the compatibility list are the documented way to avoid that, at the cost of running a capable model locally.

Third, quality claims are unverified here. The README mentions a built-in benchmark in benchmark.py for comparing translation model speed and quality, which is the right tool for the question, but no results are published in the material provided. Anyone choosing between deepseek-chat and a local model has to run that benchmark against their own audio. Similarly, the README gives no word error rate for any ASR backend and no end-to-end latency figure. Treat the backend list as options, not as a ranking.

How LiveTranslate differs from OBS-based subtitle workflows

The obvious alternative for a streamer is the subtitle plugin ecosystem inside OBS Studio, where speech-to-text runs as a filter on an audio source and the result is rendered as a text source in the scene. The difference in approach is structural. OBS plugins live inside the compositor, so the subtitle is part of the broadcast and is captured by the recording or the stream output. LiveTranslate runs as a separate process with its own PyQt6 overlay that is always-on-top and click-through, so the subtitle exists on your screen and not in your output. For a viewer watching a foreign stream, that is exactly right. For a streamer who wants translated subtitles baked into the VOD, it is the wrong shape, because the overlay is not part of the scene graph.

The second difference is the ASR stage. OBS plugins typically bind to one recogniser. LiveTranslate exposes four local backends plus a remote client, and the Anime-Whisper backend exists specifically for Japanese anime and galgame audio, a niche the general-purpose recognisers handle poorly. If your content is that niche, the backend choice is the reason to pick this project over a compositor plugin. If your content is ordinary speech and you want the subtitles in the recording, the plugin is the shorter path.

Maintenance, licensing and what to check before you install

The project is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are included. That is the whole of the licence implication stated in the material; it says nothing about the licences of the four ASR models or the translation APIs you connect to, and those are separate agreements you should read on their own terms. The models are downloaded at runtime from ModelScope or HuggingFace, so their terms arrive with the download rather than with this repository.

On maintenance, the release cadence visible in the material is active: v2026.08.17.1 and v2026.08.17 both landed on 2026-08-17, with v2026.07.11 roughly five weeks earlier. Two releases in one day suggests a fix shipped shortly after a feature. Changelogs are maintained in two languages under i18n/. The update path is update.bat, which pulls code and refreshes dependencies, so the practical upgrade cost is a re-run of that script plus whatever dependency churn the release introduced. Because PyTorch is pinned to a CUDA index URL at install time, a dependency refresh is also the moment a CUDA mismatch can surface, so keep the install log from your first run.

The concrete thing to verify first is the model download. The wizard pulls Silero VAD and SenseVoice, roughly 1GB, before the main UI appears. If that transfer fails behind a proxy or a regional block, you have a non-functional install with no documented offline fallback. Confirm the download source works from your network before you plan around this tool.

Editorial conclusion

Adopt LiveTranslate if you are on Windows 10 or 11, you have an NVIDIA GPU or are willing to offload ASR to a remote machine over HTTP, and you already pay for or self-host an OpenAI-compatible translation endpoint. Skip it if you need macOS or Linux, if you cannot accept a cloud round trip for translation, or if you want a maintained subtitle file rather than a live overlay. Before committing, verify three things: that your GPU is covered by the CUDA 12.6 or 12.8 wheel the installer offers, that your chosen ASR backend actually supports your source language (Anime-Whisper is documented as Japanese anime and galgame material, not general speech), and that the first-run model download of roughly 1GB completes from ModelScope or HuggingFace in your network.

Official sources

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

Community notes