Wer reine Sprachpodcasts mit 128kBit/s oder mehr versendet, sollte meiner Meinung nach auch die Verwendung von Goldkabeln ins Auge fassen.
Etwas Hintergrund zu verlustbehafteter Audio-Kodierung und wie und wieso ihr euer Encoding und eure Audiopipeline speziell für MP3 genau ansehen solltet:
Die Kompression basiert grundsätzlich darauf, dass das Ohr nicht die gesamte Hörinformation gleich bewertet, sondern leise Frequenzbestandteile (aufgelöst in Gruppen) ohne subjektiven Verlust weggelassen werden können. Damit die zunächst als “Spannungsverlauf” gespeicherte Musik (wav oder flac-Format) überhaupt so verarbeitet werden kann, wird sie mit der Fouriertransformation (denkbar wären auch Wavelets) in Frequenzbestandteile zerlegt. Da werden dann psychoakustische Heuristiken angewendet, um den Beitrag zu quantisieren, also mit weniger Auflösung zu speichern, oder ganz auf 0 zu setzen. Da die Periodenlänge von Tönen mit hohen Frequenzen kürzer sind, und daher viel mehr in einem Zeitabschnitt auftreten, liegt es in der Natur der Sache, dass Geräusche mit hohen Frequenzen im Verhältnis viel mehr Information beinhalten.
Es bringt also extrem viel für die Kompression, wenn Signale eine begrenzte Bandbreite haben, also nur in bestimmten Frequenzbereichen einen Beitrag leisten, und möglichst wenig hohe Frequenzbestandteile besitzen. Entsprechend ist Rauschen der totale Kompressionskiller, da es im schlimmsten und idealen Fall aus allen Frequenzen besteht.
Natürlich kann man theoretisch auch dadurch sparen, dass man nur einen Kanal (also Mono) versendet als zwei Kanäle zu verwenden (Stereo). Die Verwendung von zwei gleichberechtigten und unabhängigen Kanälen in fast allen Fällen (außer z.B. Zwei-Kanal-Ton in zwei unterschiedlichen Sprachen) unsinnig ist, und stattdessen das Mischsignal in hoher Datenrate und die Unterschiede in geringerer Datenrate (siehe auch Intensitätsstereofonie) übertragen werden sollten.
Bei wechselnden Charakteristiken im Tonsignal macht es auch Sinn die Menge der übersendeten Daten zu verändern- also variable Bitraten zu verwenden. Neben der Strategie “feste Bitraten” zu benutzen (CBR- constant bitrate), gibt es auch “gemittelte Bitraten” (ABR- averaged bitrate) und “qualitätsorientierte Bitraten” (VBR- variable bitrates). Bei CBR ist die Bitrate immer konstant, bei ABR werden höhere und kleinere Bitraten je nach Anforderungen toleriert, aber eine feste durchschnittliche Bitrate garantiert, bei VBR wird die Bitrate rein durch “Anforderungen” skaliert definiert. (Und wie die “Anforderungen” oder die “Qualität” sinnvoll gemessen werden kann, und wie man darauf durch ein Regelungssystem reagiert- womöglich mit Multi-pass Encoding- ist nochmal ein ganz eigenes Thema…)
Was bedeutet das alles für unsere Audiopipeline und die Kompressionsparameter?
Beim Einzug von MP3 gab es den Goldstandard von konstanten 128kBit/s, der uns quasi “CD-Qualität” versprach. Die Kompression um das etwa 10-fache war beeindruckend, aber oft konnte man Unterschiede feststellen: Gerade am Anfang wurde noch viel bei den psychoakustischen Modellen experimentiert, oder die Aufteilung des Stereosignals erfolgte in zwei getrennten Kanälen. Eine einfache Möglichkeit mehr “Qualität” bei geringerer “Datenmenge” zu erzeugen, waren Tiefpassfilter. Dadurch, dass man schon vorher hohe Frequenzen herausfiltert (oder eine geringere Abtastrate als 44kHz zu verwenden), hat man die schwierigsten Bestandteile schon vor Kompression gelöscht.
Mit verschiedenen Hörtests wurden dann Werte gefunden, die für typische Anwendungen (insb. kontinuierliche Musik) für jeweils bestimmte Bitraten die subjektiv beste Abbildung des Signals für viele Menschen liefert. Für spezielle Anwendungen können aber ganz andere Werte sinnvoll sein, und aus meiner Sicht ist dies bei Sprachpodcasts ganz sicher der Fall:
- Sprache ist nie kontinuierlich- ihr macht (hoffentlich) Pausen beim Reden.
- Es spricht meisstens nur eine Person aus einer Richtung.
- Stimmen sind stark beschränkt in ihrer Bandbreite.
Das sind riesige Vorteile für die Kompression, die ihr beispielsweise mit folgenden Dingen kaputt machen könnt:
- Musik oder Atmo in den Hintergrund legen
- Musik oder andere Geräusche einspielen
- Rauschen in Stille nicht ausblenden
- Generell Störgeräusche zulassen (z.B. im oben zitierten LS001 das Brummen und Rauschen)
- Schall auf zweitem Kanal aufnehmen (fehlendes Crossgating/Übersprechen)
- Unterschiedliche Intensität der Sprechenden auf Kanälen zulassen (veränderliches Panorama)
Die ersten beiden Dinge sind teilweise ja gewollt oder erwünscht. Dann wird man über die Standardwerte nicht herumkommen und sollte mit hohen Bitraten kodieren (zB @Explikator, @Dennis_SciPie, @modnerd). In allen anderen Fällen kann man mit speziellen Codecs (wie Opus) aber auch definitiv aus MP3 noch viel mehr herauskitzeln, so dass spezielle Codecs in vielen Fällen keine großen Vorteile mehr besitzen.
Wenn die Audiopipeline in der Stille wirklich das Rauschen herausblendet, so kann man hier sehr viel gewinnen: Für Stille braucht man keine 128kBit/s, sondern da reichen 32kBit/s, das ist das Minimum bei MP3. Damit der Encoder das realisieren kann, sollte man auf jeden Fall CBR vermeiden und auf ABR oder VBR wechseln. Ja, es gibt noch sehr, sehr alte Player, die mit veränderlichen Bitraten Probleme haben. Werft sie weg. Wir haben 2015.
Generell ist Rauschen oder anderes Störgeräusch der Killer schlechthin- gute Mikros mit festem Abstand zum Sprecher und symmetrische Übertragung bringt euch auch wegen der Kompression einen großen Qualitätsgewinn.
Verwendet Crossgating gegen das Übersprechen und Hall, und pegelt Personen fest auf eine Panoramastellung zwischen Links und Rechts. Dann habt ihr die Vorteile der besseren Personenauflösung durch Stereo ohne Qualitätsverluste oder höhere Bitraten- siehe auch die Diskussion zu Stereo/Mono. Insgesamt unterscheidet sich hier Sprach-Stereo völlig von Musik-Stereo: Musik braucht durch unterschiedliche Tonquellen an unterschiedlichen Orten wirklich zwei Kanäle, bei Sprache ist es nur eine Quelle an festem Ort und so wird nur diese (bei Stereo) kodiert. Wenn man das richtig macht, so erhält man schon alleine deshalb mit 80kBit/s bei Sprache lässig die Qualität von 128kBit/s bei Musik. (Auch hier tut sich ein weites Feld auf: Eigentlich will man Personen nicht nur mit “Pegel” in Stereo verorten, sondern auch Laufzeitunterschiede zulassen, aber das können die Encoder nicht “erkennen” und macht die Kompression kaputt.)
Auch wenn ihr das alles befolgt, hört ihr sicher sofort einen Unterschied, wenn ihr jetzt mit beispielsweise 64kBit/s statt 128kBit/s eure Podcasts kodiert. Das liegt zum ganz großen Teil am Tiefpassfilter, der bei Musik mit hohen Bandbreiten ganz sicher Vorteile hat, aber bei schmalbandiger Sprache schon im Vorfeld ohne Not das Signal nicht nur verfälscht, sondern richtig kaputt gemacht.
Bei lame ist der Tiefpassfilter bei 192kBit/s bei 19.2kHz, bei 128kBit/s bei 17kHz, bei 96kBit/s bei 15.5kHz (mit resampling auf 32kHz), bei 64kBit/s bei 11.2kHz (mit resampling auf 24kHz). Da könnt ihr euch die Aufnahme bei 44.1kHz Samplefrequenz sparen, wenn der Encoder gleich mal jedes zweite Byte einfach wegwirft, noch lange bevor das psychoakustische Modell mal eine Chance hat, eine sinnvollere Auswahl zu treffen: Das Resultat klingt dumpf.
Glücklicherweise kann man das ausschalten, und voilá- plötzlich klingt auch durchschnittlich 64kBit/s für Sprachpocasts ganz passabel, wenn man auch die anderen Punkte oben beachtet. Meiner Erfahrung nach geht es aber nicht wirklich tiefer mit MP3- es hängt auch von den Stimmen ab. Da es ja Menschen mit höheren Stimmlagen gibt, wie auch bei unserem Podcast, sollte man die Bitrate nicht fest auf einen Wert wie 64kBit/s (per ABR) festlegen, sondern die Bitrate von den Anforderungen abhängig machen, also VBR verwenden.
Wir verwenden seit einiger Zeit und Optimierung folgendes MP3-Encoding
lame -V8.5 -q0 --lowpass 22050 --resample 44100
und haben in den letzten Folgen (bei >99% MS-Encoding durch Crossgating) diese Bitraten erreicht: Folge 63 hat gesamt 67kBit/s, Folge 64 hat 69kBit/s und Folge 65 wieder 67kBit/s. Folgen mit viel Atmo oder Hall erhalten automatisch mehr- Folge 56 von der Gulaschprogrammiernacht hat 74kBit/s. Das ganze in Stereo und bisher ohne jeglichen negativen Kommentar zur Qualität- ganz im Gegenteil.
Your milage may vary, aber wir kommen sehr gut mit den niedrigen Bitraten zurecht und brauchen daher keine weiteren Feeds. Und man kann uns in vielen Teilen der Edge-Hölle noch streamen. =)