Der größte Teil der Verzögerung bei Live-Übersetzungen ist Warten: auf den Stream, auf das nächste Wort, auf den Satz. Den einen Teil, den Sie steuern können, bildet der Latenzmodus: weniger Verzögerung oder weniger Korrekturen.
Ein Zuhörer, der eine Live-Übersetzung liest, sieht jede Zeile einige Sekunden nach dem Satz des Sprechers. Diese Verzögerung besteht nicht aus einem einzigen Schritt, sondern aus mehreren, die sich entlang einer Kette addieren, und die meisten davon sind eine Form des Wartens. Wer weiß, welches Warten wozu gehört, kann den Latenzmodus leicht wählen und erkennt, was ein Entwickler im Reader anzeigen sollte und wann.
Als Maßstab vorab: Ein menschlicher Simultandolmetscher spricht üblicherweise zwei bis vier Sekunden hinter dem Sprecher. Dolmetscher nennen diesen Abstand die Ohr-Stimme-Spanne. Bei Sprachen mit Verb am Satzende warten sie nicht auf das Verb, sondern nehmen es vorweg oder zerlegen den Satz in Teile, die für sich allein stehen können. Eine oder zwei Sekunden Verzögerung sind deshalb kein Mangel der Software; sie entsprechen ungefähr dem, was ein sehr guter Mensch leistet.
Jede Live-Transkription auf VocalStack durchläuft dieselben Stufen in derselben Reihenfolge, und jede wartet auf die vorherige.
Der Originaltext erreicht den Leser fast so, wie er gesprochen wird. Die Übersetzung folgt ein bis zwei Sekunden später, und der gesprochene Satz kommt nach seiner Übersetzung, weshalb ein Sprachclip immer als Letzter ankommt. Die erste sichtbare Wirkung der Kette tritt jedoch lange vor jeder Stimme ein: Der Text selbst bewegt sich.
Als Erstes fällt bei einem Live-Transkript auf, dass sich die neuesten Wörter bewegen. Eine Wortgruppe erscheint, ändert sich und setzt sich schließlich fest. Das ist die Entwurfsstufe am Werk, und sie existiert aus einem Grund, der für jeden Spracherkenner gilt.
Ein Erkenner legt die Schreibweise eines Wortes fest, indem er auf das schaut, was danach kommt. „I scream“ und „ice cream“ klingen gleich, bis das nächste Wort kommt; ein angehängtes „s“ kann zu diesem Wort oder zum nächsten gehören. Solange rechts von einem Wort kein Audio liegt, ist seine Schreibweise eine Vermutung. Deshalb sind die neuesten Wörter in jedem Live-Transkript immer die unsichersten. Ein Entwurf ist schlicht diese Vermutung, die früh gezeigt statt verborgen wird.
Jeder Entwurf ersetzt den Live-Bereich am Ende vollständig: die Wörter, die seit dem letzten Commit gehört wurden und sich noch ändern. Ein Commit ist endgültig. Er ändert sich nie, trägt Zeitstempel auf Wortebene, und Commits sind lückenlos nummeriert, damit ein Leser merkt, wenn ihm einer fehlt.
Für Entwickler ist das die eine Regel, auf die die Realtime-API besteht: Rendern Sie jedes committete Segment, dann den neuesten Entwurf danach, und löschen Sie den Entwurf, sobald ein Commit eintrifft. Entwürfe anzuhängen statt sie zu ersetzen, erzeugt doppelten, flackernden Text; der Commit verbraucht einfach das Ende. Das WebSocket-Tutorial baut einen Reader genau darauf auf.
Für einen Gastgeber ist bewegter Text der Preis für niedrige Verzögerung. Wörter zu zeigen, bevor der Satz fertig ist, macht das Transkript lebendig. Die Übersetzung kann sich diesen Trick jedoch nicht leisten, denn ein Wort lässt sich aus einem halben Satz erraten, eine Übersetzung nicht.
Die Wortstellung ist der Grund, warum die Übersetzung nicht mit dem Entwurf Schritt halten kann. Ein deutsches Verb kann am Ende seines Satzes stehen, und im Japanischen steht das Verb ganz am Schluss. Jeder Übersetzer braucht den ganzen Satzteil, bevor er ihn treu wiedergeben kann. Wort für Wort zu übersetzen liefert dem Zuhörer Fragmente, die beim Satzende erst noch zusammengelesen werden müssen. Dolmetscher warten im Deutschen seit jeher auf das Verb, lange bevor Software es versuchte.
VocalStack übersetzt deshalb Sätze, nicht Segmente. Sätze sind standardmäßig aktiviert; mit ihnen fasst der Server Commits zu einem Satz zusammen und übersetzt den ganzen Satz. Solange der Satz offen ist, ist seine Übersetzung vorläufig; sobald er schließt, ist die Übersetzung endgültig. Ein Reader hält einen Eintrag pro Satz und ersetzt ihn, wenn Aktualisierungen eintreffen.
Die Stimme wartet noch länger. Nur ein abgeschlossener Satz wird gesprochen, denn ein Satz, der sich noch ändert, würde bei jeder Korrektur neu synthetisiert. Ein langer Satz wird in Teilen vorgelesen, damit der erste Teil abgespielt werden kann, während die übrigen entstehen.
Bei ausgeschalteten Sätzen bekommt stattdessen jeder Commit seinen eigenen Übersetzungsrahmen. Dieser Weg wartet auf nichts, aber ganze Sätze lesen sich weit besser.
Alle diese Wartezeiten werden ab dem Moment gemessen, in dem das Audio VocalStack erreicht. Bei vielen Übertragungen war das Audio schon verspätet, als es ankam.
Wenn die Quelle ein Stream statt eines Mikrofons ist, liegt das Audio schon zurück, bevor überhaupt transkribiert wird. Es hinkt dem Live-Rand hinterher, dem neuesten Moment, den der Stream veröffentlicht hat.
Ein einfacher HTTP-Audiostream, wie ihn die meisten Internetradiosender veröffentlichen, liegt typischerweise ein bis drei Sekunden zurück. Der Server führt einen Burst-Puffer: einige Sekunden jüngsten Audios, auf einmal gesendet, damit der Player eines neuen Zuhörers ohne Stocken starten kann. Jeder Zuhörer, VocalStack eingeschlossen, steigt so weit zurück ein. HLS ist schlimmer: Seine Playlists starten einen Client drei Segmente hinter dem Live-Rand, was je nach Segmentlänge in der Praxis mehrere Sekunden bis eine halbe Minute bedeutet. Standard-DASH liegt meist im selben Bereich wie HLS; nur die Low-Latency-Variante liegt deutlich darunter. Das „Live“ eines Senders kann so live sein, wie ein Brief aktuell ist.
Diese Angaben sind ungefähr, und sie gehören zum Stream, nicht zur Transkription: Keine Einstellung auf Seiten von VocalStack holt sie zurück. Wenn diese Sekunden bei einer Veranstaltung zählen, speisen Sie das Audio von einem Mikrofon oder einem Encoder statt von einem öffentlichen Stream ein. Die Stream-Verzögerung steht fest, bevor VocalStack ein Wort hört; der Latenzmodus ist das, was Sie tatsächlich verändern können.
Der Latenzmodus hat nur eine Aufgabe: Er legt das Gleichgewicht zwischen Verzögerung und Genauigkeit fest. Die Einstellung steht unter Advanced, wenn eine Live-Transkription angelegt wird, und im Speed-Tab, während sie läuft. Dort zeigt der Chip AUTO, SPEED oder ACCURACY an (Fast erscheint als SPEED). Über die API ändert session.update den Modus während des Streams.
Der Kompromiss ist der, den die Namen nahelegen. Fast bringt Text früher heraus, muss aber mehr davon korrigieren; Accuracy braucht etwas länger und korrigiert weniger. Ein sitzendes Publikum, das übersetzte Untertitel liest, bemerkt selten eine zusätzliche Sekunde, wohl aber Wörter, die sich ständig ändern. Accuracy ist deshalb oft die angenehmere Einstellung, solange das Verzögerungsdiagramm flach bleibt. Auto zeigt, was es tut: Eine Zeile, die es beschleunigt hat, um eine Lücke zu schließen, trägt im Transkript des Gastgebers das Abzeichen FAST MODE, mit dem Hinweis, dass die Genauigkeit dort geringer sein kann.
Unabhängig vom Modus muss die Transkription vor dem ersten Wort bereit sein, und dieses Bereitmachen ist die einzige Verzögerung, die die Kette nur einmal zahlt.
Bei manchen Tarifen braucht eine Live-Transkription einige Sekunden zum Starten. Wie lange, hängt vom Tarif ab: Die Zeile Start-up speed auf der Preisseite reicht von einem Kaltstart von bis zu 15 Sekunden bei Pay as you go bis zu immer warm bei Enterprise.
Über die API zeigt sich die Wartezeit als session.loading-Frames, während die Sitzung startet, danach kommt ein session.ready; der Client sendet Audio erst danach. Ein Zuhörer, der den Link in der Zwischenzeit öffnet, sieht „Live. The first line appears in a moment.“ Sobald die Transkription läuft, liegt diese Verzögerung hinter Ihnen, und es bleibt nur die Frage, wie viel der restlichen Verzögerung Sie mitschleppen.
Während eine Live-Transkription läuft, zeigt der Speed-Tab des Gastgebers, was all dies zusammen ergibt: die aktuelle Lücke zwischen Sprecher und Text, mit dem Modus-Chip daneben, und ein Diagramm dieser Lücke über die ganze Aufnahme mit Durchschnitt und Spitzenwert. Im Transkript selbst trägt eine Zeile, die die Zuhörer spät erreichte, ein Abzeichen mit der Anzahl Sekunden zwischen dem Sprechen und dem Eintreffen.
Ein Diagramm, das niedrig und flach bleibt, zeigt, dass der Modus zum Audio passt. Ein steigendes Diagramm bedeutet, dass die Pipeline zurückfällt. Bei Accuracy kann das der Moment sein, zu Auto zu wechseln, das etwas Genauigkeit gegen Tempo tauscht, bis die Lücke sich schließt.
Entwickler bekommen stattdessen eine einzige Zahl. Wenn eine Realtime-Sitzung endet, enthält session.done stats.realtimeFactor: die transkribierte Audiolänge geteilt durch die Zeit, die für das Transkribieren aufgewendet wurde. Eine Konventionswarnung: In der Spracherkennungsliteratur bedeutet Real-time factor meist das Gegenteil, also Verarbeitungszeit geteilt durch Audiozeit, wobei niedriger besser ist. VocalStack gibt es andersherum aus, hier gilt also: Höher ist besser. Eine Live-Sitzung liegt nahe 1, und unter 1 heißt, dass Audio schneller ankam, als die Pipeline es transkribieren konnte.
Keine dieser Sekunden ist rätselhaft. Manche gehören zum Stream, manche zu einem Wort, das auf das nächste wartet, manche zu dem Satz, den eine Übersetzung braucht, und der Rest zu dem Latenzmodus, den Sie gewählt haben. Die API-Referenz enthält die Details Frame für Frame, und die Demo auf der Startseite zeigt die Kette in Aktion.
