Aften anstatt BeSweet für wav->ac3, okay?

Archimedes1

Es spricht ja eigentlich nichts dagegen, wenn man vorher immer mit BeSweet („AC3Enc“) von WAV nach AC3 (DD 2.0) gewandelt hat, dies zunkünftig mit Aften zu machen (immerhin stammen beide Encoder vom FFmpeg-Projekt ab). Oder irre ich mich da?

Archimedes1

Ich beantworte meine Frage mal selbst.

Ich werde meine selbstgedrehten Filme von jetzt an nicht mehr mit BeSweet von WAV nach AC3 (DD 2.0) wandeln, sondern werde dazu Aften hernehmen. So schlecht war die BeSweet-Lösung nun auch wieder nicht. Und von Aften erwarte ich eher eine Verbesserung (da ständig daran weiterentwickelt wird).

LigH

In der Tat sieht es danach aus, dass Aften sich doch recht erheblich weiterentwickelt; vor allem die mit Grafiken belegten Ausgabepegel sehen zumindest "besser" aus als bei BeSweet mit AC3Enc.

Störend ist leider ein wenig, dass man als Eingangsdatei eine 6-Kanal-WAV braucht, aber mit BeSweet und BeLight's MUX-Generator (mit Preset "WAV") klappt das bei nicht allzu langen Stücken recht gut (>4 GB kann ich mit dieser Technik nicht empfehlen - die WAV-Dateien sehen nicht danach aus, im geeigneten Format vorzuliegen!).

Die Revision 221, die Kurtnoise13 von Version 0.05 anbietet, scheint bei mir jedoch eine fehlerhafte Datei zu erzeugen. Die etwas ältere Version 0.05 klang korrekt.

Archimedes1

Die geringe Lautstärke bei den BeSweet-Dateien (AC3) hat mich eigentlich nie so richtig gestört. Im Gegenteil, ich fand sie eigentlich immer passend - den Ton empfand ich in etwa so laut wie den auf Kauf-DVDs.

Ich habe mittlerweile auch festgestellt, dass AC3Enc bei niedrigen Bitraten bis etwa 128 kbps zu (hörbaren) Verzerrungen neigt, wohlwissend, dass AC3 erst ab 192 kbps Sinn macht (saubere Quellen vorausgesetzt). Bei Aften habe ich das (in dieser Stärke) noch nicht festgestellt. Auch die anderen Vorzeichen - technische Eigenschaften nach Enkodierung eines Testsignal - sehen bei Aften besser aus. Auch beschneidet Aften ein vorhandenes Frequenzspektrum nicht so stark wie AC3Enc.

Kurzum, mein letztes selbstgefilmtes Projekt habe ich bereits mit Aften erstellt. Und zwar im ganz normalen DD-2.0-Ton mit 256 kbps – zu mehr benötige ich Aften momentan auch nicht.

DarkAvenger

LigH

Ließe sich feststellen, ab welcher Rev der Fehler passiert? Mit "svn up -r NUMMER" läßt sich eine spezielle Revision ziehen. Dann ließe sich der fehlerhafte commit schnell ausmachen.

Ich glaube rev 153 ist die erste fehlerhafte und ich bin es schuld. :-/

OK, bug ist gefixt. Rev 212 sollte wieder sauberen Klang produzieren.

Allerdings, was mir aufgefallen ist: Mappt aften die Kanäle richtig? xine psielt die nämlich falch ab, wenn ich das mit der originalen ac5 Testdatei vergleiche. Da aber schon aften 0.05 dieses Verhalten zeigt, kann es nicht an mir liegen.

Archimedes1

Den Eindruck hatte ich auch schon. Ich habe das allerdings unter Verwendung von BeLight festgestellt. Habe dort die einzelnen Kanäle richtig zugeordnet (dachte ich jedenfalls). Beim Anhören der erstellten AC3-Datei stellte ich jedoch fest, dass da Verdreher drinnen waren. Auf den einzelnen Kanälen habe ich dabei - zeitlich voneinander getrennt - für 5 Sekunden ein Signal gelegt. Die vorgegebene Reihenfolge war dabei: FL, FR, C, SL, SR, LFE. Als Ausgabe erhielt ich aber: FL, C, FR, LFE, SL, SR.

Die von BeLight erzeugte Mux-Datei sah dabei wie folgt aus:

Zitat

"C:\Temp\5.1-Test\audioFL.wav"
"C:\Temp\5.1-Test\audioC.wav"
"C:\Temp\5.1-Test\audioFR.wav"
"C:\Temp\5.1-Test\audioSL.wav"
"C:\Temp\5.1-Test\audioSR.wav"
"C:\Temp\5.1-Test\audioLFE.wav"

Wenn ich AC3Enc als Encoder auswähle, scheint die Zuordung zu stimmen.

Offensichtlich muss Aften mit einer anderen Reihenfolge gefüttert werden:

Zitat

"C:\Temp\5.1-Test\audioFL.wav"
"C:\Temp\5.1-Test\audioFR.wav"
"C:\Temp\5.1-Test\audioC.wav"
"C:\Temp\5.1-Test\audioLFE.wav"
"C:\Temp\5.1-Test\audioSL.wav"
"C:\Temp\5.1-Test\audioSR.wav"

So hat die Zuordnung bei Aften (unter BeLight) jedenfalls gestimmt.

LigH

Aften verwendet die Reihenfolge, die BeLight mit dem MUX-Creator im Preset "WAV" (oder "AAC") erzeugt - so wie Archimedes1 das bereits ausführlich zeigt.

Ich finde es allerdings nicht gerade sinnvoll, 6-Kanal-WAV zu fordern, wegen 4-GB-Grenze von normalen WAV-Headern. Größere WAV-Dateien müssten wohl das Extensible-Format verwenden, da sieht der Header anders aus.

Jetzt mitmachen!