Peak-Normalisierung gegen Lautheits-Normalisierung — und das Ziel, das nicht erreichbar ist

Peak und Lautheit beantworten zwei verschiedene Fragen

Die Peak-Normalisierung stellt eine Frage: Was ist das lauteste Sample dieser Datei, und mit welcher Konstanten multipliziere ich alles, damit es genau auf einer gewählten Decke landet? Eine Messung, eine Multiplikation. Das ist schnell, exakt und nahezu nutzlos, um zwei Aufnahmen gleich laut klingen zu lassen, denn der lauteste Augenblick eines Audios sagt nichts über die empfundene Lautstärke. Eine spärliche Sprachaufnahme mit einem zuschlagenden Türblatt und eine dichte Wand aus Musik können exakt denselben Spitzenwert erreichen, während die eine mehrfach lauter wirkt als die andere.

Die Lautheits-Normalisierung stellt die andere Frage: Wie laut wirkt dieses ganze Programm, und um wie viel muss ich es verschieben, damit es so laut wirkt wie alles andere? Das verlangt ein Gehörmodell, und es gibt eines: ITU-R BS.1770 definiert einen Filter, der den Frequenzgang des Ohrs annähert, die Kanäle mit festen Gewichten summiert und — entscheidend — leise Passagen ausblendet, damit eine lange Stille am Ende die Zahl nicht nach unten zieht. Das Ergebnis ist eine Lautheit in LUFS, und zwei Dateien mit demselben LUFS-Wert klingen tatsächlich etwa gleich laut. EBU R 128 ist die auf dieser Messung aufgebaute Praxis, und daher stammen die Zielwerte.

Dieses Werkzeug macht nur das Zweite. Es gibt keinen Peak-Normalisierungs-Knopf, und das ist richtig so: Peak-Normalisierung war das, was das „Normalisieren“-Häkchen früherer Dateiverwaltungen bedeutete, und es tat fast nie, was die Leute wollten. Was das Werkzeug aus der Peak-Welt behält, ist eine Decke — eine True-Peak-Grenze, standardmäßig −1 dBTP —, und diese Decke erweist sich als das folgenreichste Bedienelement der Seite, aus Gründen, zu denen der dritte Abschnitt kommt.

Zwei Durchgänge, und warum einer nicht reicht

Ein Ein-Pass-Lautheitsnormalisierer hat eine unmögliche Aufgabe: Er muss in jedem Augenblick entscheiden, wie viel Verstärkung er anlegt, und kennt dabei nur, was er schon gehört hat. Vor einem leisen Anfang hebt er ihn an, dann kommt ein lauter Refrain, den er wieder herunterdrücken muss. Das Ergebnis ist eine Aufnahme, deren innere Balance ein Algorithmus mit Zukunftsvermutungen umgestellt hat — das ist ein Kompressor, kein Normalisierer, und nicht das, was jemand meinte, der um Normalisierung bat.

Die Zwei-Pass-Form nimmt das Raten heraus. Der erste Durchgang liest das ganze Programm und druckt seine Messwerte: integrierte Lautheit, True Peak, Lautheitsumfang und die verwendete Gating-Schwelle. Diese vier Zahlen plus ein Zielversatz gehen an den zweiten Durchgang, der die Antwort nun vor dem Start kennt und eine konstante Verstärkung von Anfang bis Ende anlegen kann. Nichts wird umgestellt; die Aufnahme wird nur verschoben. Das bedeutet lineare Normalisierung, und genau das verlangt das Werkzeug mit linear=true.

Wenn Luft da ist, funktioniert das genau wie versprochen. Ein gleichmäßiger Testton mit −29,75 LUFS und Spitzen weit unten bei −26,02 dBTP, für den das Rundfunkziel von −23 LUFS verlangt wurde, kam mit −23,05 LUFS heraus: fünf Hundertstel Dezibel vom Ziel, was praktisch das Ziel ist. Der Entwurf taugt. Das Problem ist, was passiert, wenn keine Luft da ist.

Das verlangte Ziel ist nicht immer das erreichte Ziel

linear=true ist keine Anweisung, sondern eine Präferenz. ffmpegs loudnorm wendet eine konstante Verstärkung nur an, wenn der wahre Spitzenwert dabei unter der von dir gesetzten Grenze bleibt. Würde die aus den Messungen folgende konstante Verstärkung diese Grenze überschreiten, verlässt der Filter stillschweigend den linearen Modus und fällt auf seinen dynamischen Algorithmus zurück — der die Grenze einhält und eben deshalb dein Lautheitsziel nicht erreichen kann. Nichts im Log kündigt den Wechsel an. Das Werkzeug druckte früher die angeforderte Zahl und nannte die Differenz „angewandte Korrektur“; es schickt die erzeugte Datei jetzt durch dasselbe Messgerät zurück und druckt, was herauskommt — die Zahl auf dem Schirm ist also eine gemessene und keine verlangte.

So viel kostet das bei ganz gewöhnlichem Material. Nimm ein Programm mit −16,06 LUFS, dessen Spitzen bei −0,09 dBTP liegen — ein völlig normales Profil für alles, was in den letzten zwanzig Jahren gemastert wurde, denn fast alles wird nah an den Vollausschlag geschoben. Verlange das Streaming-Standardziel von −14 LUFS mit der Standarddecke von −1 dBTP. Eine lineare Verstärkung von etwa zwei Dezibel brächte diese Spitzen auf rund +1,9 dBTP, der lineare Modus wird also abgelehnt. Die Ergebnisdatei misst −15,59 LUFS: Die echte Verstärkung war ein halbes Dezibel, nicht die zwei, die die Anzeige meldet. DeDort stand „Gemessen: −16,1 LUFS → −14,0 LUFS · Angewandte Korrektur: +2,1 LU“, und jedes Wort davon war eine Annahme im Kostüm einer Messung. Jetzt steht dort −15,59, denn die Ausgabe wird gemessen, bevor überhaupt etwas angezeigt wird — und weicht der erreichte Wert eine halbe Einheit oder mehr vom Ziel ab, wird das Ziel danebengedruckt, damit du siehst, dass der Filter abgelehnt hat.

Die Lücke wächst bei Material mit weitem Lautheitsumfang. Ein Programm mit −13,15 LUFS und einem einzelnen Vollausschlag-Transienten, für das −14 LUFS verlangt wurde, kam mit −26,71 LUFS heraus — fast dreizehn Dezibel unter dem Ziel und hörbar leise. Dieselbe Datei durch ein schlichtes Ein-Pass-loudnorm geschickt, wovor die eigene Notiz des Werkzeugs warnt, landete bei −14,75 LUFS. Das ist kein Argument gegen zwei Durchgänge; zwei Durchgänge sind für die große Mehrheit der Dateien richtig. Es ist ein Argument dafür, einer nie gemessenen Anzeige zu misstrauen. Klingt das Ergebnis falsch, kann es falsch sein, und der Weg zur Gewissheit ist, die Ausgabe selbst zu messen statt die Anzeige zu lesen.

Welches Ziel, und warum lauter nicht besser ist

Drei Voreinstellungen decken das meiste ab. −23 LUFS ist das europäische Rundfunkziel, festgeschrieben in EBU R 128 und vom Fernsehen erwartet. −16 LUFS ist gängige Praxis für Wortpodcasts, keine von irgendwem veröffentlichte Norm. −14 LUFS liegt ungefähr dort, wo die großen Streamingdienste die Wiedergabe normalisieren, und ist hier die Voreinstellung. Der Hinweistext fasst Spotify, YouTube und Apple Music bei −14 zusammen; die veröffentlichten Werte dieser Dienste haben sich über die Jahre verschoben und sind nicht alle dieselbe Zahl — nimm −14 also als Gegend, nicht als Spezifikation, und nutze den eigenen Regler, wenn dir eine Zahl vorgegeben wurde.

Verinnerlichen sollte man: Auf einer normalisierenden Plattform bringt es nichts, lauter als das Ziel abzuliefern. Die Plattform dreht dein Stück auf ihre eigene Referenz herunter, bevor es den Hörer erreicht. Nicht zurück kommt, was du für die Lautheit geopfert hast — die geplätteten Transienten, die zusammengedrückte Dynamik. Du landest bei derselben Wiedergabelautstärke wie alle anderen, nur mit weniger in der Aufnahme. Vorab auf die Zahl des Ziels zu normalisieren ist der Weg, die Dynamik zu behalten und trotzdem richtig laut anzukommen.

Normalisieren macht bereits vorhandenes Clipping nicht rückgängig

Clipping entsteht, wenn ein Signal den größten Wert überschreiten sollte, den ein Sample fassen kann, und alles darüber schlicht abgeschnitten wurde. Übrig bleibt ein flaches Dach, wo eine Kurve war, und der Klang daraus ist jene harte Kante, die man Verzerrung nennt. Was über der Decke lag, ist weder gedämpft noch versteckt; es existiert in der Datei nicht. Keine spätere Bearbeitung holt es zurück, denn nichts hat aufgezeichnet, was es war.

Eine geclippte Quelle durch dieses Werkzeug zu schicken zeigt das sauber. Eine absichtlich geclippte Testdatei maß −1,55 LUFS mit einem True Peak von +0,10 dBTP — über Vollausschlag, wofür ein True-Peak-Messgerät genau da ist: Es rekonstruiert, was zwischen den Samples passiert, und findet die Überschwinger, die ein Sample-Peak-Messgerät verfehlt. Auf −14 LUFS normalisiert kam sie mit −14,35 LUFS und einem True Peak von −12,67 dBTP heraus. Der Pegel stimmt nun, und die Decke wird bequem eingehalten. Die flachen Dächer sind weiterhin flach. Verzerrung leiser zu drehen ergibt leisere Verzerrung.

Was herauskommt — und die Datei, die nicht hineinkommt

Gib ihm ein Video, und das Bild wird mit -c:v copy unverändert übernommen, während der Ton durch eine frische AAC-Spur mit 192 kbit/s ersetzt wird — bei einem WebM-Container Opus mit derselben Rate, denn WebM kann kein AAC tragen. Gib ihm Audio, und du wählst die Ausgabe: MP3 mit 192 kbit/s als Standard, oder WAV als 16-Bit-PCM, M4A als AAC, OGG als Vorbis in Qualität 5, oder FLAC. Einen Stream-Copy-Weg gibt es nicht, und das ist unvermeidlich — die Samples wurden verändert, also müssen sie neu geschrieben werden. Ist deine Quelle verlustfrei, wähle FLAC oder WAV; den MP3-Standard stehen zu lassen verwandelt ein verlustfreies Master als Nebenwirkung einer Lautstärkekorrektur in ein verlustbehaftetes.

Eines hielt manche Leser auf, bevor sie anfingen. Obwohl das Werkzeug nach Audio benannt ist, fünf Audio-Ausgabeformate anbietet und über seiner Ablagefläche „Audio- oder Videodatei wählen“ schreibt, war seine Dateiauswahl nur auf Video eingestellt: die Liste enthielt MP4, MOV, WebM, MKV, AVI und M4V und keinen einzigen Audiotyp, ein hineingezogenes MP3 wurde also als falsche Art abgewiesen, und der ganze Audio-Zweig — die Formatknöpfe, die MP3- und FLAC-Ausgaben — war über die Auswahl nicht erreichbar. Jetzt nimmt sie beides an, und die Beschriftung beschreibt endlich, was das Werkzeug tut. Es lohnt zu verstehen, warum so ein Fehler überlebt: alles hinter der Auswahl funktionierte einwandfrei, also schlug nichts fehl, wurde nichts getestet, wurde nichts protokolliert. Die Funktion lag schlicht hinter einer Tür, die niemand öffnen konnte.

Häufige Fragen

Macht dieses Werkzeug auch Peak-Normalisierung?

Nein. Es macht nur Lautheits-Normalisierung, über ffmpegs loudnorm-Filter, der nach der Methode ITU-R BS.1770 in LUFS misst. Aus der Peak-Welt behält es eine True-Peak-Decke, und die ist eine Grenze, kein Ziel: Sie sagt, wie nah das Ergebnis an den Vollausschlag heran darf, nicht wie laut es klingen soll. Wolltest du wirklich Peak-Normalisierung — jede Datei so skaliert, dass ihr lautestes Sample am selben Wert liegt —, würdest du feststellen, dass zwei Clips weiterhin sehr verschieden klingen; deshalb will sie fast niemand mehr, wenn er die Alternative gehört hat.

Die Anzeige sagt, mein Ziel sei erreicht. Kann ich der Zahl trauen?

Nur der ersten Hälfte. Der Wert „Gemessen“ ist echt — er stammt aus dem ersten Durchgang, der deine Datei wirklich analysiert hat. Der zweite ist überhaupt keine Messung: Es ist das von dir gewählte Ziel, zurückgespiegelt, und die gezeigte Korrektur ist bloß die arithmetische Differenz beider. Hat ffmpeg die lineare Verstärkung abgelehnt, weil sie die True-Peak-Decke durchstoßen hätte, liegt die Ausgabe ganz woanders, und nichts auf der Seite sagt es dir. Das Warnzeichen: eine Quelle, die schon nahe am Vollausschlag spitzt und leiser ist als dein Ziel. Diese Kombination ist nicht erfüllbar, und das Ergebnis bleibt darunter.

Auf welchen Wert setze ich die True-Peak-Grenze?

Lass sie bei −1 dBTP für alles, was nach dir noch einmal kodiert wird — also fast alles. Ein verlustbehafteter Encoder gibt deine Samples nicht exakt wieder; er rekonstruiert eine Näherung, und diese Näherung kann leicht über deine Samples hinausschießen. Ein Dezibel Luft gibt diesem Überschwinger einen Platz, statt im Player des Hörers zu clippen. Die Decke Richtung null zu heben kauft dir etwas Lautheit und verbraucht deine Sicherheitsreserve — und sie macht die oben beschriebene Ablehnung des linearen Modus auch nicht unwahrscheinlicher.

Kann Normalisieren eine bereits verzerrte Aufnahme reparieren?

Nein, und das sollte man deutlich sagen. Hat die Aufnahme beim Aufzeichnen geclippt, wurden die Spitzen über dem Maximum in diesem Moment verworfen; die Datei enthält flache Dächer, wo Wellenformen waren, und nirgends steht, wie die fehlenden Teile aussahen. Normalisieren ändert den Pegel, die Verzerrung wird also leiser, aber die Form bleibt. Eine geclippte Testdatei mit einem True Peak von +0,10 dBTP kam mit −14,35 LUFS aus dem Werkzeug, ihre Spitzen sicher bei −12,67 dBTP und ihre flachen Dächer vollständig erhalten. Kannst du neu aufnehmen, nimm neu auf. Sonst raten spezialisierte De-Clipping-Programme die fehlende Kurve, mit gemischtem Erfolg.

Wozu dient der Regler für den Lautheitsumfang, und soll ich ihn anfassen?

Er beschreibt, wie stark der Pegel über das Programm hinweg schwanken darf, gemessen in Lautheitseinheiten, und steht standardmäßig auf 11 LU. Er zählt, wenn loudnorm dynamisch statt linear arbeitet: Ein niedriger Wert plättet den Abstand zwischen leisen und lauten Stellen stärker, ein hoher lässt sie weiter auseinander. Wird der lineare Weg genommen — der Normalfall, wenn Luft da ist —, wird das ganze Programm um eine Konstante verschoben und der Umfang bleibt unangetastet; der Regler ändert dann gar nichts. Lass ihn stehen, sofern dir niemand einen Umfang vorgegeben hat; und wenn du ihn senkst, um leise Sprache hörbar zu machen, willst du eigentlich einen Kompressor, keinen Normalisierer.