Das Problem
Wer Audio-Artikel anbietet, kennt die Frage: Wie zeigt man dem Zuhoerer, wo im Text sich der Sprecher gerade befindet? Plattformen mit Transkript-Sync loesen das ueber nachtraegliche Spracherkennung. Eine Speech-to-Text-Engine wie Whisper analysiert die fertige Audiodatei und generiert Wort- oder Satz-Timestamps.
Das funktioniert, hat aber Nachteile: Die Verarbeitung kostet entweder Rechenzeit auf dem Server oder Geld bei einem API-Anbieter. Und die Erkennung arbeitet ohne Kenntnis des Originaltexts – sie muss raten, was gesprochen wurde.
OKAYPLAY hat einen strukturellen Vorteil: Der Artikeltext existiert bereits vor der Aufnahme. Sprecher lesen einen vorgegebenen Text ein. Damit laesst sich das Problem umdrehen – statt nachtraeglich zu erkennen, kann die Zuordnung waehrend des Einsprechens passieren.
Der Ansatz: Forced Alignment im Browser
Forced Alignment ist ein Verfahren aus der Linguistik: Man hat einen bekannten Text und eine Audioaufnahme und will herausfinden, welches Wort zu welchem Zeitpunkt gesprochen wird. In der Forschung nutzt man dafuer Server-Tools wie Montreal Forced Aligner, die auf Hidden Markov Models oder neuronalen Netzen basieren.
Fuer OKAYPLAY war die Anforderung anders: Die Zuordnung soll in Echtzeit passieren, im Browser des Sprechers, und keine Kosten verursachen. Die Loesung: Die Web Speech API, die in Chromium-Browsern eingebaut ist.
Architektur
Das System besteht aus drei Schichten:
SpeechRecognitiongegen Artikeltext
pro Voiceover
Schicht 1: Echtzeit-Spracherkennung
Die Web Speech API laeuft parallel zur MediaRecorder-Aufnahme. Beide nutzen denselben Mikrofon-Stream, arbeiten aber unabhaengig voneinander. Die Speech API liefert laufend Zwischen- und Endergebnisse als Text-Fragmente.
var recognition = new (window.SpeechRecognition
|| window.webkitSpeechRecognition)();
recognition.lang = 'de-DE';
recognition.continuous = true;
recognition.interimResults = true;
recognition.onresult = function(event) {
// Gesprochener Text in Echtzeit
var transcript = event.results[...][0].transcript;
matchAgainstParagraphs(transcript, elapsed);
};Schicht 2: Fuzzy Matching gegen den Artikeltext
Der Artikeltext wird beim Start in Absaetze zerlegt. Jeder Absatz wird in normalisierte Wortlisten aufgespalten: Kleinschreibung, Umlaute aufloesen, Satzzeichen entfernen. Die erkannten Worte der Speech API werden gegen diese Listen abgeglichen.
Der Algorithmus prueft immer den aktuellen und die naechsten zwei Absaetze. Sobald genuegend Woerter aus dem naechsten Absatz erkannt werden (Standard: 25% Wort-Ueberlappung), springt der Zeiger weiter. Das ist bewusst grosszuegig – die Speech API erkennt nicht jedes Wort korrekt, aber fuer eine absatzweise Zuordnung reicht eine grobe Uebereinstimmung.
function countOverlap(spokenWords, paraWords) {
var paraSet = {};
for (var i = 0; i < paraWords.length; i++)
paraSet[paraWords[i]] = (paraSet[paraWords[i]] || 0) + 1;
var count = 0, used = {};
for (var i = 0; i < spokenWords.length; i++) {
var w = spokenWords[i];
if (paraSet[w] && (!used[w] || used[w] < paraSet[w])) {
count++; used[w] = (used[w] || 0) + 1;
}
}
return count;
}Schicht 3: Timestamp-Persistenz
Wenn der Sprecher die Aufnahme beendet, werden die Daten als JSON zusammen mit der Audiodatei an den Server geschickt. Pro Absatz wird gespeichert: Index, Startzeitpunkt in Sekunden, ob der Absatz erkannt wurde, und wie viele Worte uebereinstimmten.
// Datenstruktur pro Absatz
{
"index": 3,
"start": 47, // Sekunden ab Aufnahmestart
"matched": true,
"words": 28, // Erwartete Woerter
"matchedWords": 19 // Erkannte Woerter
}Serverseitig landet das in einer paragraph_timestamps JSON-Spalte auf dem Voiceover-Datensatz, zusammen mit einem text_match_score – dem Gesamtprozentsatz korrekt erkannter Woerter.
Zwei Features aus einem System
Das Elegante an diesem Ansatz: Ein einziger Mechanismus liefert gleichzeitig zwei Features, die sonst getrennt gebaut werden muessten.
Live-Highlighting im Teleprompter
Waehrend der Aufnahme wird der Teleprompter automatisch zum aktuellen Absatz gescrollt. Der aktive Absatz wird visuell hervorgehoben, bereits gelesene Absaetze werden gedimmt. Der Sprecher sieht sofort, ob das System ihm folgt – und das System sieht, ob der Sprecher dem Text folgt.
Sprechervalidierung
Der Match-Score gibt einen quantitativen Hinweis darauf, wie genau der Sprecher den Text eingelesen hat. Ein Score von 70–80% ist bei normaler Sprache typisch (die Web Speech API erkennt nicht alles perfekt). Werte deutlich darunter koennen auf Abweichungen vom Originaltext hindeuten – etwa wenn der Sprecher Passagen uebersprungen oder frei formuliert hat.
Player-Highlighting (naechster Schritt)
Die gespeicherten Absatz-Timestamps koennen direkt fuer Playback-Highlighting genutzt werden. Ein Intervall liest currentTime des Audio-Elements und setzt per CSS-Klasse den aktiven Absatz – technisch identisch mit dem Ansatz, den andere Webseiten fuer Transkript-Sync verwenden. Der Unterschied: Die Timestamps wurden nicht nachtraeglich per Whisper generiert, sondern entstehen als Nebenprodukt des Aufnahmeprozesses.
Vergleich der Ansaetze
| Kriterium | Whisper (Server) | Google STT (API) | OKAYPLAY (Echtzeit) |
|---|---|---|---|
| Kosten | Server-GPU oder API | ~0,006€/15s | 0€ (Browser-API) |
| Verarbeitung | Nachtraeglich | Nachtraeglich | Waehrend Aufnahme |
| Granularitaet | Wort-genau | Wort-genau | Absatz-genau |
| Originaltext noetig | Nein | Nein | Ja (Vorteil bei OKAYPLAY) |
| Live-Feedback | Nein | Nein | Ja |
| Validierung | Separate Logik | Separate Logik | Inklusive |
| Browser-Abhaengig | Nein | Nein | Ja (Chromium) |
Grenzen und Kompromisse
Browser-Kompatibilitaet
Die Web Speech API (SpeechRecognition) ist kein W3C-Standard, sondern eine Chromium-Implementierung. Das System ist deshalb als Progressive Enhancement gebaut: Wenn der Browser die API nicht unterstuetzt, funktioniert die Aufnahme trotzdem – es fehlen lediglich die Timestamps und das Highlighting.
Granularitaet
Das System arbeitet absatzweise, nicht wortweise. Wort-genaues Highlighting (wie Spotify-Lyrics) waere mit der Web Speech API nur unzuverlaessig moeglich, weil die Erkennungslatenz zu hoch ist. Fuer Artikel-Audio ist absatzweises Highlighting aber voellig ausreichend.
Erkennungsqualitaet
Die Erkennung haengt von der Mikrofonqualitaet, Umgebungsgeraeuschen und der Sprechgeschwindigkeit ab. Fachbegriffe, Eigennamen oder Bibelverse werden haeufig falsch erkannt. Das ist fuer das Matching kein Problem, weil die umliegenden Woerter trotzdem genuegend Signal liefern.
Datenschutz
Die Web Speech API sendet Audio-Daten zur Verarbeitung an Google-Server (in Chromium). Das passiert unabhaengig von der eigentlichen Aufnahme und betrifft nur den Erkennungsstrom, nicht die gespeicherte Audiodatei. Die Sync-Funktion kann uebersprungen werden, wenn das nicht gewuenscht ist.
Fazit
Die Web Speech API ist nicht perfekt, aber fuer absatzweises Matching in Kombination mit Fuzzy-Abgleich voellig ausreichend. Das Ergebnis: Timestamps ohne Server-Kosten, Sprechervalidierung ohne Extra-Aufwand, und ein Aufnahmeerlebnis, bei dem der Sprecher sieht, dass das System ihm folgt. Progressive Enhancement stellt sicher, dass nichts kaputt geht, wenn der Browser die API nicht unterstuetzt.