21.10.2019, 13:44
Hallo,
bislang glaubte ich, daß die Decodier-Resultate verschiedener mp3-Decoder so gering seien, daß man sie nur bei sehr genauem zuhören und vergleichen bemerken kann, was auch noch Kenntnis des Originals erfordere.
Gestern stieß ich auf einen Fall, bei dem ein Unterschied bei Betrachtung der Waveform geradezu "ins Auge springt".
Ich hatte eine Musik-haltige Radio-Sendung als mp3 mitgeschnitten. Der Pegel erreichte höchstens -5 dB. Danach habe ich mit mp3DirectCut die Zwischen-Moderation entfernt. Da die Sendung sehr "dicht" gestaltet war, gab es keine Pausen ohne Signal zwischen Moderation und Musik.
Danach habe ich den Pegel mit der "Normalize"-Funktion um 4.5 dB angehoben, sodaß der Spitzenpegel bei -0.5 dB lag.
Anschließend habe ich das "Werk" in Audacity geladen zwecks optischer Waveform-Kontrolle.
Da sah ich bei Minute 32 eine rot markierte Übersteuerung. Beim Hinein-Zoomen wurde ein wild oszillierender Transient erkennbar, der in den Spitzen +2.5 dB erreicht. Die Länge entspricht etwa einem mp3-Frame (~24 ms).
Weil so eine Signalspitze vorher nicht da war, kam mir das merkwürdig vor. Deshalb habe ich den mp3-File extern mit ffmpeg 4.0.2 in einen wav-File gewandelt und zum Vergleich ebenfalls in Audacity importiert. Es wurden 2 Unterschiede deutlich: Die Waveforms sind zunächst synchron. Ab etwa Minute 21:27 hat ffmpeg offenbar in einer kurzen Stille-Phase einen Leer-Frame eingefügt (oder Audacitys mp3-Decoder einen weggelassen). Ab da hat der wav-File eine Verzögerung von einem Frame (1152 Samples). Ziehe ich die Waveform für den weiteren Vergleich um einen Frame vor, finde ich an der verdächtigen übersteuerten Stelle des ersten Files im zweiten File einen "sauberen" Signal-Übergang zwischen einer Sektion niedrigen Pegels und einer mit hohem Pegel ohne Übersteuerung.
Solche drastischen Decodier-Unterschiede habe ich bislang nicht gesehen.
Dieser Screen Shot zeigt einen kurzen Ausschnitt um die "Stör"-stelle:
Oben die von Audacity erzeugte Decodierung,
darunter das von ffmpeg erzeugte Signal.
Bei Audacity.org ist zu lesen, daß das Programm default-mäßig mp3 mit libmad decodiert. Eine Version von mpg123 oder mpg321 (mit libmad "verwandt") lieferte bei mir auch einen Spitzenpegel von ~2.5 dB, während ffmpegs astats Befehl -0.5 dB meldet. Da gibt es also 3 dB "Meinungs"-Unterschied.
Das ffmpeg-Ergebnis ist "gefälliger", was aber nicht beweist, daß es richtig ist.
Ich habe leider kein Tool, mit dem ich mir ansehen kann, was die in Windows enthaltenen Fraunhofer-Decoder l3codeca.acm und l3codecp.acm daraus machen.
Das Problem hat möglicherweise mit dem Schneiden mittels mp3DirectCut zu tun. Die mp3-Codierung sieht vor, daß komplexe Frames, die viele Bits zur Artefakt-armen Beschreibung brauchen, diese Bits in weniger beanspruchten vorherigen Frames unterbringen können (wird "Bitreservoir" genannt). Wenn solche vorigen Frames entfernt werden, fehlen dem folgenden Daten oder er benutzt falsche Daten aus dem durch Schnitt neuen Vorgänger. Was dann passiert, ist völlig unklar. Da die Frames keine Name haben, ist nicht erkennbar, ob der vorige der richtige ist. Unklar ist auch, ob per Konsistenz-Prüfung erkennbar ist, ob Daten in vorigen Frames zumindest formal die richtigen sind. Eine mögliche Erklärung wäre also, daß hier eine Schnittstelle vorliegt mit Bezug zu nicht meht vorhandenen vorigen Frames, die libmad fehl-interpretiert, während ffmpeg was merkt und einen gefälligeren Übergang erzeugt.
Es ist also nicht ganz egal, welchen mp3-Decoder man verwendet.
libmad wird auf den Internetseiten von Audacity hohe Qualität zugeschrieben.
Das Resultat von ffmpeg scheint mir hier besser zu passen.
MfG Kai
Nachtrag:
Da es ohnehin immer besser ist, sich eine Sendung (sofern möglich) aus der Mediathek des Anbieters zu verschaffen, habe ich das hier auch getan. Es handelte sich um den DLF. Gerade eben habe ich diese Version (ADTS-AAC-LC) in gleicher Weise bearbeitet wie oben beschrieben, und eben in Audacity mit der mp3 und wav-Version verglichen. An der "Stör"-Stelle sieht der File sehr der wav-Version (ffmpeg) ähnlich. Den wilden Transienten von Audacity/libmad gibt es da auch nicht. Dazu sind noch zwei Dinge zu ergänzen:
1. In AAC-Files gibt es kein "Bitreservoir", daß sich über frühere Frames erstreckt. Schneiden auf Frame-Level ist also gefahrloser.
2. Audacity benutzt ffmpeg (2.2.2) zum Decodieren von AAC-Files.
bislang glaubte ich, daß die Decodier-Resultate verschiedener mp3-Decoder so gering seien, daß man sie nur bei sehr genauem zuhören und vergleichen bemerken kann, was auch noch Kenntnis des Originals erfordere.
Gestern stieß ich auf einen Fall, bei dem ein Unterschied bei Betrachtung der Waveform geradezu "ins Auge springt".
Ich hatte eine Musik-haltige Radio-Sendung als mp3 mitgeschnitten. Der Pegel erreichte höchstens -5 dB. Danach habe ich mit mp3DirectCut die Zwischen-Moderation entfernt. Da die Sendung sehr "dicht" gestaltet war, gab es keine Pausen ohne Signal zwischen Moderation und Musik.
Danach habe ich den Pegel mit der "Normalize"-Funktion um 4.5 dB angehoben, sodaß der Spitzenpegel bei -0.5 dB lag.
Anschließend habe ich das "Werk" in Audacity geladen zwecks optischer Waveform-Kontrolle.
Da sah ich bei Minute 32 eine rot markierte Übersteuerung. Beim Hinein-Zoomen wurde ein wild oszillierender Transient erkennbar, der in den Spitzen +2.5 dB erreicht. Die Länge entspricht etwa einem mp3-Frame (~24 ms).
Weil so eine Signalspitze vorher nicht da war, kam mir das merkwürdig vor. Deshalb habe ich den mp3-File extern mit ffmpeg 4.0.2 in einen wav-File gewandelt und zum Vergleich ebenfalls in Audacity importiert. Es wurden 2 Unterschiede deutlich: Die Waveforms sind zunächst synchron. Ab etwa Minute 21:27 hat ffmpeg offenbar in einer kurzen Stille-Phase einen Leer-Frame eingefügt (oder Audacitys mp3-Decoder einen weggelassen). Ab da hat der wav-File eine Verzögerung von einem Frame (1152 Samples). Ziehe ich die Waveform für den weiteren Vergleich um einen Frame vor, finde ich an der verdächtigen übersteuerten Stelle des ersten Files im zweiten File einen "sauberen" Signal-Übergang zwischen einer Sektion niedrigen Pegels und einer mit hohem Pegel ohne Übersteuerung.
Solche drastischen Decodier-Unterschiede habe ich bislang nicht gesehen.
Dieser Screen Shot zeigt einen kurzen Ausschnitt um die "Stör"-stelle:
Oben die von Audacity erzeugte Decodierung,
darunter das von ffmpeg erzeugte Signal.
Bei Audacity.org ist zu lesen, daß das Programm default-mäßig mp3 mit libmad decodiert. Eine Version von mpg123 oder mpg321 (mit libmad "verwandt") lieferte bei mir auch einen Spitzenpegel von ~2.5 dB, während ffmpegs astats Befehl -0.5 dB meldet. Da gibt es also 3 dB "Meinungs"-Unterschied.
Das ffmpeg-Ergebnis ist "gefälliger", was aber nicht beweist, daß es richtig ist.
Ich habe leider kein Tool, mit dem ich mir ansehen kann, was die in Windows enthaltenen Fraunhofer-Decoder l3codeca.acm und l3codecp.acm daraus machen.
Das Problem hat möglicherweise mit dem Schneiden mittels mp3DirectCut zu tun. Die mp3-Codierung sieht vor, daß komplexe Frames, die viele Bits zur Artefakt-armen Beschreibung brauchen, diese Bits in weniger beanspruchten vorherigen Frames unterbringen können (wird "Bitreservoir" genannt). Wenn solche vorigen Frames entfernt werden, fehlen dem folgenden Daten oder er benutzt falsche Daten aus dem durch Schnitt neuen Vorgänger. Was dann passiert, ist völlig unklar. Da die Frames keine Name haben, ist nicht erkennbar, ob der vorige der richtige ist. Unklar ist auch, ob per Konsistenz-Prüfung erkennbar ist, ob Daten in vorigen Frames zumindest formal die richtigen sind. Eine mögliche Erklärung wäre also, daß hier eine Schnittstelle vorliegt mit Bezug zu nicht meht vorhandenen vorigen Frames, die libmad fehl-interpretiert, während ffmpeg was merkt und einen gefälligeren Übergang erzeugt.
Es ist also nicht ganz egal, welchen mp3-Decoder man verwendet.
libmad wird auf den Internetseiten von Audacity hohe Qualität zugeschrieben.
Das Resultat von ffmpeg scheint mir hier besser zu passen.
MfG Kai
Nachtrag:
Da es ohnehin immer besser ist, sich eine Sendung (sofern möglich) aus der Mediathek des Anbieters zu verschaffen, habe ich das hier auch getan. Es handelte sich um den DLF. Gerade eben habe ich diese Version (ADTS-AAC-LC) in gleicher Weise bearbeitet wie oben beschrieben, und eben in Audacity mit der mp3 und wav-Version verglichen. An der "Stör"-Stelle sieht der File sehr der wav-Version (ffmpeg) ähnlich. Den wilden Transienten von Audacity/libmad gibt es da auch nicht. Dazu sind noch zwei Dinge zu ergänzen:
1. In AAC-Files gibt es kein "Bitreservoir", daß sich über frühere Frames erstreckt. Schneiden auf Frame-Level ist also gefahrloser.
2. Audacity benutzt ffmpeg (2.2.2) zum Decodieren von AAC-Files.