Bessere Spracherkennung im boostN-CLI: Audio-Normalisierung + flexibles Whisper-Modell

Martin Rau · · 7 Min. Lesezeit

Spracheingabe ist im boostN-CLI keine Spielerei, sondern ein Arbeitsweg: Gedanken laufen schneller als Finger, und beim Tippen verliert man oft die Hälfte der Idee zwischen Hirn und Tastatur. Genau deshalb hat es richtig gestört, dass die Transkription über Whisper bei uns regelmäßig Wörter verschluckt hat — vor allem bei kurzen Sätzen, Fachbegriffen und leiseren Stellen. Dieser Beitrag erklärt, woran das lag, welche zwei Änderungen das Problem gelöst haben, und ein bisschen Audio-Engineering-Hintergrund für alle, die wissen wollen, warum die gewählten Lösungen die sauberen Lösungen sind.

Das Problem in einem Satz

Whisper sieht nur das Audio-Signal, das man ihm gibt — und wenn das Signal zu leise ist oder das Modell zu klein, fehlen ihm schlicht die Hinweise, um zwischen ähnlich klingenden Wörtern, gemurmelten Silben oder Fachbegriffen sauber zu unterscheiden.

Bei uns kamen zwei Sachen zusammen: Das Mikrofon-Volumen am Mac war zwar auf Maximum, der Aufnahme-Pegel im WAV-File trotzdem niedrig — typischer Headroom-Effekt: Damit der lauteste Peak nie clippt, bleibt der Durchschnitt der Aufnahme deutlich unter dem digitalen Maximum. Und das Whisper-Small-Modell hat zwar Vorteile (schnell, klein, 244 MB), kennt aber weniger Akustik-Varianten als Medium oder Large-v3. Bei lauter, klarer Studiosprache fällt das nicht auf. Bei spontanen Diktaten, mit Hintergrundrauschen und gemischtem Deutsch-Englisch-Fachvokabular schon.

Lösung 1: Audio-Normalisierung mit SoX

Direkt nach der Aufnahme und vor der Übergabe an Whisper läuft die WAV-Datei jetzt durch SoX mit dem Filter norm -1. Das bedeutet: Der lauteste Punkt der Aufnahme wird auf -1 dBFS angehoben — also fast bis zur digitalen Obergrenze, mit minimalem Sicherheitsabstand zur Vermeidung von Clipping.

Warum -1 dBFS und nicht 0?

dBFS (Dezibel relativ zu Full Scale) ist die digitale Skala für Audio-Pegel. 0 dBFS ist das absolute Maximum — alles, was darüber liegen würde, wird auf 0 abgeschnitten (Clipping), und Clipping hört sich nicht nur unschön an, es zerstört Information. Whisper hasst Clipping, weil verzerrte Vokale für das Modell aussehen wie kaputte Phoneme.

Mit -1 dBFS lassen wir einen Headroom von 1 Dezibel — das ist akustisch nicht hörbar (1 dB ist die Wahrnehmungsschwelle), reicht aber, um Rundungsfehler in der Pipeline oder minimale Resampling-Artefakte abzufangen. Klassischer Mastering-Move: so heiß wie möglich, ohne ins Clipping zu rutschen.

Warum norm und nicht einfach Gain hochdrehen?

Ein fester Gain (z.B. „immer +3 dB”) behandelt jede Aufnahme gleich. Eine bereits laute Aufnahme würde clippen, eine sehr leise wäre danach immer noch zu leise. norm arbeitet dagegen adaptiv: SoX scannt die Datei, findet den lautesten Peak und berechnet den Gain so, dass dieser Peak exakt auf den Zielpegel landet. Eine kurze flüsternde Aufnahme wird stark angehoben, eine bereits volle Aufnahme kaum.

So sieht Whisper jede Aufnahme mit ähnlich kräftigem Pegel — unabhängig davon, wie nah am Mikrofon gesprochen wurde, wie laut der Raum ist oder welche Tagesform die Stimme hat.

Warum keine Kompression?

Ein häufiger Reflex an dieser Stelle: „Dann komprimier doch auch noch, damit leise Stellen lauter werden.” Klingt logisch, ist hier aber kontraproduktiv. Kompression verändert das Verhältnis zwischen leisen und lauten Stellen — und genau dieses Verhältnis ist für Whisper ein wichtiges Feature. Atempausen, weicher Konsonantenausklang, leichte Betonung am Satzende: Das sind Hinweise, die das Modell aktiv nutzt. Wenn man die durch Kompression einebnet, klingt es zwar präsenter, das Modell bekommt aber weniger Information, nicht mehr.

norm ändert nur die Amplitude, nicht den Frequenzgang und nicht die Dynamik. Es ist eine reine lineare Skalierung — leise und laute Stellen werden im exakt gleichen Verhältnis angehoben. Genau das wollten wir.

Lösung 2: Modell-Switcher im Settings-Menü

Bis zur letzten Version war das Whisper-Modell hartkodiert auf Small. Schnell, klein, lief reibungslos auf Apple Silicon — aber bei Fachbegriffen und kurzen Diktaten eben mit spürbar mehr Fehlern als nötig. Die naheliegende Lösung „nimm ein größeres Modell” wollten wir nicht hart austauschen, sondern auswählbar machen.

Jetzt gibt es unter Einstellungen → Voice → Whisper-Modell die Auswahl zwischen:

  • Small (~244 MB) — schnell, gut genug für klare Sprache, sparsam mit RAM
  • Medium (~769 MB) — der neue Default-Vorschlag, deutlich genauer bei Fachbegriffen
  • Large-v3 (~1.5 GB) — Whispers Top-Modell, bestes Englisch + Deutsch, etwas mehr Latenz

Der Flow ist auf null Reibung getrimmt

Das war uns wichtiger als das Feature selbst. Ein Modell-Wechsel sollte sich nicht anfühlen wie eine Systemkonfiguration, sondern wie ein Klick:

  1. Modell auswählen → Enter
  2. CLI prüft, ob das Modell schon lokal liegt
  3. Falls nein: Confirm-Dialog, dann Auto-Download über das mitgelieferte whisper.cpp-Script
  4. Config wird persistiert, Whisper-Server wird automatisch neu gestartet mit dem neuen Modell
  5. Statusmeldung: „Modell ist jetzt aktiv — sofort einsatzbereit”

Kein App-Restart. Kein manuelles Editieren von Config-Files. Kein Pfad-Setzen. Kein „lade dir das Modell vorher von HuggingFace runter und schiebe es in den richtigen Ordner”. Das alles passiert im Hintergrund. Wer der CLI vertraut, kann das Modell mitten in der Arbeit wechseln und drei Sekunden später weiter diktieren.

Warum das wichtiger ist, als es klingt

Tools werden nur dann ehrlich benutzt, wenn die Reibung niedrig genug ist. Ein Modell-Switcher, der einen Restart braucht, wird in der Praxis fast nie benutzt — und damit ist das ganze Feature tot. Wir haben uns deshalb explizit die Zeit genommen, den kompletten Lifecycle (Download, Persistierung, Server-Restart, Statusmeldung) so zu bauen, dass er sich anfühlt wie ein Dropdown-Wechsel — auch wenn im Hintergrund eine 700-MB-Datei nachgeladen wird.

Das Ergebnis

Mit dem Medium-Modell und aktivierter Normalisierung subjektiv ~50 % weniger Fehler bei kurzen Sätzen und Fachbegriffen. Vor allem Mischsprache (deutscher Satz mit englischen Fachwörtern wie „Webhook”, „Inference”, „Prompt Caching”) wird jetzt deutlich zuverlässiger erkannt.

Die Überraschung: Geschwindigkeit blieb praktisch identisch

Was uns selbst überrascht hat: Trotz dreifacher Modellgröße ist Medium auf Apple Silicon mit Metal-GPU kaum langsamer als Small. Der Grund liegt im Encoder-Decoder-Aufbau von Whisper.

Whisper besteht aus einem Encoder, der den kompletten Audio-Clip einmal verarbeitet (relativ teuer, läuft parallel auf der GPU), und einem Decoder, der dann Token für Token den Text generiert (deutlich billiger pro Token, aber linear in der Token-Anzahl). Bei kurzen Diktaten von 2–5 Sekunden dominiert der Encoder-Overhead — und genau dieser Encoder skaliert auf einer Metal-GPU sehr gut. Die zusätzliche Modell-Komplexität fällt in der GPU-Verarbeitung kaum auf, weil sie ohnehin nicht der Bottleneck ist.

Bei längeren Aufnahmen (mehrere Minuten) wird der Decoder-Anteil größer und der Unterschied zwischen Small und Medium spürbar. Für unseren Hauptanwendungsfall — kurze Diktate von Befehlen, Notizen, Prompt-Schnipseln — ist Medium das neue sinnvolle Default.

Was wir daraus mitnehmen

Drei Dinge, über Whisper hinaus:

1. Audio-Qualität ist oft das fehlende Glied. Wenn ein ML-Modell „nicht gut genug ist”, lohnt sich vor dem Modellwechsel ein Blick auf das Input-Signal. Wir hätten direkt auf Large-v3 hochziehen können — und das eigentliche Problem (zu leiser Pegel) wäre versteckt geblieben. Erst die Kombination aus Normalisierung und größerem Modell hat die Erkennung wirklich verbessert.

2. Null-Reibung-UX ist Architektur, nicht Politur. Den Modell-Switcher hätten wir auch in „bearbeite die config.toml” abkürzen können. Hätten wir das gemacht, wäre das Feature da, aber tot. UX-Reibung ist eine technische Designentscheidung, keine Schönheitskorrektur.

3. Kleine Tools, sauber gebaut. SoX und whisper.cpp sind beide klassische Unix-Werkzeuge — fokussiert, gut dokumentiert, ohne Cloud-Abhängigkeit. Das passt zu unserer Linie: lokale Tools wo möglich, externe Dienste nur wo nötig.

Nächster Schritt

Large-v3 ist über das gleiche Menü ein Klick entfernt. Wir testen aktuell, ob die zusätzliche Genauigkeit für unsere typischen Diktate den Unterschied wert ist — oder ob Medium der Sweet-Spot bleibt. Berichte folgen, wenn die Daten dafür stehen.

Entdecke mehr