VR Prosodic Speech Analysis System

01

Messen, wie jemand spricht

Wie jemand während einer VR-Übung spricht, verrät etwas, das der reine Aufgabenscore nicht erfasst.

Wenn jemand in VR eine simulierte Prozedur durchgeht, weiß das System bereits, ob die Schritte erledigt wurden. Es weiß nichts darüber, wie die Person dabei geklungen hat. Tonhöhe, Lautstärke, Tempo und Pausen liefern diese Information. Ich wollte daraus eine Zahl machen, während die Übung noch läuft.

Eine feste Schwelle funktioniert nicht. Wenn ich sage, alles über 180 Hz oder 70 dB gilt als erhöht, misst das System am Ende die Person statt ihren Zustand. Wer von Natur aus laut spricht, überschreitet diese Linie schon im ruhigen Zustand. Wer leise spricht, überschreitet sie selbst unter echtem Druck nie. Eine feste akustische Schwelle müsste auf unterschiedliche Stimmen passen. Ich wollte aber eine Veränderung innerhalb derselben Stimme erkennen.

• Hardware Ein Windows-PC, Meta Quest 3 über Quest Link, Ton vom virtuellen Oculus-Mikrofon mit 16 kHz mono
• Interaktion Eine Controller-Taste: gedrückt halten zum Aufnehmen, loslassen zum Auswerten
• Grenze Keine Audioanalyse in C# nachgebaut. Eine Umsetzung, in Python
• Latenz Die Auswertung kommt zurück, während die Übung noch läuft
• Grundsatz Lieber nichts zurückgeben als einen schlechten Score

02

Zwei Referenzaufnahmen statt einer festen Schwelle

Jede Person bekommt eine eigene Skala. Beide Endpunkte werden aus ihrer Stimme bestimmt.

Vor der Übung nimmt jede Person zwei kurze Sätze auf. Den ersten spricht sie in normalem Ton als Baseline, den zweiten deutlich dringlicher als Upperline. Der Abstand zwischen den beiden Aufnahmen bildet für jedes Merkmal den persönlichen Bewertungsbereich.

Spätere Aufnahmen werden innerhalb dieses persönlichen Bereichs eingeordnet: null entspricht der Baseline, eins der Upperline. Eine laute und eine leise sprechende Person erhalten denselben Score, wenn sie sich relativ zu ihren eigenen Referenzen gleich stark in Richtung Dringlichkeit verändert haben.

Besonders wichtig war mir, das Vorzeichen der Spanne beizubehalten. Die meisten Menschen sprechen schneller, wenn sie Dringlichkeit ausdrücken; ihre Upperline der Artikulationsrate liegt also über ihrer Baseline. Manche sprechen stattdessen langsamer und bedachter. Die Formel behandelt das nicht als Fehler, der korrigiert werden müsste. Sie behält die Richtung, die diese Person tatsächlich gezeigt hat. Die Spanne ist dann einfach negativ, und der Fortschritt darauf wird genauso berechnet.

raw_progress = (
  current_number - baseline_number
) / gap

# Baseline'ın ters yönündeki değişim panik puanı üretmez.
score_progress = max(raw_progress, 0.0)

# Upperline'ı aşmak mümkündür. 1.25 sınırı, tek özelliğin
# bütün skoru aşırı şişirmesini engeller.
score_progress = min(score_progress, 1.25)

weighted_progress += score_progress * weight
used_weight += weight

Der Score wird aus sechs Merkmalen berechnet. Jedes hat ein Gewicht und eine Mindestspanne. Die Mindestspanne ist der kleinste Abstand zwischen den beiden Ankern einer Person, der noch als echter Unterschied zählt und nicht als Rauschen.

Für die zeitliche Auswertung nutze ich die Wortzeitstempel von Faster-Whisper statt einer energiebasierten Sprachaktivitätserkennung. Energiebasierte VAD kann eine Pause nicht von einem stillen Raum unterscheiden, und ein verrauschtes Signal vom Headset-Mikrofon erschwert die Erkennung zusätzlich. Wortgrenzen aus dem Transkript sind eine deutlich bessere Grundlage dafür, zu sagen, wo das Sprechen tatsächlich aufgehört hat. Silben werden über das Zählen türkischer Vokale genähert. Das ist eine dokumentierte Näherung und kein echter Silbentrenner, und sie reicht, um eine Person mit sich selbst zu vergleichen.

Das System ist bewusst in zwei Schichten gebaut, mit einer HTTP-Brücke dazwischen.

Diese Trennung ist sinnvoll, weil die gesamte Messung in Python bleibt. Zu Praat, librosa und Faster-Whisper gibt es in C# kein Gegenstück. Einen Teil davon in das VR-Projekt zu portieren hätte eine zweite Umsetzung der Messung erzeugt, und ich hätte beide dauerhaft aufeinander abstimmen müssen.

03

Irreführende Scores vermeiden

Ein großer Teil der Entwicklungsarbeit steckt in der Entscheidung, wann kein Ergebnis ausgegeben werden darf.

Einer Zahl auf einem Bildschirm vertraut man schnell. Deshalb muss klar sein, wann das System überhaupt eine ausgeben darf. Die folgenden Prüfungen sind für mich der wichtigste Teil dieser Entwicklung.

Die Prüfung auf Merkmalsebene ist die wichtigste. Unterscheiden sich Baseline und Upperline bei einem Merkmal nicht ausreichend, liefert es keine Information über die Veränderung dieser Person. Vielleicht hat sie beide Male auf derselben Tonhöhe gesprochen. Dieses Merkmal würde nur Rauschen in die Bewertung bringen. Deshalb wird es ausgeschlossen. Die übrigen Merkmale, bei denen ein Unterschied erkennbar ist, werden neu gewichtet und zum Score verrechnet.

Fallen zu viele Merkmale weg, reicht das Profil nicht mehr für eine Bewertung. Bleiben weniger als zwei Merkmale oder liegt ihr Gesamtgewicht unter 0.40, wird die Kalibrierung abgelehnt. Die Referenzaufnahmen müssen dann wiederholt werden.

Die Aufnahmequalität wird vor all dem geprüft. Clipping bei einer Spitze von 0.99 oder darüber, eine Spitze unter 0.02 oder weniger als 20% stimmhafte Frames lösen jeweils eine Warnung aus. Es gibt noch eine feinere. Meldet die Sprachaktivitätserkennung, dass 98% oder mehr des Fensters aktives Sprechen sind, ist das meist ein lauter Raum, der als durchgehendes Reden gehört wird, und die daraus abgeleiteten Zeitmerkmale sind nicht vertrauenswürdig.

if speech_window > 0:
  active_ratio = active_duration / speech_window

  if active_ratio >= 0.98:
      warnings.append(
          "Kayıdın neredeyse tamamı aktif konuşma olarak algılandı. "
          "Gürültü nedeniyle VAD/sessizlik tespiti güvenilir olmayabilir."
      )

Eine Prüfung mag ich noch besonders. Der Kalibriersatz selbst wird verifiziert: das Transkript dessen, was die Person gesagt hat, wird mit dem Satz verglichen, den sie sagen sollte. Eine Baseline, die aufgenommen wurde, während jemand mit der Person nebenan geredet hat, sollte nicht stillschweigend zur Referenz werden, an der jeder spätere Score gemessen wird.

04

Das fertige System

Vom Tastendruck bis zum Score läuft alles auf einem Rechner.

Die Analyse-Engine läuft auch ohne angeschlossenes Headset. So habe ich sie entwickelt und kann sie weiterhin testen: Eine WAV-Datei und ein Satz reichen, um die gesamte Analyse auszuführen. Die VR-Schicht startet nur die Aufnahme und zeigt das Ergebnis an.