Audio fürs Web und Streaming aufbereiten: Formate, Bitraten

Eine WAV-Datei klingt perfekt, ist aber als Quelle gedacht, nicht als Auslieferung. Drei Minuten Stereo mit 44,1 kHz und 16 Bit ergeben rund 30 Megabyte. Diese Datenmenge über eine Website oder einen Podcast-Feed auszuliefern, kostet Ladezeit, Bandbreite und Geduld. Genau hier setzt die Aufbereitung an: Du wandelst das unkomprimierte Master in ein verlustbehaftetes Format, das für das jeweilige Ziel passt, ohne dass die Hörer den Unterschied bemerken. Dieser Ratgeber zeigt, welches Format wann sinnvoll ist, wie du Lautheit richtig setzt und wo der Kompromiss zwischen Dateigröße und Qualität wirklich liegt.

Welche Formate der Browser tatsächlich abspielt

Im Web gilt nicht das technisch beste Format, sondern das mit der breitesten Unterstützung. MP3 läuft seit Jahren in jedem aktuellen Browser ohne Sonderbehandlung. Es ist nicht das effizienteste Verfahren, aber das verlässlichste. Wer einen Ton auf einer Seite einbinden will und keine Lust auf Browserweichen hat, liegt mit MP3 fast immer richtig.

AAC, oft als M4A-Datei verpackt, klingt bei gleicher Datenrate etwas sauberer als MP3 und ist auf Apple-Geräten der native Standard. OGG Vorbis und der modernere Opus-Codec sind beide technisch überlegen, besonders bei niedrigen Bitraten unter 96 kbit/s, wo MP3 hörbar abbaut. Der Haken: Safari unterstützt Vorbis und Opus nur eingeschränkt, daher braucht jede Einbindung eine MP3-Variante als Sicherheitsnetz.

Praktisch löst man das über das audio-Element mit mehreren Quellen. Der Browser nimmt die erste Quelle, die er beherrscht. So bekommst du Opus für moderne Browser und MP3 als Rückfall, ohne JavaScript.

Bitrate: wie viel Daten pro Sekunde nötig sind

Die Bitrate bestimmt, wie viele Daten pro Sekunde Audio gespeichert werden, und damit direkt Qualität und Dateigröße. Mehr ist nicht automatisch besser, weil das menschliche Ohr ab einem bestimmten Punkt keinen Unterschied mehr hört, die Datei aber weiter wächst.

Für Sprache, etwa eine Begrüßung oder ein Podcast in Mono, reichen 64 bis 96 kbit/s. Für Hintergrundmusik auf einer Website sind 128 kbit/s ein guter Startwert. Musik, die im Vordergrund steht und bewusst gehört wird, profitiert von 192 kbit/s. Alles darüber, etwa 256 oder 320 kbit/s, ist im Web fast immer verschenkte Bandbreite, weil der Qualitätsgewinn gegenüber der wachsenden Datei nicht ins Gewicht fällt.

Die Rechnung dahinter ist simpel und hilft beim Planen: Bitrate in Kilobit pro Sekunde geteilt durch 8 ergibt Kilobyte pro Sekunde. Bei 128 kbit/s sind das 16 Kilobyte je Sekunde, also knapp ein Megabyte pro Minute. So lässt sich die Dateigröße vor dem Konvertieren überschlagen, ohne ein einziges Werkzeug zu öffnen.

Lautheit richtig setzen statt nur laut machen

Viele unterschätzen, wie stark Streaming-Plattformen ins Material eingreifen. Spotify, YouTube, Apple Music und andere messen die wahrgenommene Lautheit in LUFS, der Loudness Units relative to Full Scale, und regeln jeden Titel auf einen Zielwert. Wer also lauter mastert in der Hoffnung, durchzusetzen, erreicht das Gegenteil: Die Plattform dreht den Titel wieder herunter, und durch die vorherige Begrenzung der Spitzen ist die Dynamik bereits zerstört.

Wer über den Zielwert hinaus laut mastert, gewinnt keine Lautstärke, sondern verliert nur Dynamik.

Die gängigen Zielwerte liegen je nach Plattform zwischen minus 14 und minus 16 LUFS integriert. Für Podcasts hat sich minus 16 LUFS bei Mono und minus 18 bei Stereo eingebürgert, abgeleitet aus der Rundfunknorm EBU R128. Statt also bis an die digitale Obergrenze zu fahren, normalisierst du auf den Zielwert und lässt einen Sicherheitsabstand bei den Spitzen, üblicherweise minus 1 dBTP, um Verzerrungen nach der verlustbehafteten Kodierung zu vermeiden.

Dateigröße gegen Ladezeit abwägen

Auf einer Website ist Audio selten das größte Asset, aber es addiert sich. Ein Hintergrundloop von zwei Minuten mit 192 kbit/s wiegt knapp 3 Megabyte. Bei mobilen Nutzern über ein schwaches Netz verschiebt das den Moment, in dem die Seite vollständig nutzbar ist, spürbar nach hinten.

Drei Hebel helfen. Erstens die Bitrate dem Inhalt anpassen, statt pauschal hoch zu wählen. Zweitens Audio nicht automatisch im Hintergrund vorladen, sondern erst bei Bedarf. Das preload-Attribut auf metadata oder none zu setzen, verhindert, dass der Browser die ganze Datei lädt, bevor jemand auf Play drückt. Drittens lange Inhalte wie Podcasts oder Mitschnitte gar nicht selbst hosten, sondern über einen spezialisierten Dienst ausliefern, der Bandbreite und Auslieferung übernimmt.

Was Podcast-Hoster konkret erwarten

Ein Podcast ist technisch nichts anderes als ein RSS-Feed, der auf Audiodateien verweist. Trotzdem gibt es klare Konventionen, an die sich die Verzeichnisse halten. Apple Podcasts und Spotify lesen die ID3-Tags der MP3-Datei aus und zeigen Titel, Episodennummer und Cover direkt an. Fehlen diese Felder oder sind sie inkonsistent, wirkt der Feed unaufgeräumt.

Beim Format dominiert MP3, seltener M4A. Für reine Sprache reicht Mono, was die Datenmenge gegenüber Stereo halbiert, ohne dass eine Stimme dadurch schlechter klingt. Übliche Bitraten liegen zwischen 64 und 128 kbit/s. Das Cover sollte quadratisch und mindestens 1400 mal 1400 Pixel groß sein, weil die Verzeichnisse kleinere Bilder ablehnen.

Ziel	Empfohlenes Format	Bitrate	Kanal
Hintergrundmusik Website	MP3 oder Opus	128 kbit/s	Stereo
Vordergrundmusik, Demo	MP3 oder AAC	192 kbit/s	Stereo
Kurzer UI-Ton, Jingle	MP3	128 kbit/s	Stereo
Podcast Sprache	MP3	96 kbit/s	Mono
Podcast mit Musikanteil	MP3	128 kbit/s	Stereo
Hörprobe Streaming-Upload	WAV oder AAC	hoch oder 256 kbit/s	Stereo

Beachte den letzten Eintrag: Wer einen Track bei einem Aggregator für Spotify oder Apple Music hochlädt, liefert bewusst hohe Qualität, oft sogar WAV. Die Plattform übernimmt die Kompression selbst und macht das auf ihre Zielwerte hin optimiert. Eine bereits stark komprimierte MP3 erneut zu kodieren, stapelt zwei verlustbehaftete Durchläufe und klingt messbar schlechter.

Ein konkretes Beispiel von WAV bis Feed

Angenommen, du hast eine 45-minütige Podcast-Folge als WAV aufgenommen, Stereo, 48 kHz, 24 Bit. Das Master wiegt rund 740 Megabyte und ist als Download unbrauchbar. Die Folge ist überwiegend Sprache mit kurzen Musikbetten am Anfang und Ende.

Der Weg sieht so aus. Zuerst normalisierst du auf minus 16 LUFS mit einem True-Peak-Limit bei minus 1 dBTP. Dann mischst du auf Mono, weil die Stimme dominiert und Stereo hier keinen Mehrwert bringt. Anschließend kodierst du nach MP3 mit 96 kbit/s. Aus 740 Megabyte werden so etwa 31 Megabyte, ein Sechzehntel des Ausgangs. Zum Schluss setzt du die ID3-Tags: Titel, Episodennummer, Staffel, Cover. Diese Datei lädst du zu deinem Hoster hoch, der den RSS-Feed generiert.

Wichtig ist die Reihenfolge: Lautheit und Mixdown passieren auf dem unkomprimierten Material, die Kompression kommt zuletzt. Wer erst komprimiert und dann normalisiert, arbeitet auf bereits beschädigten Daten und verschenkt Qualität. Für den ersten Schritt, das reine Wandeln von WAV zu MP3, brauchst du keine Cloud: Ein Browser-Konverter wie mp3-wav.de erledigt das clientseitig, ohne dass deine Aufnahme den Rechner verlässt.

Häufige Fehler beim Aufbereiten

Einige Stolperfallen tauchen immer wieder auf und kosten Qualität oder Ladezeit, ohne dass es nötig wäre. Der erste Klassiker ist die doppelte Kompression: Eine bereits als MP3 gespeicherte Datei wird bearbeitet und erneut als MP3 exportiert. Jeder Durchgang entfernt Klanganteile, und der zweite arbeitet auf bereits beschnittenem Material. Das Ergebnis klingt dumpfer, obwohl die Bitrate gleich bleibt. Die Lösung ist, Bearbeitungen immer aus der unkomprimierten Quelle vorzunehmen und erst ganz am Schluss einmal zu kodieren.

Der zweite Fehler ist die pauschal zu hohe Bitrate. Wer jede Datei vorsichtshalber mit 320 kbit/s exportiert, bläht die Auslieferung auf, ohne dass jemand den Unterschied hört. Gerade bei Sprache ist das reine Verschwendung. Der dritte Fehler betrifft die Lautheit: Material, das ohne Normalisierung hochgeladen wird, klingt im Vergleich zu professionell gemasterten Titeln entweder zu leise oder, nach aggressivem Limiting, flach und ermüdend. Der vierte Fehler ist das automatische Vorladen großer Audiodateien beim Seitenaufruf, das die wahrgenommene Ladezeit unnötig verlängert. Wer diese vier Punkte vermeidet, hat den Großteil der Probleme bereits umgangen.

So gehst du beim nächsten Projekt vor

Beginne immer beim Ziel, nicht beim Werkzeug. Frage dich zuerst, wo das Audio landet: kurzer Ton auf einer Seite, Hintergrundmusik, Vordergrundmusik oder Podcast. Daraus ergeben sich Format und Bitrate fast von selbst, die Tabelle oben nimmt dir die Entscheidung ab. Setze die Lautheit auf den passenden LUFS-Wert, bevor du komprimierst, und halte einen True-Peak-Abstand. Überschlage die Dateigröße über die Faustformel Bitrate durch 8, damit du keine bösen Überraschungen beim Laden bekommst. Und kodiere immer nur einmal aus der unkomprimierten Quelle, statt komprimierte Dateien erneut durch den Wolf zu drehen. Wer diese Reihenfolge einhält, liefert Audio, das schnell lädt, überall läuft und auf jeder Plattform sauber klingt.