AI Tools10 Min. Lesezeit

Schafft Ihr eigener Computer Untertitel und Sprachaufnahmen?

llama.cpp 0.9.0 ergänzt drei Sprachfunktionen. So prüfen Sie Offline-Transkription, Sprecherzuordnung und Sprecherstimmen auf der vorhandenen Hardware.

K
Ken Jo

Sie haben einen Rohschnitt einer Produktdemo, einen Mitschnitt mit zwei Kollegen und drei Sprecherzeilen, die neu aufgenommen werden müssen. Üblicherweise geben Sie den Mitschnitt an einen Transkriptionsdienst und das Skript an einen Sprachdienst. Wenn beides auf dem Schnittrechner läuft, können wiederholte Korrekturen leichter werden. Das hilft besonders, wenn das Ausgangsmaterial dort bleiben soll. Dafür kümmert sich der Schnitt nun auch um die Warteschlange, die Modelldateien und die Qualitätsprüfung.

Am 4. November 2026 veröffentlichte das quelloffene Inferenzprojekt llama.cpp die Version 0.9.0. Die Version unterstützt die Offline-Transkription mit NVIDIA Nemotron 3.5 Transcribe, Sprachausgabe mit Chatterbox und vordefinierte Pocket-TTS-Stimmen ohne Referenzaufnahme. Die Versionshinweise nennen Transkription in 40 Sprachen, zusätzlichen Kontext über den Prompt und Sprecherzuordnung. Alle drei Änderungen lassen sich im selben Schnittablauf nutzen, stellen aber unterschiedliche Anforderungen an den Rechner und an die prüfende Person. Versionshinweise zu llama.cpp v0.9.0

Wer llama.cpp bei einem lokalen Chatbot kennengelernt hat, könnte den Umfang der Version unterschätzen. Die Inferenzlaufzeit führt unterstützte Modellarchitekturen aus und stellt Werkzeuge zum Laden kompatibler Modelldateien und zur Bearbeitung von Anfragen bereit. Das Update erweitert den Funktionsumfang dieser Werkzeuge. Die umgebende Anwendung entscheidet weiterhin, wo Audio gespeichert wird, wie Korrekturen erscheinen und wann eine Datei veröffentlichungsreif ist. Projekt llama.cpp

Ein Terminalauszug identifiziert den Windows-Build b12110 von llama.cpp, auf den die Version 0.9.0 verweist

Telli.sh hat den offiziellen Windows-Build aus den Versionshinweisen ausgeführt und seine tatsächliche Versionsausgabe gesetzt. Der Auszug bestätigt die Build-Kennung. Verknüpfter Build b12110

Untertitel beginnen mit einem bearbeitbaren Transkript

Eine Kollegin nimmt etwa eine zehnminütige Einführung in ein noch nicht veröffentlichtes Produkt auf. Ein Kollege unterbricht sie, um einen Funktionsnamen zu korrigieren. Sie brauchen ein durchsuchbares Transkript, eine grobe Zuordnung der Stimmen und schließlich Untertitel, die beim richtigen Bild erscheinen. Das sind drei verschiedene Ergebnisse. Das erste ist ein Text, das zweite eine redaktionelle Zuordnung und das dritte verlangt Zeitmarken.

Die Nemotron-Integration deckt die ersten beiden Schritte ab. Die integrierte Implementierung unterstützt Offline-Transkription mit optionalem Kontext und Sprecherzuordnung. Sie kann Sprecherinformationen zwischen Verarbeitungsfenstern einer Aufnahme mitführen. Laut den Änderungsnotizen des Maintainers lagen Zeitmarken für einzelne Wörter und Streaming außerhalb des Umfangs dieser Integration. Transkribieren Sie daher die fertige Aufnahme, korrigieren Sie den Text und richten Sie ihn bei Bedarf in einem separaten Schnitt- oder Untertitelschritt zeitlich aus. Integration von Nemotron 3.5 Transcribe

Eine Aufnahme durchläuft lokale Transkription, menschliche Prüfung und die getrennte zeitliche Ausrichtung der Untertitel

Illustration von Telli.sh. Das lokale Transkript lässt sich bearbeiten. Die Untertitel werden zeitlich ausgerichtet, nachdem Text und Sprecherzuordnung geprüft wurden.

Zusätzlicher Prompt-Kontext hilft möglicherweise bei Begriffen, die im Alltag selten vorkommen. Für eine Aufnahme über eine fiktive Funktion namens Pine Relay können Sie eine kurze Liste erwarteter Namen und Abkürzungen angeben und denselben Ausschnitt danach ohne Liste verarbeiten. Zählen Sie, ob der Kontext den Namen korrigiert, ihn irrtümlich an einer anderen Stelle einfügt oder Zahlen und andere Wörter verändert. Halten Sie die Liste so kurz, dass sich die Wirkung einzelner Einträge nachvollziehen lässt. Der Transkriptionsassistent soll seltene Wörter leichter prüfbar machen, ohne dass das Glossar den Mitschnitt umschreibt.

Die Sprecherzuordnung braucht eine eigene Prüfung. Zwei Stimmen in einem klaren Interview lassen sich möglicherweise leicht unterscheiden. Eine dritte Person über Lautsprecher und einige überlappende Sätze können den Korrekturaufwand verändern. Hören Sie sich die Übergänge und die längsten Beiträge jeder Person an. Im Transkript können alle Wörter stimmen, während eine wichtige Entscheidung der falschen Person zugeschrieben wird. Halten Sie die Modellmarkierungen von den echten Namen getrennt, bis jemand mit Kenntnis der Aufnahme die Zuordnung bestätigt.

Prüfen Sie die exportierten Untertitel im Video. Ein Satz kann im Dokument gut aussehen und im Bild zu lang sein, vor einer wichtigen Enthüllung erscheinen oder stehen bleiben, obwohl bereits jemand anderes spricht. Testen Sie früh einen harten Schnitt und eine kurze Unterbrechung. Sind Untertiteldateien mit verlässlichen Zeitmarken nötig, rechnen Sie Ausrichtung und Korrektur in den Zeitaufwand ein. Ein gutes erstes Transkript ist auch dann nützlich, wenn der endgültige Schnitt in einem anderen Programm entsteht.

Eine vordefinierte Stimme eignet sich für den ersten Test

Betrachten Sie nun die andere Seite des Rohschnitts. Der Name einer Funktion ändert sich, und in sechs Bildschirmaufnahmen muss eine Sprecherzeile ausgetauscht werden. Ist die Einrichtung fertig, lässt sich ein neuer lokaler Versuch günstig erstellen. Die Schwierigkeit liegt in Konsistenz und Aussprache. Der neue Ton soll zu den benachbarten Clips passen, den Produktnamen richtig aussprechen und zur Länge der Einstellung passen.

Version 0.9.0 nimmt Chatterbox in die von llama.cpp unterstützten Sprachausgabemodelle auf. Die Projektprüfung nennt CUDA-Durchläufe mit Chatterbox Turbo und Multilingual V3. Der Reviewer testete Standardstimmen und referenzgestützte Erzeugung und hängte Hörbeispiele an. Das sind Nachweise aus der Integrationsprüfung einer bestimmten Konfiguration. Für den Produktionseinsatz bleibt zu prüfen, ob Stimme und Sprache mit dem tatsächlichen Text und der verwendeten Hardware konsistent bleiben. Chatterbox-Integration und Hörbeispiele des Projekts

Pocket TTS eröffnet einen anderen Weg. Wenn ein kompatibles Modell eingebaute Stimmen enthält, kann es ihre Namen unter voices in der Serverantwort auf GET /props anbieten. Ein Client kann einen gelisteten Namen an den Sprachausgabe-Endpunkt weitergeben. Ein Skript oder eine kleine Anwendung kann die Auswahl damit aus dem geladenen Modell füllen. Für einen ersten Versuch ist also keine Aufnahme einer Person nötig, deren Stimme nachgebildet werden soll. Notieren Sie Modell und ausgewählten Stimmennamen beim Export, damit eine spätere Bearbeitung unter denselben Bedingungen beginnen kann. Vordefinierte Stimmen in Pocket TTS

Ein Sprechtext wird mit einer vordefinierten Stimme erzeugt, angehört und erst nach der Prüfung exportiert

Illustration von Telli.sh. Hören Sie den erzeugten Ton vor dem Export ab. Die Auswahl zeigt, was angefordert wurde. Erst beim Abhören erfahren Sie, was herauskam.

Beginnen Sie mit einem kurzen Skript, das auch Begriffe enthält, die in einer Vorführung leicht fehlen. Ergänzen Sie einen Produktcode, eine Adressform oder eine Zahl mit Einheit und einen Satz, bei dem der Tonfall zählt. Rendern Sie drei einzelne Zeilen und danach den ganzen Absatz. Eine Stimme kann in Einzelsätzen gleichmäßig klingen und im längeren Abschnitt gerade das wichtige Wort übergehen. Bitten Sie jemanden, der die Sprache des Publikums kennt, zunächst ohne Skript zuzuhören und anschließend Gehörtes und beabsichtigten Text zu vergleichen.

Speichern Sie die Endfassung getrennt von Skript und Originalaufnahmen. Wenn sich später eine falsch gesprochene Zahl findet, können Sie die betroffene Aufnahme ersetzen, ohne den ursprünglichen Schnitt zu verlieren. Bei einem Auftrag mit einer autorisierten Sprecherin oder einem autorisierten Sprecher sollten Originalaufnahmen und erzeugte Alternativen klar gekennzeichnet bleiben, damit sie sich nicht unbemerkt gegenseitig ersetzen. Wenn nur eine verständliche, gleichbleibende Stimme gebraucht wird, ist eine Vorgabe ein einfacher Einstieg.

Die Version der Laufzeit ist nur ein Teil der Einrichtung

Wer schon mit llama.cpp arbeitet, kann durch die Version einen Grund weniger für den Wechsel der Laufzeit haben. Sie brauchen trotzdem einen kompatiblen Build, die richtigen Modelldateien und modellspezifische Zusatzdateien wie den multimodalen Projektor aus der Nemotron-Implementierung. Die Modellgewichte sind separat herunterzuladen und unterliegen eigenen Bedingungen. Prüfen Sie die Dokumentation der Laufzeit und des Modells, bevor Sie Teile der Einrichtung an ein anderes Team oder einen Kunden weitergeben. Dateien der Veröffentlichung und Einrichtungshinweise zur Nemotron-Integration

Messen Sie den Speicher während der Arbeit, nachdem das Modell geladen ist. Die Dateigröße sagt, wie viel Speicherplatz die Datei auf dem Datenträger belegt. Die Ausführung braucht außerdem Platz für Berechnungen, Backend-Puffer und Zwischenergebnisse. Ein Desktop kann die Transkription starten und gleichzeitig das Schnittprogramm bremsen, wenn beide die GPU nutzen. Ein Laptop kann beim vierten Versuch langsamer sein, wenn Kühlung und Hintergrundaufgaben eine Rolle spielen. Erfassen Sie Spitzenwerte für RAM und gegebenenfalls Grafikspeicher bei geöffnetem Schnittprogramm in der tatsächlichen Arbeitskonfiguration.

Die Projektverantwortlichen dokumentierten im Nemotron-Pull-Request die Transkriptionsprüfung unter anderem mit klarer Sprache und Besprechungsaufnahmen. Sie nannten die verwendete Quantisierung und eine RTX PRO 6000 Blackwell in der Testumgebung. Das erklärt, wie die Integration geprüft wurde. Für einen Kauf oder Einsatz messen Sie am besten die eigenen Aufnahmen auf dem vorgesehenen Rechner. Selbst mit derselben Hardware können andere Präzision, Sprache oder mehr überlappende Rede das Verhältnis von Laufzeit zu Korrekturaufwand verschieben. Nemotron-Prüfung und Einrichtung

Halten Sie den Versionsvergleich einfach. b12144 vom 6. November ist eine separate Vorabversion mit einer Änderung der CUDA-Datenanordnung für Mixture of Experts. Um die Audiofunktionen zu beurteilen, beginnen Sie mit der nummerierten Version vom 4. November und lassen Sie Modelle und Einstellungen gleich. Testen Sie die Vorabversion später als eigenen Durchlauf. Dann lässt sich unterscheiden, ob sich durch das Audiomodell, das Inferenz-Backend oder die Anwendung etwas geändert hat. Hinweise zur Vorabversion vom 6. November

Definieren Sie bei lokaler Verarbeitung genau, was auf dem Rechner bleibt. Auch wenn der Desktop-Ablauf einen lokalen Server aufruft, kann eine andere Anwendung Protokolle senden, einen Ausgabeordner synchronisieren oder Abhängigkeiten abrufen. Beschaffen Sie Programme und Gewichte vor sensiblen Aufnahmen auf einem Testrechner oder in einem vorgesehenen Einrichtungsschritt. Prüfen Sie dann mit einem unkritischen Clip ohne Verbindung, welche Teile tatsächlich funktionieren. Prüfen Sie auch die Speicherorte für Originaldatei, temporäre Daten und Export. Die lokale Laufzeit begrenzt den Ort der Inferenz, während die übrige Anwendung den gesamten Datenweg bestimmt.

Probieren Sie ein Projekt auf Ihrem tatsächlichen Arbeitsrechner aus

  1. Wählen Sie zwei kurze, freigabefähige Eingaben. Nehmen Sie 30 bis 60 Sekunden mit zwei Personen auf, mit kurzer Überlappung und einem erfundenen Funktionsnamen. Schreiben Sie einen kurzen Sprechtext mit demselben Namen und einer schwierig auszusprechenden Zahl. Lassen Sie die Eingaben für alle Versuche gleich, damit Effekte einer Einstellung sichtbar werden.
  2. Halten Sie Laufzeit und Modelle fest. Wählen Sie den v0.9.0-Build für Ihr System. Dokumentieren Sie Modellquelle, Dateinamen und Quantisierung. Für Nemotron über llama-server nennt die integrierte Änderung --reasoning off, da das Standardtemplate sonst nur die interne Schlussfolgerung statt eines Transkripts ausgeben kann. Die multimodale Kommandozeile braucht den Schalter laut Projekt nicht. Testen Sie den Weg, den Sie später nutzen. Hinweise zur Nemotron-Integration
  3. Messen Sie den Kaltstart und wiederholen Sie den Versuch. Erfassen Sie erst die Zeit vom Start bis zum Ergebnis und dann die Zeit nach dem Laden des Modells. Teilen Sie bei der Transkription die Verarbeitungszeit durch die Audiodauer, um den Aufwand längerer Aufnahmen abzuschätzen. Notieren Sie Speichermaximum und Reaktionsfähigkeit des Schnittprogramms. Bei Sprechertexten ist die Zeit von der Korrektur einer Zeile bis zum Hören der neuen Aufnahme womöglich wichtiger.
  4. Vergleichen Sie Fehler nach ihrem Aufwand. Markieren Sie einen verfehlten Begriff, eine falsche Zahl, eine vertauschte Stimme und einen Satz, dessen Timing geändert werden muss. Rechnen Sie die Korrektur in die Fertigstellungszeit ein. Prüfen Sie bei Sprechertexten Namen, Zahlen, Pausen und den Anschluss an den Schnitt. Vergleichen Sie die fertig korrigierte Datei und das erste Ergebnis.
  5. Bestimmen Sie die Übergabe vor der Automatisierung. Legen Sie fest, wer das Transkript prüft, wo die Untertitel ausgerichtet werden und wie freigegebene Sprachaufnahmen markiert werden. Verwenden Sie nach dem ersten erfolgreichen Versuch einen zweiten Clip. Schlägt eine Datei fehl, bewahren Sie das Original und zeigen Sie den Fehler in der Warteschlange an, damit jemand den Fall übernehmen kann, ohne alle Dateien erneut zu verarbeiten.

Sie können Einrichtung, Verarbeitungszeit, Korrekturzeit und Freigabe in vier Tabellenspalten festhalten. Notieren Sie auch, warum ein Ergebnis abgelehnt wurde. Nach einigen Versuchen eignet sich die lokale Einrichtung vielleicht sehr gut für wiederholte Sprachkorrekturen, während laute Gruppeninterviews einen anderen Ablauf brauchen. Auch das ist ein brauchbares Ergebnis. Verwenden Sie jede Komponente dort, wo sie Zeit spart, und halten Sie fest, wann der Ausweichweg besser funktioniert.

Haben Sie schon eine gute Transkription, vergleichen Sie diese anhand derselben Aufnahme und Freigabekriterien. Es kann genügen, nur den leichteren Teil umzustellen und vorläufige Sprachaufnahmen mit geringem Risiko auf dem Arbeitsrechner zu erzeugen. Umgekehrt kann eine zuverlässige Untertitelproduktion später von einer gemeinsamen lokalen Integration profitieren, wenn es einen Grund gibt, die Modellbereitstellung zusammenzuführen und die neue Implementierung den bisherigen redaktionellen Standard nachweislich erfüllt.

Wo die Version am meisten hilft

Ein guter Einstieg ist eine Aufgabe, die Sie regelmäßig wiederholen. Ein Tutorial-Team kann einen Rohschnitt transkribieren, bevor das Video den Schnittrechner verlässt, und mit einer vorläufigen Stimme das Tempo prüfen. Eine Forscherin kann ein bearbeitbares Transkript einer eigenen Aufnahme erstellen, die Sprecherzuordnung korrigieren und das Audio als Quelle behalten. Ein kleines Entwicklerteam kann beide Wege in einer internen Oberfläche testen, wenn dort das gewählte Modell, das Ergebnis und etwaige Fehler sichtbar sind.

Der größte Nutzen liegt möglicherweise in weniger Übergaben zwischen Spezialwerkzeugen bei weiterhin getrennten Qualitätsprüfungen. Das Transkriptionsmodell muss die Wörter erkennen und Stimmen unterscheiden. Das Synthesemodell muss das Skript richtig aussprechen. Der Schnitt entscheidet, wann das Ergebnis fertig ist. Neu ist, dass diese Aufgaben dieselben Inferenzwerkzeuge und möglicherweise denselben vorhandenen Rechner nutzen können.

Wenn Sie eine fertige Aufnahme später mit Transkript und Notizen wiederfinden möchten, starten Sie einen Upload in Telli.sh.


← Zurück zum Blog