Wie AudioLab Dinge misst.

Der maximale Abtastwert einer digitalen Aufnahme ist nicht dasselbe wie der Maximalwert der zugrunde liegenden kontinuierlichen Wellenform. Zwischen zwei Samples, die beide bequem unter 0 dBFS liegen, kann das rekonstruierte Analogsignal kurzzeitig 0 dB überschreiten, ein sogenannter Inter-Sample-Peak. Limiter, die nur auf die Abtastwerte schauen, übersehen diese. Die Referenzdecoder der Streaming-Plattformen nicht.

BS.1770-4 Annex 2 schreibt 4×-Oversampling über einen FIR-Interpolator vor, gefolgt von der Spitzenwerterkennung am hochgesampelten Signal. AudioLab verwendet einen 4-Punkt-Kubik-Interpolator, der zwischen jedes Paar von Originalsamples drei Zwischenwerte einfügt. Der maximale Absolutwert über den hochgesampelten Puffer wird als True Peak ausgegeben.

Kubische Interpolation genügt für den 4×-Faktor, den BS.1770 vorgibt (die Referenz des Standards verwendet einen 12-Tap-FIR; wir liegen bei Standard-Testsignalen innerhalb von 0,1 dBTP). Für Mastering-taugliche Analyse ist ein Kernel höherer Ordnung vorzuziehen; die Anzeige von AudioLab ist für diagnostische Loudness-Arbeit gedacht, nicht als Ersatz für ein kalibriertes Laborinstrument.

Die Stereokorrelation in MixLab ist der Pearson-Korrelationskoeffizient zwischen linkem und rechtem Kanal, samplewise berechnet über das gesamte Programm (offline) oder über ein gleitendes 1024-Sample-Fenster (während der Wiedergabe). Die Werte reichen von +1 (perfekt mono) über 0 (dekorreliert) bis -1 (perfekt invertiert, nicht mono-kompatibel, löscht sich bei Mono-Summierung aus).

Das Phasenskop ist eine Lissajous-Figur: ein 2D-Plot mit L auf der einen und R auf der anderen Achse, gezeichnet aus einem gleitenden Fenster der jüngsten Samples. Eine senkrechte Linie bedeutet Mono-Inhalt; ein Kreis bedeutet unkorrelierte Stereofonie; eine waagerechte Linie bedeutet polaritätsinvertiertes Material, das bei Mono-Wiedergabe zu Stille kollabiert. Die Anzeige nähert nicht an, sie zeichnet die tatsächlichen Samplepaare.

Mid und Side werden aus der üblichen Summe und Differenz abgeleitet: M = (L + R) / 2, S = (L – R) / 2. Wir nehmen den RMS-Wert beider über das gesamte Programm; das Verhältnis von Side zu Mid, geteilt durch 1,5 und auf 1 begrenzt, ist die Stereobreite, die wir ausgeben (0 ist Mono, 1 ist breit).

Die Echtzeit-Spektrumansicht nutzt die in den Browser integrierte AnalyserNode, die intern eine FFT mit einem Blackman-Fenster implementiert. Für die Offline-Analyse verwenden wir ein Hann-Fenster und eine 4096-Punkt-FFT mit 50 % Überlappung. Die Fensterwahl verschlechtert den Dynamikumfang gegenüber Blackman leicht, bewahrt aber eine bessere Main-Lobe-Auflösung, nützlich für die visuelle Lesbarkeit in der Analyser-Anzeige.

Der Siebenband-Meter fasst FFT-Bins zu perzeptuell verteilten Bändern zusammen. Die Wahl folgt gängigen Konventionen von Mastering-Tools:

Sub          20  Hz –   60 Hz
Bass         60  Hz –  200 Hz
Low-mid     200  Hz –  500 Hz
Mid         500  Hz –   2 kHz
High-mid      2 kHz –   4 kHz
Presence      4 kHz –   8 kHz
Air           8 kHz –  16 kHz

Jedes Band liefert die mittlere spektrale Magnitude der Bins innerhalb seiner Grenzen, so skaliert, dass das stärkste Band 1 ergibt. Die sieben Werte sind relativ zueinander, keine Pegel in dBFS. Der Binabstand beträgt bei 48 kHz und einer 4096-Punkte-FFT 11,7 Hz, das Sub-Band enthält also nur etwa vier Bins und ist das gröbste der sieben.

VoiceLab QA liefert einzelne Messwerte, keinen Gesamtwert. Sie sind eigenwillig, für Podcast- und Voiceover-Produzenten entworfen und ausdrücklich keine klinische Messung. Was folgt, ist das, was die Engine heute tut. Wo sich eine Messung als falsch erwies, steht das in Abschnitt 08.

• Sprachdetektion: der Pegel (RMS) wird alle 20 ms über ein 40-ms-Fenster bestimmt, und eine Phrase ist ein Abschnitt oberhalb einer Schwelle, die aus den eigenen Pegelperzentilen dieser Aufnahme stammt: der größere Wert aus dem Dreifachen des 10. Perzentils und der Mitte zwischen 10. und 70. Perzentil, nie unter etwa −55 dBFS, und auf die Hälfte des 70. Perzentils begrenzt, wo sie sonst über dem 95. läge und nichts mehr fände. Lücken unter 160 ms werden überbrückt, Abschnitte unter 100 ms entfallen. Das ist ein Pegel-Gate und kein Spracherkenner, und es lässt sich täuschen. Wie sehr, haben wir an 111 Aufnahmen mit dem sauberen Quellsatz als Grundwahrheit gemessen: bei 10 dB Signal-Rausch-Abstand findet es im Mittel 1,2 s zu wenig Sprache, bei 5 dB 2,4 s. Diese Sprache fällt dann aus dem Sprachpegel und dem SNR heraus.
• Was das aktive Material ist: jedes Frame wird anhand seines Pegels und der Schwankung seiner Nulldurchgangsrate über etwa eine halbe Sekunde zu beiden Seiten als Stimme, Musik, Rauschen oder Stille etikettiert (Sprache wechselt zwischen Konsonanten und Vokalen, Musik ist spektral gleichmäßiger). Die Grenzen wurden an einem gelabelten Korpus angepasst: Sprache in 32 Rausch- und Hallbedingungen, tonale und beatgetriebene Musik und reines Raumrauschen. Das Ergebnis gilt ab 60 % stimmähnlicher Frames als Stimme, ab 40 % als gemischt, sonst als Musik oder Rauschen. Das geschriebene Feedback beurteilt SNR, Tempo und Zischlaute nicht bei Material, das nicht als Stimme gelesen wird.
• Rauschteppich und SNR: der Rauschteppich ist das 10. Perzentil des Pegels. Der Gesamt-SNR ist der mittlere Sprachpegel minus dieser Teppich. Ein Fernseher oder ein vorbeifahrender Lkw hebt den Teppich nur in einem Teil einer Aufnahme an, deshalb liefert die Engine zusätzlich einen SNR pro Phrase, gegen den Teppich in einem Fenster von etwa einer halben Sekunde um diese Phrase, und das schwächste Zehntel davon: ein einziger unverständlicher Satz genügt, um eine Durchsage zu verpassen, und ein Mittelwert verbirgt das. Phrasen unter 200 ms erhalten keinen eigenen SNR.
• Tempo: die dominante Modulationsfrequenz der Sprachhüllkurve zwischen 2 und 8 Hz, in Silben pro Sekunde, über die Spanne von der ersten bis zur letzten Phrase, Pausen eingeschlossen. Sie wird auf ein Etikett langsam, normal oder schnell abgebildet. Das Zählen von Hüllkurvenspitzen wurde ausprobiert und verworfen: bei einem Satz, der in drei Tempi gelesen wurde und dessen wahres Verhältnis 1,63 : 1,00 : 0,69 betrug, ergab es 1,12 : 1,00 : 0,98.
• Zischlaute: in Frames mit 4096 Abtastwerten und Hann-Fenster der Anteil der spektralen Magnitude zwischen 5 und 9 kHz. Der Median über die Frames, mal fünf und auf 1 begrenzt, ist der Wert: niedrig unter 0,25, mittel unter 0,55, hoch darüber.
• Helligkeit: aus dem spektralen Schwerpunkt abgeleitet, leistungsgewichtet und nur bis 8 kHz gezählt. Darüber hat Sprache fast nichts, und die Tausenden nahezu leeren Bins bestimmten früher das Ergebnis: ein Rauschteppich bei −96 dBFS, weit unter der Hörschwelle, verschob die Helligkeit von 0,513 auf 0,590.
• Clipping: zählt Folgen aufeinanderfolgender Abtastwerte am Spitzenwert und stuft diese Anzahl ein: keins, niedrig, mittel oder hoch.
• Verständlichkeit, als Proxy: der schwächere von zwei Verläufen: das schwächste Zehntel des SNR pro Phrase und der Sprachpegel über dem Hintergrund in den Pausen. Jeder liest 0 bei 3 dB und 1 bei 18 dB und wird bei mittlerem Clipping um 15 % und bei starkem um 40 % gesenkt. Klar ab 0,65, grenzwertig ab 0,35, sonst untergegangen, und nur bei mindestens zwei messbaren Phrasen. Es ist ein Proxy und heißt auch so: kein Speech Transmission Index, der ein im Raum abgespieltes Testsignal braucht. Es ist ein Proxy dafür, wie gut ein Hörer der Stimme folgen kann, nicht für die Genauigkeit der Spracherkennung: in unserem eigenen Test mit 1.248 Transkriptionen sagte es Erkennungsfehler nicht voraus (siehe den Status auf der Lenses-Seite).

Es gibt keine einzelne Gesamtzahl. Die Messwerte kommen als getrennte Felder zurück, du legst also selbst fest, was als bestanden gilt. Das Verständlichkeitsetikett ist die eine Ausnahme, und es heißt Proxy. Eine frühere Fassung dieser Seite beschrieb einen Wert von 0–100; die Engine hat nie einen geliefert.

SignalLab teilt eine beliebige Audiodatei in beschriftete Regionen ein: Stimme, Musik, Rauschen, Stille und Clipping. Es ist eine Pipeline, die VoiceLab mitbenutzt.

1. Frame-Etiketten: Pegel (RMS) und Nulldurchgangsrate alle 20 ms. Jedes Frame bekommt sein Etikett aus seinem Pegel und daraus, wie stark die Nulldurchgangsrate über etwa eine halbe Sekunde zu beiden Seiten schwankt: Sprache wechselt zwischen Konsonanten und Vokalen (eine Streuung von 0,05 oder mehr), Musik ist spektral gleichmäßig (0,02 oder weniger). Die Grenzen wurden an einem gelabelten Korpus angepasst (Sprache in 32 Rausch- und Hallbedingungen, tonale und beatgetriebene Musik, reines Raumrauschen) und nicht geraten, und VoiceLab nutzt dieselbe Funktion, die beiden Labs können sich also nicht darüber streiten, was Stimme ist.
2. Regionen zusammenfassen: aufeinanderfolgende Frames mit demselben Etikett werden zu einer Region, und Regionen unter 0,3 s gehen in der vorherigen auf. Clipping ist ein eigener Durchgang: ein Abschnitt, in dem in einem Fenster mehr als drei Abtastwerte bei oder über 0,98 der Vollaussteuerung liegen, wird zur Clipping-Region, bei Dateien mit viel Clipping.

Die Regionen-Labels sind heuristisch. Das Tag-Schema ist veröffentlicht unter /docs/signallab/tag-schema. Sie sind nützlich für Navigation und Massenfilterung. Die Zeitleiste der Regionen stammt aus diesem einfachen Frame-Klassifikator; für die Produktionsindexierung im großen Maßstab wäre auch dafür ein gelerntes Modell vorzuziehen.

Das Dateiurteil, der Inhaltstyp (voice, music, mixed, noise oder unknown), ist ein eigener Schritt. Auf der Website kommt es aus einem kleinen gelernten Modell (v2) über 25 einfache Merkmale pro Fenster von 10 Sekunden; in der API ist es bis zum 15. Januar 2027 eine Option (contentModel v2) und wird dann zum Standard. Das erste Modell haben wir am 12. Oktober 2026 an echten Aufnahmen geprüft: 600 Ausschnitte von je 20 Sekunden aus dem MUSAN-Korpus (je 200 Sprache, Musik und Rauschen), ein Durchlauf, nachträglich wurde nichts angepasst. Es verfehlte die Latte, die wir vorher gelegt hatten (Recall und Präzision von mindestens 0,80 in allen drei Klassen): Es fand 164 der 200 Sprachausschnitte, 91 der 200 Musikausschnitte und 3 der 200 Rauschausschnitte. Danach haben wir v2 einmal auf dieselbe Weise geprüft, an denselben 600 Ausschnitten plus 90 Ausschnitten aus drei Umgebungen, die es nie gesehen hatte: Es fand 197 der 200 Sprachausschnitte (Präzision 0,95), 190 der 200 Musikausschnitte (0,86) und 40 der 90 Ausschnitte mit stationärem Rauschen (Präzision 1,00; Straßenverkehr und U-Bahn hießen meist unknown). Es erreichte die Latte für Sprache und Musik, nicht für Rauschen, bleibt also ein Proxy. Die vollständigen Zahlen stehen unter signal.contentType auf /lenses.

Jede Messung, die die Engine liefert, trägt einen von vier Status, und dieselben Wörter stehen auf der Lenses-Seite, der API-Seite, im OpenAPI-Dokument und in den MCP-Tool-Beschreibungen. Beta heißt, dass es noch keinen Grundwahrheitstest gibt, nicht dass die Messgröße falsch ist. Eine Messgröße wird erst mit einem festgehaltenen Test gegen einen bekannten Wert und mit einer Toleranz validiert, und ein Proxy bleibt bis dahin ein Proxy.

Bei jeder Messgröße auf der Lenses-Seite (Englisch) steht, wogegen sie getestet wurde, wogegen nicht, und was sie nicht ist. Die meisten Loudness-Werte sind gegen die EBU-Testsignale validiert; die Szenen-, Inhalts- und Verständlichkeitsmaße sind Proxys; der Nachhall-Score, der durchfiel, wurde zurückgezogen (siehe Korrekturen unten). Jede Messgröße sagt auch, wie sie funktioniert: klassische Signalverarbeitung oder Signalverarbeitung mit einem kleinen gelernten Modell, das dann benannt wird, mit den Daten, auf denen es trainiert wurde.

Einer Messung kann man nur trauen, wenn ihr Hersteller sagt, wann sie falsch war. Das sind die Fälle von September und Oktober 2026. Jeder wurde gefunden, indem eine Behauptung an etwas Gemessenem geprüft wurde, und jeder ist in der Engine behoben und nicht nur im Text.

• Ein Hallwert, der keinen Hall maß. Das Hall-Etikett von VoiceLab (Dry, Tight, Live, Reverberant) stieg mit dem Hintergrundrauschen, nicht mit dem Hall. Gegen die gemessenen Nachhallzeiten von 24 Räumen, von 0,18 bis 1,71 s, lag die Rangkorrelation bei 0,06, und ein Raum mit 1,71 s erzielte weniger als eine Kabine mit 0,18 s. Am 27. September aus der Engine, den Apps, der API und dem MCP-Server zurückgezogen. Die Zahl bleibt unter dem Namen dessen, was sie misst, Energie in den Pausen nach Sprache, und senkt den Verständlichkeits-Proxy nicht mehr. Die Auswertung mit den Zahlen. Ein neues Hallmaß darf erst Hall heißen, wenn es denselben Test besteht.
• Zahlen ohne Sprache. Bei einem Musikstück mit Gesang fand VoiceLab keine einzige Phrase und meldete trotzdem einen SNR von −66 dB, ein Tempo von 0,0 Silben pro Sekunde, ein Zischlautrisiko mittel und 14,3 s Stille. Keine der vier Zahlen war gemessen. Sie sind jetzt leer, wenn keine Sprache gefunden wird, und das Labor sagt, was das Material zu sein scheint.
• Zwei Labs, zwei Antworten. VoiceLab und SignalLab berechneten je ihre eigene Pegelkurve und Schwelle und widersprachen sich bei derselben Datei: 14,3 s Stille gegen 6,3 s Stimme. Sie teilen jetzt einen Satz Fakten, und eine Prüfung an einer synthetischen Datei hält sie dabei.
• Eine Plattform, die sich anders verhält als angenommen. Nach der YouTube-Normalisierung wurde ein leiser Upload als über der Obergrenze gezeigt, aber YouTube hebt leise Uploads laut Messungen Dritter nicht an. Spotify tut es, bis auf 1 dB Reserve. Ein Ergebnis nach der Normalisierung wird jetzt nur gezeigt, wo die Plattform veröffentlicht, was sie tut, und wo nicht, sagt das Werkzeug das.
• Lautheitswerte und der Standard. Diese Seite behauptete zuerst, die Engine stimme mit der Referenzimplementierung der EBU auf 0,05 LU überein. Der Benchmark vergleicht mit den veröffentlichten Erwartungswerten des Standards, nie mit einer anderen Implementierung, und der schlechteste Fall liegt bei 0,06 LU. Der Text sagt das jetzt.

Prüfungen, die bei jedem Build laufen, verhindern die Rückkehr: die Preisseite gegen den Code, dokumentierte API-Endpunkte gegen echte, die Datenschutzseiten gegen das, was tatsächlich lädt, zurückgezogene Aussagen gegen den Text, die Lautheit gegen die EBU-Signale Tech 3341 und 3342 und ein Selbsttest pro Modul. Ein getrennter Durchlauf zerstört absichtlich Dinge, um zu beweisen, dass jede Prüfung rot werden kann.

Kann ich das nicht an einem Nachmittag von einer KI bauen lassen?

Eine Oberfläche lässt sich generieren, und eine Seite, die Zahlen zeigt, ist schnell gemacht. Was sich nicht generieren lässt, ist das, was eine Zahl vertrauenswürdig macht: der Test gegen etwas Gemessenes. Unsere Lautheit wird gegen die Signale geprüft, die der EBU-Standard definiert, und liegt im schlechtesten Fall bei 0,06 LU. Unser Hallwert wurde gegen 24 Räume mit gemessenen Nachhallzeiten geprüft, fiel durch und wurde zurückgezogen; der Abschnitt oben nennt die Zahlen. Eine Kopie, die nie getestet wird, behält so einen Wert. Übrig bleibt nicht der Code, sondern das Testen, eine ehrliche Liste dessen, was wir nicht messen, und eine Engine hinter den Browser-Labs, der API und dem MCP-Server.

Ist es Open Source?

Nein. Die Messengine ist Closed Source. Öffentlich sind: die API-Spezifikation unter /openapi.yaml, der MCP-Server und das AI SDK auf npm sowie ein öffentliches Repository für den MCP-Server unter github.com/Audio-Launch/audiolab-mcp-server. Die Standards, die wir umsetzen, und die Testsignale, gegen die wir prüfen, werden von ihren Eigentümern veröffentlicht, und der Lautheits-Abschnitt sagt, wie du die Prüfungen selbst nachbaust. Die Browser-Labs senden kein Audio an uns, und der Netzwerk-Tab deines Browsers zeigt das.

Hat eine KI es geschrieben, und ist es Vibe-Coding?

Viel vom Code wird mit KI-Werkzeugen geschrieben, und es ist kein Vibe-Coding. Der Unterschied liegt darin, was passiert, nachdem der Code da ist. Vibe-Coding heißt, zu übernehmen, was herauskommt, und es zu veröffentlichen, weil es läuft. KI-gestützt heißt, dass ein Mensch bestimmt, was gemessen wird und wogegen, und dass nichts auf sein Wort hin geglaubt wird: Jeder Push lässt den Lautheits-Benchmark gegen die EBU-Testsignale laufen, einen Selbsttest pro Modul und Prüfungen, dass Preisseite, API-Dokumentation und Datenschutzseiten mit dem übereinstimmen, was wirklich läuft. Erweist sich eine Messung als falsch, wird sie zurückgezogen, und die Seite sagt das. Der Abschnitt oben nennt diese Fälle; Ergebnisse, die nie geprüft oder getestet wurden, haben keine zu nennen.

Die Zahlen sind innerhalb der oben dokumentierten Toleranzen genau, aber dies ist ein browserbasierter Analyser, der auf der CPU des Nutzers läuft. Er ist kein Ersatz für:

• Ein kalibriertes Hardware-Loudness-Messgerät für Broadcast-Compliance-Audits.
• Einen Labor-Audioanalysator zum Testen von Verstärkern oder Wandlern.
• Ein klinisches Audiometrie-Instrument (HearLab ist ausdrücklich nicht-medizinisch).
• Einen Referenz-Encoder/-Decoder zur Prüfung der Codec-Compliance.
• Einen Hallmesser für eine Aufnahme. VoiceLab liefert die Energie in den Pausen nach Sprache, und die steigt mit Rauschen ebenso wie mit Hall. Für Hall misst RoomLab ihn aus einem Klatschen.
• Einen Zähler für Wörter, Füllwörter oder Sprecherwechsel. Keine Linse zählt sie.

Was er ist, im Geiste der übrigen Website: eine funktionierende, schnelle, belegbare Messung, die du in den Browser-Labs an jeder Audiodatei durchführen kannst, ohne irgendetwas auf einen Server hochzuladen, mit vollständig dokumentierter Mathematik und einem Codepfad, der von jeder Demo aus hierher zurückverlinkt werden kann.