VoiceStudio: Sprachklonen, Synchronisation und Hörbücher komplett auf dem eigenen Rechner

VoiceStudio: 16 TTS- und 11 ASR-Engines unter einer lokalen Oberfläche

VoiceStudio ist der aktuelle Name des Projekts, das unter dem älteren Namen OmniVoice-Studio bekannt wurde. Das Repository debpalash/VoiceStudio ist in Python geschrieben und laut GitHub-Metadaten mit 11913 Sternen und 1876 Forks eine der größeren quelloffenen Sprachanwendungen. Die Lizenz ist AGPL-3.0, der Standardzweig ist main, und die neueste Veröffentlichung trägt die Versionsnummer v0.5.1 vom 28. August 2026. Das README warnt ausdrücklich, dass es sich um eine aktive Beta handelt, und empfiehlt für stabile Arbeit den letzten Release statt des main-Zweigs.

Die Aufzählung in der Übersicht des README liest sich wie eine Programmliste: Sprachklonieren und Sprachdesign, Video-Synchronisation, Diktat, Geschichten, Hörbücher und Stapelverarbeitung. Dahinter stehen laut README 16 TTS-Engines und 11 ASR-Engines, die zusammen einen Katalog von 646 Sprachen für Text-zu-Sprache abdecken. Die tatsächliche Reichweite und Qualität hängt von der jeweils gewählten Engine ab, das Projekt gibt diese Abhängigkeit selbst offen zu.

Zero-Shot-Klonen mit drei Sekunden Referenzmaterial

Der Weg zur ersten Stimme ist im README in drei Schritten beschrieben. Nach dem Start öffnet man den Bereich Voice Cloning, fügt eine saubere Sprachprobe hinzu und wählt Text plus Sprache aus. Drei Sekunden Audio genügen demnach, um ein Ergebnis zu erzeugen, fünf bis fünfzehn Sekunden liefern laut README meist einen besseren Prompt. Das Klonen arbeitet als Zero-Shot-Synthese aus dem kurzen Referenzclip, ohne separates Training.

Daneben gibt es einen Sprachdesign-Zweig, der Stimmen aus Attributen aufbaut: Alter, Akzent, Tonhöhe, Stil und Vortragsanweisungen fließen in die Beschreibung ein. Für die Aufbereitung von Ausgangsmaterial sind Demucs für die Trennung von Stimme und Hintergrund sowie Pyannote und WhisperX für die Zuordnung von Sprechern vorgesehen. Ein KI-Wasserzeichen auf Basis von AudioSeal lässt sich laut Feature-Tabelle einbetten und wieder nachweisen, was für die Kennzeichnung synthetischer Sprache praktisch ist.

Video-Synchronisation und Hörbücher mit M4B-Export

Die Video-Synchronisation folgt laut Feature-Tabelle einer Pipeline aus Transkribieren, Übersetzen, Erhalten der Sprecher, Synthetisieren und Exportieren des Videos. Damit deckt das Werkzeug einen Ablauf ab, der üblicherweise mehrere getrennte Dienste verlangt, und führt ihn in einer Anwendung zusammen.

Für lange Audioformate gibt es einen eigenen Bereich: Geschichten- und Hörbuch-Arbeitsabläufe unterstützen Mehrstimmen-Skripte, den Import von EPUB- und PDF-Dateien, das Rendern nach Kapiteln und den Export als M4B-Datei. Eine Stapelwarteschlange nimmt größere Mengen an Audio- und Videoaufträgen auf und zeigt den Fortschritt pro Auftrag an. Wer zu Betrachtungs- und Bearbeitungszwecken nicht ständig die App wechseln will, findet hier einen Ablauf, der vom Buch bis zur fertigen Kapiteldatei innerhalb von VoiceStudio bleibt.

Architektur: Tauri-Hülle, FastAPI-Sidecar und OpenAI-kompatible Schnittstelle

Die App kombiniert laut README eine Desktop-Hülle mit einem lokalen Python-Backend. Neben der Oberfläche läuft eine REST-, SSE- und WebSocket-Schnittstelle, dazu eine OpenAI-kompatible Audio-API, sodass bestehende Skripte ihre Aufrufe gegen die lokalen Engines und geklonten Stimmen richten können. Ein MCP-Server stellt Synthese- und Transkriptionswerkzeuge für MCP-Clients bereit, was die Einbindung in Agentenumgebungen erklärt, die dieses Protokoll sprechen.

Die Speicherung bleibt laut README standardmäßig auf der Maschine: Stimmen, Projekte, Einstellungen und Ausgaben liegen lokal. Vernetzte Funktionen sind ausdrücklich als Opt-in ausgelegt. Für Ausgaben jenseits des Desktops gibt es optional entfernte Worker, auf denen sich Modelle installieren lassen, mit live angezeigtem Fortschritt. Die GPU-Erkennung wählt automatisch zwischen CUDA, Apple Silicon über MPS und MLX, ROCm unter Linux und der CPU, mit Prüfungen pro Engine.

Plattformanforderungen von Apple Silicon bis glibc 2.39

Die Plattformliste ist präzise. macOS wird ab Version 13.3 auf Apple Silicon unterstützt, Windows 10 und 11 auf x64, Linux auf x86_64 mit glibc 2.39 oder neuer. Installationspakete sind eine DMG für macOS, ein MSI für Windows und ein AppImage für Linux, dazu Docker-Images mit CUDA-, ROCm- oder CPU-Profilen, die auch als reine GPU-Worker betrieben werden können. Beim ersten Start erzeugt die App eine verwaltete Python-Umgebung und lädt das Standardmodell herunter, spätere Starts verwenden beides wieder.

Zwei Sonderfälle nennt das README direkt. Auf macOS verlangt der erste Start eine einmalige Freigabe über Rechtsklick und Öffnen, und Intel-Macs können das lokale Python-Backend nicht ausführen, dort bleibt nur ein entferntes Backend. Wer aus dem Quellcode bauen will, klont debpalash/VoiceStudio, führt bun install und dann bun run desktop aus; für die Browser-Oberfläche gibt es bun run dev. Details liegen in den Installationsanleitungen unter docs/install für jede Plattform.

Diagnose: Selbsttest, Fehlerjournal und Bereinigte-Berichte-Bundles

Für den Fall, dass die Einrichtung scheitert, beschreibt das README einen festen Ablauf. Zuerst läuft der Selbsttest über Settings, About und Run self-check, alternativ über die Kommandozeile mit uv run python backend/main.py --diagnose --deep. Danach verweist die Dokumentation auf die Fehlerbehebung unter docs/install/troubleshooting.md und empfiehlt, beim Erstellen eines Issues ein bereinigtes Diagnose-Paket aus der App zu speichern.

Die Diagnose-Funktionen umfassen laut Feature-Tabelle Selbstprüfungen, ein Fehlerjournal und Protokolle. Bei langsamer Generierung verweist das README auf die gemessenen Werte in docs/benchmarks.md und die Leistungseinstellungen in docs/performance.md. Diese Struktur ist für ein lokal laufendes Projekt sinnvoll, weil Probleme oft von der konkreten Hardware abhängen, und sie erspart Support-Anfragen, die ohne Diagnosedaten ohnehin ins Leere laufen würden.

AGPL-3.0: kommerzielle Nutzung erlaubt, Modifikationen offenlegen

VoiceStudio steht unter AGPL-3.0, und die Lizenz folgt dem Typ der Lizenz für Netzwerkdienste: Wer die Software verändert und die veränderte Fassung über ein Netzwerk anbietet, muss den Quellcode unter denselben Bedingungen verfügbar machen. Das Projekt erklärt die Konsequenz im README so, dass kommerzielle Nutzung möglich bleibt, etwa der Verkauf erzeugter Audiodaten oder der Einsatz im Team, und dass es auf Anfrage eine kommerzielle Lizenz für Einbettungen in proprietäre Produkte gibt.

Ein weiterer Punkt betrifft die optionalen Engines: Sie behalten ihre eigenen Modelllizenzen, wie die Übersichtstabelle ausdrücklich festhält. Wer also kommerziell Audio erzeugt, sollte zusätzlich zu AGPL-3.0 die Lizenzbedingungen der eingesetzten Modelle prüfen, denn die Auswahl im Modellkatalog ändert nichts an den Bedingungen der Modellhersteller.

Fazit: Lokale Kontrolle gegen verwaltete Bequemlichkeit

Die Abwägung, die das Projekt selbst im Vergleichsabschnitt des README anstellt, ist einfach zu fassen. VoiceStudio tauscht verwaltete Rechenleistung gegen lokale Kontrolle: keine Konten, keine Abrechnung nach Nutzung, Offline-Betrieb nach Installation der Modelle, dafür die Verantwortung für Updates, Speicherplatz und Hardware auf der eigenen Seite.

Gut geeignet ist das Werkzeug für datensensible Arbeit, hohe Stückzahlen und Umgebungen ohne Cloud-Zugang, zum Beispiel ein Studio auf einem Apple-Silicon-Mac oder einem CUDA-Rechner. Ungünstig ist es für Nutzer ohne Modellverwaltungslust oder auf Intel-Macs, für die nur der Weg über ein entferntes Backend bleibt. Vor einem ernsthaften Einsatz empfiehlt sich ein kleiner Probelauf: Paket aus dem letzten Release v0.5.1 laden, im Modellkatalog die Ziel-Engine installieren, einen dreißigsekündigen Klonversuch starten und die Laufzeit gegen die Werte in docs/benchmarks.md halten.

Redaktionelles Fazit

VoiceStudio passt zu Nutzern, die Sprachklonen, Video-Synchronisation, Diktat oder Hörbuch-Erstellung offline und ohne Cloud-Abrechnung erledigen wollen und die nötige Hardware mitbringen. Wer einen sofort einsatzbereiten Clouddienst ohne Modellverwaltung sucht, fährt mit einem gehosteten Angebot bequemer. Vor dem Ernstfall lohnt ein Blick auf docs/benchmarks.md für Geschwindigkeitswerte und ein Selbsttest über Settings, About, Run self-check auf der eigenen Maschine.

Offizielle Quellen

1. Official documentation
2. Official README
3. Project repository
4. Release notes