
Warum sind MP3-Bitraten oft Vielfache von 32? Teil 2

Technisch gesehen gibt es nichts, was die MP3-Bitrate auf ein Vielfaches von 2 begrenzen könnte, da eine variable Bitratencodierung verwendet werden kann oder eine benutzerdefinierte Bitrate mithilfe einiger Flags erreicht werden kann, die nicht in der MPEG-Spezifikation verwendet werden (obwohl sie manuell implementiert werden müssen).

Damit MP3 MPEG-kompatibel und daher mit den meisten MP3-Decodern kompatibel ist, muss es eine durch die Spezifikation definierte Bitrate haben, sodass alle CBR-codierten MP3-Dateien eine Bitrate haben müssen, die ein Vielfaches von zwei ist.
Abhängig von der Ressource kann VBR codiert werden, indem die Bitrate zwischen einer festen Rate über jedem Frame geändert wird, oder es kann codiert werden, indem die verfügbaren Bits in benachbarten Frames geteilt werden (wodurch effektiv eine nicht standardmäßige Bitrate für die beiden Frames kombiniert erzeugt wird). Die Länge eines bestimmten Frames hängt von der Abtastrate ab, es gibt 1152 Samples pro Frame. Es gibt keine Grenze für die Größe des Frames selbst, noch gibt es eine Grenze dafür, die Framegröße auf Basis 2 festzulegen (d. h. ein 128-kbit/s-MP3 mit einer Abtastrate von 44,1 kHz hätte eine Framegröße von 417 Bytes).
Am Ende klingt eine mit 126 kbps codierte Datei schlechter als eine mit 128 kbps codierte Datei, und ebenso klingt eine mit 131 kbps codierte Datei besser. MP3s werden jedoch gemäß dem psychoakustischen Modell eines bestimmten Encoders für die Komprimierung codiert. Der Betrag, um den eine Datei bei einer bestimmten Bitrate “besser” oder “schlechter” klingt, hängt weitgehend von dem Algorithmus ab, der zur Implementierung des Modells verwendet wird. Im Allgemeinen können höhere Bitraten jedoch mehr Daten enthalten, wodurch wahrscheinlich ein genaueres Rohdatenstrom-Audiosignal reproduziert wird
Ich vermute stark, dass der Grund dafür, dass der MPEG-Standard Vielfache von 2 vorgibt, darin liegt, dass binäre Computer häufig mathematische Berechnungen optimieren können, die sowohl sich selbst als auch Programmierer betreffen.
Dies ist eine Bettelfrage. Glauben Sie nicht, dass es einen mathematischen/arithmetischen Grund für den gewählten Bitratenwert gibt? Oder rechtfertigt das bloße Vorhandensein von VBR keine Begrenzung möglicher Bitraten?
@slhck Ich habe gerade meine Antwort aktualisiert, um relevantere Details bereitzustellen. Bitte lassen Sie mich wissen, ob dies alle Fragen beantwortet.
MPEG 1 Layer-III (mp3)-Dateien sind Streams von Frames.
Diese Webseite beschreibt die Datenstruktur des Frameworks.
Wie Sie sehen können, werden nur 4 Bits zugewiesen, um die Bitrate zu bestimmen. Beim Entwerfen eines Formats für das Live-Streaming möchten Sie nicht mehr Platz verschwenden, als den Stream zu beschreiben.
Ich bin mir nicht sicher, warum 4 Bits als guter Kompromiss zwischen Platzbedarf und “Bitratenauflösung” bestimmt wurden – für die ausgewählte Bitrate wurden sie wahrscheinlich basierend auf dem niedrigsten und höchsten Qualitätsbereich ausgewählt, den der Ingenieur für akzeptabel hielt. mp3-Algorithmus.
Wahrscheinlich lesen die meisten MP3-Player jeweils einen Frame und versuchen wahrscheinlich, mindestens einen Frame “früh” zu puffern, wenn sie den aktuellen Frame decodieren/abspielen.
Die Größe des Frames und möglicherweise des ihm zugewiesenen RAMs ist wie folgt:
FrameSize = 144 * BitRate / SampleRate, wenn das Füllbit gelöscht ist.
FrameSize = (144 * BitRate / SampleRate) + 1Wenn das Füllbit gesetzt ist.
Höhere Bitrate/Abtastrate = mehr RAM erforderlich.
128 Kbps ist wahrscheinlich beliebt, da es die Standardeinstellung für viele Encoder ist.
Außerdem hat mir ein Kollege Einblick in die Diskussion gegeben: 128 Kbps bedeutet auch grob übersetzt “Minuten in einer Minute” (allerdings ungeprüft), hat wahrscheinlich auch etwas damit zu tun.
Wenn “Rohdaten” protokolliert werden, werden diese Daten in Blöcken gepuffert. Diese Blöcke werden offensichtlich Zweierpotenzen sein. Es ist konzeptionell einfacher, wenn Sie eine ganzzahlige Anzahl von Blöcken pro Sekunde haben.
