Der Recognizer muss weder deine Tastatur noch die Klimaanlage hören, und auch nicht die drei Sekunden Stille, in denen du nachdenkst.
Voice Type nutzt einen streaming-fähigen Silero-Voice-Activity-Detector, um zu entscheiden, welche Teile des Mikrofonstreams Sprache sind. Alles Nachgelagerte, darunter die Länge jedes Batches und der Zeitpunkt, zu dem das Modell läuft, ergibt sich daraus, was dieses Gate markiert.
Eine Korrektur. Eine frühere Version dieser Seite hat behauptet, Voice Type verwende RNNoise. Das tut es nicht, und das hat es auch nie getan. Die App hat RNNoise nie ausgeliefert, und die Behauptung war schon bei der Veröffentlichung falsch. Das Gate ist Silero, und die Einstellungen unten sind die, die tatsächlich ausgeliefert werden. Wenn du über eine Suche nach RNNoise hierhergekommen bist, ist der nächste Abschnitt für dich.
RNNoise, und warum es nicht das Gate ist
RNNoise ist ein rekurrentes neuronales Netz zur Rauschunterdrückung, veröffentlicht von Xiph.Org unter einer BSD-Lizenz. Es ist klein, schnell und wirklich gut in dem, was es tut: Es nimmt verrauschte Sprache und gibt sauberere Sprache zurück. Es steckt in vielen Sprachanwendungen, und die Version, der die meisten begegnen, ist die, die mit OBS gebündelt wird.
Der Grund, warum es nicht in Voice Type steckt: Rauschunterdrückung und Voice Activity Detection sind unterschiedliche Aufgaben.
- Rauschunterdrückung verändert das Audio. Sie dämpft, was sie für Rauschen hält, und lässt den Rest durch, sodass das weitergegebene Signal nicht mehr das aufgenommene Signal ist.
- Voice Activity Detection verändert nichts. Sie liest das Audio und markiert, welche Abschnitte Sprache enthalten. Der Recognizer bekommt weiterhin die Originalsamples.
RNNoise stellt als Nebenprodukt seiner Unterdrückung eine Sprachaktivitätswahrscheinlichkeit bereit, weshalb es in der Suche nach einem VAD auftaucht. Diese Ausgabe als Gate zu verwenden heißt, einen Unterdrücker laufen zu lassen, den man nicht will, um ein Signal zu erhalten, das nicht sein Hauptzweck ist. Silero ist ein Detektor, erledigt also die Erkennungsaufgabe direkt und lässt das Audio in Ruhe.
Dieser Unterschied zählt beim Diktieren mehr als bei einem Anruf. Bei einem Anruf ist sauberer klingendes Audio das Ziel, und wenn ein Unterdrücker zusammen mit dem Lüfter etwas echte Sprache entfernt, ist das ein akzeptabler Kompromiss, weil ein Zuhörer die Lücke füllt. Ein Recognizer füllt die Lücke nicht. Er transkribiert, was er bekommt, sodass Audio, das vor der Erkennung verändert wurde, Genauigkeit kosten kann, und zwar genau bei den Konsonanten, die ein Unterdrücker am schwersten von Rauschen unterscheiden kann.
Wenn du nach einem RNNoise-VAD-Schwellenwert suchst: Der Wert hängt vom verwendeten Wrapper ab, denn RNNoise selbst liefert eine Wahrscheinlichkeit zwischen 0 und 1, und jede Integration wählt ihren eigenen Grenzwert. Zum Vergleich: Die entsprechenden Zahlen im Silero-Gate dieser App sind 0,30, um in der Sprache zu bleiben, und 0,22, um in sie einzutreten. Die Überlegung hinter den beiden Werten steht im Abschnitt unten. Diese Zahlen gehören zu Silero, nicht zu RNNoise, und lassen sich nicht direkt übertragen.
RNNoise ist gute Software. Sie löst nur ein Problem, das wir nicht haben.
Kurz gesagt
- Die Segmentierung entscheidet, was der Recognizer bekommt. Ein Modell, dem man Stille gibt, liefert trotzdem Text, denn Text zu liefern ist, was es tut.
- Das Gate arbeitet mit 512-Sample-Frames bei 16 kHz, mit einem Sprachschwellenwert von 0,30.
- Sprachbereiche bekommen 1.000 ms Pre-Roll bei der ersten Phrase, danach 150 ms auf beiden Seiten, damit Wörter an der Grenze nicht abgeschnitten werden.
- Ein Batch, der kürzer als 5 Sekunden ist, wird bei einer Pause nie gesendet. Er wartet auf die nächste Phrase.
Warum die Segmentierung und nicht das Modell die Genauigkeitsgrenze setzt
Gib dem Recognizer ein sauberes Sprachsegment, und er transkribiert Sprache. Gib ihm drei Sekunden Klimaanlagenbrummen mit einem darin vergrabenen Wort, und der Decoder erzeugt trotzdem Text. Der Fehler sieht aus wie ein Modellfehler und ist ein Eingabefehler.
Deshalb ist das Gate die interessante Komponente. Es soll nicht dafür sorgen, dass Audio für Menschen besser klingt. Es soll sicherstellen, dass dem Modell nur Audio vorgelegt wird, das eine Frage enthält.
Die ausgelieferten Einstellungen
Das sind die aktuellen Standardwerte im ausgewogenen Diktiermodus, der läuft, solange du nicht auf Rohaufnahme umstellst.
| Einstellung | Wert | | --- | --- | | Framegröße | 512 Samples bei 16 kHz | | Sprachschwellenwert | 0,30 | | Schwellenwert für leisen Beginn | 0,22 | | Pre-Roll vor der ersten Phrase | 1.000 ms | | Pre-Roll bei späteren Phrasen | 150 ms | | Post-Roll | 150 ms | | Stille, die eine Phrase schließt, live | 400 ms | | Stille, die eine Phrase schließt, beim Stopp | 350 ms |
Die beiden Schwellenwerte sind der Teil, den man verstehen sollte. Ein einzelner Schwellenwert muss gleichzeitig empfindlich genug sein, um eine leise erste Silbe zu erfassen, und streng genug, um einen Lüfter zu ignorieren. Das sind verschiedene Aufgaben, deshalb nutzt das Gate eine niedrigere Hürde (0,22), solange es auf den Beginn von Sprache wartet, und die normale Hürde (0,30), sobald Sprache läuft.
Das asymmetrische Pre-Roll macht denselben Trick im Zeitbereich. Das erste Wort einer Äußerung wird am häufigsten abgeschnitten, weil das Gate davor nichts hat, womit es arbeiten kann. Es bekommt deshalb eine volle Sekunde Audio vor dem Erkennungspunkt. Spätere Phrasen brauchen nur 150 ms, weil das Gate dich bereits verfolgt.
Warum ein kurzer Batch wartet
Der Batcher hängt ganze Sprachbereiche an und weigert sich, einen in der Mitte zu zerschneiden. Er weigert sich auch, einen Batch zu senden, der zu kurz ist, um einen Decode zu lohnen.
Enthält der aktuelle Batch weniger als 5 Sekunden ausgewähltes Audio und du machst eine Pause, wird nichts gesendet. Der Batch übersteht die Pause, und die nächste Phrase kommt dazu. Das ist Absicht: Ein 1,5-Sekunden-Fragment, das allein decodiert wird, hat keinen umgebenden Kontext, und Modelle der Whisper-Familie nutzen Kontext. Zwei gemeinsam decodierte Fragmente schlagen zwei getrennt decodierte.
Ab der 5-Sekunden-Marke gelten wieder die normalen Regeln: Eine Pause von 400 ms nach einer geschlossenen Phrase leert den Batch, ebenso eine Phrase, die den Batch über das Ziel von 29 Sekunden hinausschieben würde. Wenn du den Hotkey loslässt, wird alles Verbleibende unabhängig von der Länge geleert.
Das Gate läuft in einem CPU-Thread, damit es nie mit dem Recognizer um die GPU konkurriert. Quelle: StreamingSileroSpeechGate.swift.
Der Weg eines Batches
Sobald ein Batch geleert wurde, wird er aufbereitet und dann decodiert:
- DC-Offset entfernen.
- Die aktiven Filter und die Lautheitsregelung anwenden, standardmäßig einschließlich eines 50-Hz-Hochpasses.
- Auf die 16 kHz resamplen, die Whisper erwartet, falls das Aufnahmegerät nicht schon dort war.
- Das Modell außerhalb des Main Actors ausführen.
- Den entstandenen Text an das Transkript anhängen und dabei wiederholte Wörter an der Batch-Grenze entfernen.
Schritt 5 ist wichtiger, als er aussieht. Weil Batches unabhängig voneinander decodiert werden, kann dasselbe Wort am Ende des einen und am Anfang des nächsten landen. Die zuletzt übernommenen Wörter werden außerdem als Prompt-Kontext weitergereicht, sodass das Modell weiß, was es gerade gesagt hat, ohne altes Audio erneut zu decodieren.
Wenn das Gate versagt
Voice Activity Detection ist ebenfalls ein Modell und kann falsch liegen. Fällt Silero komplett aus, kann die Pipeline auf aufgenommenes Audio als markierte Ersatzsegmente zurückgreifen.
Es gibt eine bewusste Ausnahme. Läuft das Gate normal und meldet überhaupt keine Sprache, fällt die App nicht auf einen Energieschwellenwert zurück. Das ist der Fehlermodus, in dem Lüfter, Tippen und das Klicken der Stopptaste zu einem Transkript werden, und ein falsches Transkript ist schlimmer als gar keins.
Verwandt: Warum wir den Core-ML-Encoder abgeschaltet haben · Resampling auf 16 kHz