AC3 Encoder, Vergleich, Analyse.

    Naja, die -400db wären ja normalerweise sehr schön, doch wenn das original nur ~ -100db hat, muß doch "something fishy" sein. Wobei ich ehrlicherweise mit dem noise level Wert nicht viel anfangen kann. Im Grunde sollte es doch sein, daß solange der Wert nicht über dem original liegt, wurde kein Rauschen hinzugefügt. Wenn der Wert doch dadrunter liegt, wurde was weggeschmissen? Man kann doch den Rauschlevel nicht künstlich ohne weiteres verbessern, oder?

    tedgo

    Daß die käuflichen besser sind liegt bestimmt auch daran, daß die ein psychoakk. Modell haben, was ac3enc meines Wissen nach nicht hat. Nur bei Rauschen sollte das eigentlich nichts ändern. Aber so ein tiefgehender Experte bzgl AC3 bin ich nun auch wieder nicht...

    Man kann den Rauschlevel schon "verbessern".
    Bei vielen Encodern wird Rauschen, wenn es einen bestimmten Schwellwert unterschreitet, als "Stille" enkodiert. Dasselbe gilt übrigens auch oft für die Kanaltrennung (wenn der Abstand zwischen Links und Rechts einen bestimmten Wert überschreitet, wird der leisere Kanal als Stille enkodiert). Meist ist das ein Teil eines psychoakustischen Modells und kann vor allem bei VBR einige Vorteile bringen. Deshalb wunderte ich mich ja ein bisschen bei BeSweet, weil ich gar nicht wusste, dass ac3enc ein psychoakustisches Modell hat, mal abgesehen davon, dass es nur CBR gibt. Aber man lernt nie aus...

    Dass auch die anderen Encoder einen höheren Geräuschspannungsabstand haben ist bei verlustbehafteten Komprimierungsverfahren noch normal. Das zeigt zumindest, dass kein Rauschen durch die Komprimierung hinzugefügt wird - und darauf kommt es ja an.
    In meinen Tests notiere ich solche Werte mit >96dB in meine Tabellen und damit als rauschfrei ;)

    Apropos Rauschen:
    Ob ein Codec nun tatsächlich nicht rauscht, oder nicht doch vor allem bei hohen Frequenzen Rauschfahnen mit sich zieht, kann man natürlich nur durch einen Hörtest feststellen.
    Wie ich schon sagte: Allein sind die Messwerte nahezu ohne Aussagekraft, nur mit einem Hörtest kann man tatsächlich die Qualität ermitteln. Die Messwerte zeigen nur auf, wo ein Codec schwächelt und was man eventuell zu erwarten hat.

    Ich habe *nicht* behauptet, ac3enc hätte ein psychoakk. Modell. Im Gegenteil, ich denke eher nicht, zumindest ist mir nichts derartiges in den Sourcen aufgefallen.

    Jedenfalls bestätigst du meine Theorie, daß eine "Verbesserung" im Grunde nur mit Wegschmeißen erreicht wird

    Nicht ganz. Die Specs, die erhältlich sind, sind für einen Dekoder. Rückwärts aufgebaut, hast du einen simplen encoder -> ac3enc...

    Prinzipiell könnte man daher einen genauso simplen DTS encoder bauen. FAAC als aac encoder ist genauso simpel aufgebaut.

    Nru zur Verdeutlichung: ac3enc und faac verhalten wohl in der möglichen Quali analog einem mp3 iso Referenz code entsprechend. (Nicht falsch verstehen, daß ich deren Quali mit mp3 vergleichen wollte...) Wenn man nun bedenkt, daß alte xing encoder besser also der iso code waren, aber der xing codec immer noch grottig war, so kann man sich ausmalen, was aus ac3enc noch herauszuholen wäre, wenn man den analog lame aufpolieren würde...

    Umgekehrt zeigt es die Stärker des Verfahrens an sich, daß man schon ohne "Tricks" zu respektablen Ergebnissen kommt.

    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">Hmm, habe mal kurz in den Source geguckt. ATH scheint der encoder doch schon zu benutzen ("/* compute masking curve */"). Aber Psychoakkustik sehe ich nicht. Um die Bitrate zu erreichen, wird einfach solange mehr quantisiert (also SNR abgesenkt), bis man beim target ist - so lese ich den Code inlk Comments, wenn ich den überfliege. Naja einleitender comment:

    Code
    /*
 * The simplest AC3 encoder
 * Copyright (c) 2000 Fabrice Bellard.
 *

    OK, dank Ausnutzung von ATH, ist das aber etwas untertrieben ;)

    Das ist ja interessant, so wie es aussieht, hat man hier auch schon mit dem RMAA (RightMark Audio Analyzer) gespielt. Ich habe nämlich vor kurzem BeSweet und Aften damit verglichen. BeSweet lag in der Version 1.5 b31, Aften in der Version 0.05 vor.

    Das Test-Signal habe ich dabei mit einer konstanten Bitrate von 256 kbps enkodieren lassen. Die notwendige Rückumwandlung von AC3 nach WAV erledigte Azid.

    [Blockierte Grafik: http://img247.imageshack.us/img247/5333/aften0010525x0300vn7.jpg]

    Aus irgendeinem Grund versagt die Berechnung des Rauschabstandes bei BeSweet. Aften zeigt hier aber schon mal gute Werte. Auch im Dynamik-Bereich kann die Aften-Lösung punkten. Während der Klirrfaktor (THD) bei BeSweet relativ hoch ist – man sieht das auch in einer der nachfolgenden Grafiken sehr gut -, sind die Werte für Aften besser. Die schlechteren Werte für die Kanaltrennung liegen darin begründet, dass in Aften standardmäßig „Stereo rematrixing“ aktiviert ist. Diese Einstellung soll bei einer konstanten Bitrate zu einer besseren Bildqualität, bei einer variablen Bitrate zu einer Bitratenersparnis führen. Das erneute Enkodieren ohne diesen Parameter (-m 0) förderte dann auch bessere Werte für die Kanaltrennung zu Tage.

    Hier die Grafiken, die das Programm erzeugt hat. Bei den mir unbekannten Begriffen habe ich die englischen Bezeichnungen einfach stehen gelassen. Vielleicht weiß der oder die eine oder andere was zu den Grafiken zu sagen. ;)

    Frequency response
    [Blockierte Grafik: http://img144.imageshack.us/img144/4995/frde6.jpg]

    Rauschabstand
    [Blockierte Grafik: http://img213.imageshack.us/img213/4831/nsur3.jpg]

    Dynamik
    [Blockierte Grafik: http://img157.imageshack.us/img157/8997/drbm8.jpg]

    Klirrfaktor
    [Blockierte Grafik: http://img183.imageshack.us/img183/7697/thdqb8.jpg]

    Intermodulation distortion test
    [Blockierte Grafik: http://img225.imageshack.us/img225/5074/imdyd8.jpg]

    Kanaltrennung
    [Blockierte Grafik: http://img139.imageshack.us/img139/935/cttg9.jpg]

    IMD (swept frequency)
    [Blockierte Grafik: http://img86.imageshack.us/img86/8887/imdsweptfrequencyyn3.jpg]

    Dass man mit den ermittelten Zahlen vorsichtig umgehen sollte, wurde ja bereits gesagt. Letztendliche Klarheit kann nur eine Hörprobe bringen. Aber wenn man die Werte und Grafiken für Aften so betrachtet, dann stehen die Vorzeichen doch gar nicht schlecht (Aften als Ersatz für BeSweet). ;)

    Qualitativ dürfte ffmpeg ac3enc nicht viel weiter sein. Aften ist da viel weiter, vor allem, wiel es komplett auf floating-point umgestellt wurde, außerdem ist es viel schneller.

    Um meine obigen Betrachtungen zu bestätigen oder ad absurdum zu führen – je nachdem ;) -, habe ich jetzt auch noch eine Hörprobe gemacht. Dazu habe ich ein Musikstück – ein Liveauftritt von einem Künstler - in den Bitraten 64, 128, 192 und 256 kbps enkodieren lassen. Vorerst genügten mir ein absolut ruhiger Raum und die Lautsprecher von meinem Notebook (harman/kardon). Seht es mir bitte nach, wenn ich mich recht „hölzern“ ausdrücke, ich bin eben kein Akkustik-Fachmann, der alle Dinge gleich beim Namen nennen kann.

    Bei einer Bitrate von 64 kbps war die Version von Aften wesentlich besser. Die BeSweet-Datei hörte sich sogar fehlerhaft an. Die Stimme des Sängers hatte ein „blechernes Echo“ und der Applaus des Publikums war absolut unnatürlich (klang fast wie ein Platzregen). Bei der Aften-Datei merkte man halt, dass die Höhen fehlen, aber man konnte das Musikstück wenigstens anhören, es war der Bitrate entsprechend stimmig.

    Bei einer Bitrate von 128 kbps fiel bei der BeSweet-Datei gleich am Anfang auf, dass etwas nicht hundertprozentig stimmte. Der Applaus klang irgendwie merkwürdig. Man merkte förmlich, dass da etwas fehlte. Insgesamt hörte sich die Aften-Datei einfach „runder“ an. Aber man merkte auch hier, dass die Höhen fehlten. Jedoch, das Musikstück war als solches wieder „stimmig“.

    Bei einer Bitrate von 192 kbps muss ich zugeben, dass es schwieriger wird. Ganz am Anfang erahne ich beim BeSweet-Stück beim Applaus etwas, dass nicht zu stimmen scheint. Auch scheint die Stimme des Sängers etwas „blechern“ zu klingen. Irgendwie fehlen auch hier die tieferen Töne. Es hört sich einfach „flacher“ an. Ganz eindeutig aber hören sich die zwei Versionen unterschiedlich an. Die Aften-Datei hört sich voller an (mehr tiefere Töne). Man kann den Unterschied zum Original durchaus hören.

    Bei einer Bitrate von 256 kbps muss ich mit dem benutzten Equipment passen. Ich bilde mir zwar ein, dass ich am Anfang am Applaus wieder einen Unterschied ausmachen kann, bin mir aber nicht hundertprozentig sicher. Ich bilde mir aber ein, einen Unterschied zum Original ausmachen zu können. Die AC3-Version von Aften klingt minimal anders. Letztendlich läuft es bei dieser Bitrate und dem verwendeten Equipment aber auf Spekulationen hinaus.

    Fazit: Das Ganze läuft eindeutig in Richtung Aften hinaus. Bei niedrigen Bitraten sind die Unterschiede enorm. Selbst bei 192 kbps hört man noch einen Unterschied zwischen den beiden Versionen. BeSweet hört sich im Vergleich zu Aften etwas „blechern“ und „flacher“ an. Aften hatte dann auch mehr Nähe zum Original.

    Vielleicht fügt der oder die eine oder andere noch einen subjektiven Hörtest hinzu? ;)

    P.S.: Nettes Detail am Rande, ich hatte auch die aktuellste HeadAC3he-Version kurz mit dem RMAA angetestet. Ich staunte nicht schlecht. Die Werte waren durchaus vielversprechend. Irgendwie hatte ich aufgrund der Grafiken den Eindruck, dass da irgendwelche psychoakkustische Dinge mit reinspielen. Einen Hörtest habe ich dann aber nicht mehr gemacht. Mir ging es hier eigentlich nur um den Vergleich BeSweet versus Aften.

    LigH

    An HeadAC3he habe ich schon lange nicht mehr weitergearbeitet, und könnte auch dauern... Du darfst aber mal raten, wer für den Großteil der Geschwindkeitssteigerung von Aften verantwortlich ist. :) Auf der devel List findet sich auch ncoh ein Patch, der u.a. eine SSE optimierte mdct enthält und Aften nochmal um die 9% schneller macht (ohne Qualitätsverlust natürlich).

    Es sollte nun mittels CMake möglich sein eine aften.dll zu erzeugen. Wäre gut, wenn das mal jemand testen könnte. Man könnte dann immer noch eine wrapper-dll drumherum basteln, wenn man's braucht... und da aften LGPL ist, gibts auch keine Probs mit der Lizenz.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden