Pre-Gain doch nicht gut?

Hallo,

ich habe ein Problem mit der Normalisierung.

Bisher war ich ein großer Fan von Pre-Gain (BeSweet: -ota( -norm 0.97) )
Ich sehe in PreGain folgende Vorteile:
1: Echtes 2-Pass-Verfahren, müßte besonders genau sein.
2: Die ermittelte Verstärkung wird während der Transcodierung angewandt, die Daten werden daher wirklich auf's Maximum (FullScale) skaliert und nicht erst nachher beim Abspielen durch einen PostGain-Wert skaliert.
3: Da PostGain immer 0dB bzw. Faktor 1 ist, macht es nichts, wenn der Player PostGain nicht unterstützt. Habe da z.B. WinAmp im Verdacht.

Nun kommt das Problem:

Beim Transcodieren eines AC3-Ton's ermittelt Pre-Gain "Overall Track Gain: 10.132dB". Nehme ich andere Parameter, z.B. --maximize bei -azid oder --normalize bei -ssrc wird ein Overall Track Gain: 10.397dB ermittelt. 10.397 ist auf 100% skaliert, 10.132 auf 97%. Beides ist viel zu viel!! Der Ton ist verzerrt!

Nehme ich nun hybridgain (BeSweet: -ota (-hybridgain) ), steht in der Log-Datei "PostGain normalize to : 0.97". Hiermit ist der Ton in Ordnung.

Wie kommt das nur? Warum macht PreGain was falsch, hybridgain aber nicht?

Danke

akapuma

Tja, die Sache läuft noch schlechter, als ich dachte, denn hybridgain tut's auch nicht, wenn ich zu Ende transcodiere. Als Anlage füge ich mal mein Problem bei:

TEST.AC3
Das Original, klar und sauber.

TEST1.OGG
Normalisierung: Pregain-Normalisiert mit -g 0.97
Log-Datei: Overall Track Gain: 12.519dB
Ergebnis: Clipping, total übersteuert, absoluter Mist.

TEST2.OGG
Normalisierung: -hybridgain
Log-Datei: vorn: PostGain normalize to : 0.97, hinten: Gain of 8.5dB had been asserted to file.
Ergebnis: Clipping, total übersteuert, absoluter Mist.

TEST3.OGG
Normalisierung: nichts (garnichts!)
Log-Datei: Natürlich nichts zur Normalisierung
Ergebnis: OK!!!!!!!!!!!!!!!!!!!!!!!!

Es geht mir hier nur um die Normalisierung, nicht um die anderen Parameter. Bei TEST3 hat's mit denen ja auch geklappt.

Was kann ich hieraus für einen Schluß ziehen? Nicht mehr normalisieren? Daß kann's ja wohl nicht sein! Daher gibt's nur eins:

Bitte helft mir!

Alle beschriebenen Dateien samt LOG's im Anhang.

Danke

akapuma

Weiß wer, warum Anhängen nicht klappt. Nur 37kB! Ich versuch's nochmal.

akapuma

Hallo,

ich glaube mal, die Ursache des Übels gefunden zu haben. Das Problem tritt bei mir nämlich nur bei 2-Kanal-AC3-Dateien auf, nicht aber bei 5-Kanal-AC3-Dateien. Daher stell ich jetzt mal ne Theorie auf:

Bei 5-Kanal-Dateien kommt der Ton aus 5 Lautsprechern, bei 2-Kanal-Dateien nur aus 2 Lautsprechern. Bei gleicher Lautstärke aus jedem einzelnen Lautsprecher kommt bei 5-Kanal-Ton also 2,5 mal soviel raus. Bei der Normalisierung des 2-Kanal-Ton's denkt die Normalisierung daher, der Ton könnte 2,5 mal so laut sein und macht ihn deshalb 2,5 mal lauter. 2,5x lauter entspricht etwa 7,96dB. Nun werden die 2 einzelnen Lautsprecher um ca. 7,96dB verstärkt. Da diese aber nicht zu leise waren, kommt es zu extremem Clipping, der Ton hört sich schrecklich an. So sahen meine BeSweet-Parameter aus:

-core( -input "%input%" -output "%output%" -logfile "%log%" ) -ota( -norm 0.97 ) -azid( -L -3dB -c none -s stereo -n1 -f1 ) -ssrc( --rate 44100 --twopass --dither 3 ) -boost( /b2=5 ) -ogg( -q 0.000 ) -profile( %version% )

Zur Normalisierung steht in der LOG-Datei:

Input : C:\Test\Test.ac3
Output: C:\Test\Test.ogg
Floating-Point Process: Yes
Overall Track Gain: 10.132dB

Als Abhilfe habe ich nun zuerst aus dem 2-Kanal-AC3-Ton einen WAV-2-Kanalton erzeugt:

-core( -input "%input%" -output "%output%" -2ch -logfile "%log%" ) -azid( -L -3dB -c none -s stereo -n1 -f1 -F wav32 ) -ssrc( --rate 44100 --twopass --dither 3 ) -boost( /b2=5 ) -profile( %version% )

Zur Normalisierung steht natürlich nichts in der Log-Datei, da ja nichts normalisiert wurde:

Input : C:\Test\Test.ac3
Output: C:\Test\Test.WAV
Floating-Point Process: No

Nun habe ich den WAV-2-Kanalton mit Normalisierung in einen ogg-Ton transcodiert. Hier rafft die Normalisierung, daß der Eingang nur ein 2-Kanal-Ton ist:

-core( -input "%input%" -output "%output%" -logfilea "%log%" ) -ota( -norm 0.97 ) -ogg( -q 0.000 ) -profile( %version% )

Input : C:\Test\Test.wav
Output: C:\Test\Test.ogg
Floating-Point Process: Yes
Overall Track Gain: 2.855dB

Ergebnis von AC3 => WAV => OGG: Perfekt, kein Clipping, alles Klasse. Subtrahiert man nun die beiden von BeSweet verwendeten Normalisierungen, ergibt das 10,132dB-2,855dB=7,277dB. Nach meiner Theorie müßten es 7,96dB sein, was zuerst zuviel verstärkt wurde, die Werte passen also gut zusammen.

Diese Probleme müßte an sich JEDER haben, der einen 2-Kanal-AC3-Ton Normalisiert!

Trotzdem habe ich noch 2 Fragen:

1. Warum steht bei der Umwandlung von AC3 in WAV Floating-Point Process: No? Ist das normal?
2. Bei der Methode AC3 => WAV => OGG muß ich BeSweet zweimal starten. Kann ich die beiden Schritte zusammenfassen, aber so, daß auch tatsächlich ein WAV-File gebildet wird. Wäre eine sehr willkommene Erleichterung!

Gruß

akapuma

PS:

Wer jetzt Schreiben will, daß -q 0.000 zu wenig ist: Ich will KEINEN sourround-Ton, sondern lediglich einen 64kbps-Stereoton. Dafür ist -q 0.000 richtig. Sourround oder Stereo hat auch keinen Einfluß auf das Problem.

Ich weiß, daß der Parameter -f1 bei -azid für ein 2-Kanal-AC3-Ton als Eingangsgröße unnötig ist, ich suche aber eine "Universallösung", die 2- und 5-Kanal-Ton transcodieren kann. -f1 hat auch nichts mit dem Problem zu tun.

Zitat

Original von LigH
aber ich kapiere irgendwie immer noch nicht, warum du der einzige bist, bei dem ausgerechnet Pre-Gain nicht funktionieren soll - denn theoretisch kann der ja gar nicht übersteuern

Vielleicht fällt es ja nicht so oft auf, da:
1: doch eher 5.1-AC3-Spuren verwendet werden
2: geringeres Clipping ja nicht umbedingt auffallen muß

Zitat

Original von LigH
Wenn also nicht mormalisierter (zu leiser) Ton bei dir ordentlich klingt und normalisierter (optimal ausgesteuerter) zu laut, dann kann ich mir das nur so erklären, dass irgendwo dazwischen noch ein verstärkender DirectShow-Filter hängt (vielleicht der TFM - oder wie der hieß...).

Habe mal ein AC3-File abgespielt, folgende Filter sind beteiligt:

Filtername - Filterdateiname - benötigt
AC3 Parser Filter - MPG2SPLT.AX - ja
AC3 Filter - AC3Filter.AX - nein
MatrixMixer - Matrix_Mixer.ax - nein
Channel Downmixer by Trombettworks - Channeldownmixer.ax - nein
Default DirectSound Device - Quartz.dll - ja

Die mit "ja" gekennzeichneten Filter wurden umbedingt benötigt. Die mit "nein" gekennzeichneten habe ich vorübergehend entfernt. Leider hat es nichts gebracht.

Zitat

Original von LigH
Überprüfen ließe sich das, wenn du mal eine encodierte, normalisierte Tonspur wieder nach WAV decodierst und in einem Wave-Editor anschaust (in Frage kämen: CoolEdit, GoldWave, vielleicht auch Nero's Wave-Editor oder Audacity - die dürften alle MP3 und Ogg Vorbis decodieren können). Tritt dort auch eine Übersteuerung auf (optisch in der Wellenform), ist sie tatsächlich in der Datei; passiert es nur beim Anhören, dann funkt ein zusätzlich verstärkender DirectShow-Filter dazwischen.

Du schreibst, die Tonspur wieder in WAV decodieren und dann anschauen. Danach steht, die Programme dürften auch Ogg Vorbis decodieren können. Das wiederspricht sich irgendwie, oder ich hab's nicht verstanden. Irgendwie sieht in Wave-Editoren bei mir alles gleich übersteuert aus, zumindest als ogg. wav hab ich hier noch nicht probiert.

Bevor ich die Lösung kenne, gibt es eine Möglichkeit, eine Umwandlung AC3>WAV>OGG vorzunehmen und dabei BeSweet zur einmal zu starten?

Gruß

akapuma

Zitat

Original von LigH
Für das Abspielen von AC3-Audio brauchst du keinen AC3-Decoderfilter?!

Das habe ich nochmals überprüft. Wenn ich den AC3Filter deaktiviere, übernimmt der intervideo Audio Decoder dessen Aufgabe. Das hatte ich zuerst garnicht bemerkt.

Zitat

Original von LigH
Haarspalter... Du kannst Ogg Vorbis mit OggDec (oder z.B. auch OggDropXP) nach PCM-WAV decodieren und dann das WAV öffnen, oder du läßt die Decodierung beim Öffnen der Ogg-Datei vom Sampleeditor selber durchführen.

Haarspalterei lag mir fern, wirklich! Hatte nur nochmals nachgefragt, weil ich alles richtig machen wollte.

Zitat

Original von LigH
-ssrc(--twopass) ist Unsinn - das wird durch den "strömenden" Ablauf gar nicht unterstützt.

Glaub ich Dir auf's Wort, machte mir auch keinen twopass-Eindruck. Hatte aber mal gelesen (von Dir?), daß "--rate 44100 --twopass --dither 3" die richtigen Einstellungen wären. Was mach ich denn nun? --twopass weglassen? Oder kann/soll/muß ich es doch irgendwie benutzen? Ich würde schon gerne von 48kHz auf 44,1kHz downsamplen!

Zitat

Original von LigH
-boost(/b2=5) - bei 2-Kanal-Ton? Ja, kein Wunder, dass das übersteuert klingt! Bei Zweikanalton empfehle ich einen Faktor um etwa 3.0 bei Methode 1, wenn man es wirklich kräftig verstärken will; bei Mehrkanalton wäre für Methode 2 ein Faktor um 4.0 ausreichend. Meiner Meinung nach ist für Zweikanalton erstens Methode 2 die falsche, und zweitens Faktor 5.0 viel zu viel.

Hier hast Du die Lösung gefunden! Allerdings hörte sich meine kleine AC3-Testdatei mit /b=3 auch nicht besser an. /b=2 war geringfügig besser, aber immer noch schlecht! Daher habe ich mal -boost weggelassen und den Azid-DRC mit -c normal und -c heavy probiert, beides war erfolgreich! Ich muß die Sache noch was austesten, möglicherweise wäre "heavy" für kleine PC-Lautsprecher besser. Das deutliche Clipping war bei beiden Einstellungen nicht zu hören!

Nun habe ich zwar eine funktionierende Lösung gefunden, klar ist mir die Sache aber immer noch nicht. In meinem Post vom 03.10.03 um 1Uhr06 hatte ich beschrieben, wie ich die AC3 mit -boost( /b2=5) in erst eine WAV-Datei und die WAV dann in eine OGG-Datei transcodiert habe. Warum hat das nur geklappt? Außerdem habe ich schon oft /b2=5 für 2-Kanalton genommen, und habe nie Clipping festgestellt. Aber mit dem azid-DRC komm ich ja jetzt klar.

Besteht nur noch die Frage, ob -ssrc auch ohne --twopass ordentlich verwendbar ist.

Gruß

akapuma

Hallo,

LigH hatte geschrieben, daß der --twopass Parameter bei -ssrc nicht verwendet werden kann, wenn man direkt AC3 in MP3 umwandelt. Gilt dies auch für den Parameter --dither 3 ?

Danke!

akapuma

Hallo LigH,

Zitat von LigH

In der BeSweet-GUI wird der Dithering-Parameter nicht mit grüner Farbe gekennzeichnet - dürfte somit also nicht wirksam sein, wenn man die DLL in BeSweet verwendet (nur als EXE).

Ob hier die BeSweetGui sehr aussagekräftig ist, glaube ich nicht. So läßt sich der Parameter -f1 (Azid1 - Output Modes - Control Rear Channel Filtering) nur anwählen, wenn Decode (Front / Rear) darüber auf 2/0 oder 3/0 entsprechend -d 2/0 bzw. -d 3/0 angekreuzt wurde. Zumindest wenn ich den Parameter -s stereo verwende, kommt aber was ganz anderes raus, je nach dem, ob ich -f1 verwende oder nicht, es läßt sich aber nicht anwählen. Andere Einstellungen hab ich nicht probiert, mag da aber auch so sein.

Jetzt nochmal zum Dithering und Deinen beiden Bildern: Du schreibst, daß dithering bei -ssrc im genannten Fall wegen der Fließkommaarithmetik nicht notwendig sei. Am Ende der Transcodierung müssen die Fließkommawerte aber, unabhängig vom ssrc, in integers umgewandelt werden. Findet dort ein dithering statt? Gerade nach Deinen Bildern und Deiner Beschreibung erscheint mir das sinnvoll.

Gruß

akapuma