Beiträge von Archimedes1

Wenn du eine „möglichst laute Wiedergabe“ erreichen willst, dann sorge dafür, dass der Ton so bleibt, wie er ist, d. h., belasse den Dialognormalisierungswert auf -31 dB. Je höher der eingestellte Wert (z. B. -27 dB), desto leiser wird die resultierende AC3-Datei. Bei einem eingestellten Wert von -31 dB wird an der Lautstärke nichts verändert. Dass du das Ganze zunächst ohne Dynamikkompression ausprobierst, ist vollkommen richtig. Erst beim Anhören über eine entsprechende Anlage wird man feststellen, ob DRC überhaupt benötigt wird oder nicht. Wenn DRC tatsächlich zum Einsatz kommen soll, dann muss der Dialognormalisierungswert richtig eingestellt werden!

Was PowerDVD betrifft, schau doch mal in der Konfiguration unter „Audio“ und „Erweitert…“ nach, ob eine Dynamikkompression aktiv ist (z. B. „Laute Umgebung“).

Ich habe mittlerweile von Hank auch einen Hinweis erhalten, dass man der Anzeige des BitRate Viewers bzgl. der Quantisierungskurve wohl nicht so vertrauen kann. Offensichtlich ermittelt der BitRate Viewer die Quantisierungswerte nur unzureichend bzw. falsch.

Ein Bild (Mpeg 2) ist im Prinzip ja nichts anderes als ein mit Makroblöcken ausgefülltes Raster. Makroblöcke werden wiederum zu sog. Slices zusammengefasst (vereinfacht ausgedrückt).

Der BitRate Viewer liest offensichtlich immer nur den ersten Quantisierungswert eines Slices und bildet daraus einen Durchschnitt für den ganzen Frame. Da die Quantisierungswerte, je nach verwendeten Encoder, von Makroblock zu Makroblock aber sehr unterschiedlich sein können, ist die Anzeige alles andere als repräsentativ.

Ich war ja wirklich am Zweifeln, ob gewisse Features von Dolby Digital bei selbstgefilmten Material überhaupt Sinn machen. Speziell die Dynamik-Reduzierung hielt ich diesbezüglich für überflüssig. Auch die Verwendung des integrierten Mikrofons eines DV-Camcorders schien mir ein limitierender Faktor diesbezüglich zu sein.

Die Analyse meiner Videos ergab dann aber ein etwas anderes Bild. Ich fand heraus, dass es zwar Videos gab, die ohne Dynamik-Reduzierung auskamen, aber es gab auch Videos, bei denen eine Dynamik-Reduzierung, wie soll ich sagen, zu einer verbesserten Annehmlichkeit beim Anhören führte.

Ohne Dynamik-Reduzierung musste ich bei manchen Videos zwischen leisen und lauten Stellen immer die Lautstärke regulieren - zum einen, damit ich die leisen Dialoge verstand und zum anderen, damit die lauten Stellen nicht zu laut wurden. Nach der Dynamik-Reduzierung – ich verwendete die Einstellung "Film Standard" – musste ich die Lautstärke während dem Betrachten nicht mehr regulieren. Leise Stellen wurde etwas lauter wiedergegeben, laute Stellen etwas leiser. Das, was letzten Endes auch der Sinn der Dynamikreduzierung ist, einfach ausgedrückt.

Beispiel für so einen Fall: Das Mikrofon (der Camcorder) befand sich in der Nähe eines spielenden Kindes. Ein Kind spricht leise zu einer anderen Person (ich muss die Lautstärke erhöhen, damit ich den Dialog verstehe). Anschließend macht es mit einem Gegenstand sehr laute Geräusche (ich muss die Lautstärke wieder reduzieren, weil es sonst zu laut wird). Ich muss aber auch sagen, dass ich den Ton beim Videoschnitt für gewöhnlich unangetastet lasse, soll heißen, es finden keine Lautstärkeanpassungen und dergleichen statt.

Ich habe mir jetzt auch noch mal die Arbeit gemacht, und für jedes Profil eine Grafik angefertigt. Auf diese Weise kann man die Unterschiede zwischen den Profilen sehr schön sehen. Den Bereich, wo keine Veränderung der Lautstärke stattfindet, nennt man „Null Band“. Die Mitte dieses „Null-Band-Bereiches“ befindet sich exakt bei -31 dB. Jetzt ist es vielleicht verständlicher, warum es bei der Verwendung der Dynamikreduzierung so wichtig ist, dass der Dialog-Normalisierungswert richtig ermittelt wird.

[Blockierte Grafik: http://img180.imageshack.us/img180/3245/dynamicrangecontrol0104yk7.jpg]

[Blockierte Grafik: http://img371.imageshack.us/img371/8283/dynamicrangecontrol0204wy8.jpg]

[Blockierte Grafik: http://img329.imageshack.us/img329/9429/dynamicrangecontrol0304qd3.jpg]

In der Regel wird man bei DV-Videos die Dynamikreduzierung eher weniger benötigen – das hängt einfach vom Film ab - und wenn, dann würde ich eher moderater an die Sache herangehen und die Einstellung "Film Light" wählen.

Normalerweise sehe ich mir den Film vor der Weitergabe ja noch mal in aller Ruhe auf einem Fernseher an. Dabei fallen mir dann oft Kleinigkeiten auf (Schnitt, Ton etc.), die ich in der Regel dann noch mal bereinige. Die Enkodierung nach AC3 erfolgt dabei zunächst mit: "aften –b 256 input.wav output.ac3", ohne irgendwelche Filter. Zukünftig werde ich aber noch mehr auf den Ton achten, auf die Annehmlichkeiten beim Anhören.

Die Dialog-Normalisierung, auch Lautstärke-Normalisierung genannt, ist ja zu nichts anderes da, damit die verschiedenen DVDs in etwa die gleiche Lautstärke aufweisen. Wenn ich gerade einen Action-Film auf DVD angesehen habe und anschließend einen romantischen Film anschaue, dann brauche ich im Idealfall nicht am Lautstärkeregler drehen. Dieser Wert sagt dem Decoder, wie weit die durchschnittliche Lautstärke eines Dialogs von der Referenzlautstärke (ebenfalls basierend auf einem Dialog) entfernt ist.

Natürlich wird man bei einem privaten Video den Aufwand in Grenzen halten. Welche Einstellung für diese Art von Videos überhaupt sinnvoll ist, muss erst durch Tests ausfindig gemacht werden.

monx:
Eigentlich sollten bei dieser relativ hohen Bitrate keine hörbaren Unterschiede zwischen der Quelldatei (WAV, 48 kHz) und der AC3-Datei auszumachen sein. Allerdings sind die AC3-Dateien von BeSweet ca. 6 db leiser als das Original. Selbst wenn man den Lautstärkeregler nachdreht, hört sich die AC3-Datei nicht so toll an. Vielleicht ist es auch das, was dir negativ aufgefallen ist. Auch „Clipping“ ist ein mögliches Problem.

Ich würde die WAV-Dateien (44.1 kHz) zunächst mit SSRC auf 48 kHz bringen.

ssrc_hp --rate 48000 –twopass audio_44.1kHz.wav audio_48kHz.wav

Anschließend würde ich mit Aften, ohne irgendwelche Filter, die Wandlung nach AC3 vornehmen.

aften –b 256 audio_48kHz.wav audio.ac3

256 kbps sollten vollkommen ausreichen. Eventuell ist es auch sinnvoll „Stereo rematrixing“ zu deaktivieren (-m 0). Musik hat in der Regel einen eher begrenzten Dynamikumfang, so dass eine Dynamikkompression nicht unbedingt nötig und sinnvoll ist. Wenn eine Reduzierung des Dynamikumfangs aber dennoch zum Zuge kommen soll, dann sollte man auch mit einem korrekt ermittelten Dialog-Normalisierungswert arbeiten. Der letztgenannte Wert ist für sich gesehen vielleicht noch sinnvoll, um die Lautstärke auf ein „übliches Niveau“ zu bringen.

Hier geht es doch nicht um die Wandlung von DVB-Streams, sondern um das Erzeugen von Dolby Digital im Allgemeinen. :motz: Damit lässt sich schon ein wenig mehr machen, als "nur" DD 2.0. Das geht sogar mit recht einfachen Mitteln.

Die Frage nach dem Sinn von DD 2.0 kann man natürlich stellen (das kann man aber immer). Grundsätzlich aber gibt es schon Gründe, warum DD 2.0 auch bei DV-Videos Sinn macht. Ob jetzt eine hörbar bessere Qualität herauskommt, sei jetzt mal dahingestellt. Ein wesentlicher Grund ist aber die gesteigerte Kompatibilität. Bei mir kommt es z. B. mitunter vor, dass ich meine selbstgefilmten Werke auch mal nach Übersee schicke.

Wenn man’s "richtig" machen will, dann muss man zuerst den Wert für die Dialog-Normalisierung (Dialog Normalization) ermitteln. Dazu muss in der betreffenden Audio-Datei ein Bereich ausfindig gemacht werden, wo nur gesprochen wird. Für diesen Bereich wird dann die durchschnittliche Lautstärke (Average RMS Power) ermittelt. Das erledigen Programme wie Adobe Audition (vormals Cool Edit Pro) oder Sound Forge, um nur ein paar zu nennen. Der so ermittelte Wert wird auf eine ganze Zahl gerundet und dem Encoder als Dialog-Normalisierungswert übergeben. In Aften entspricht dies dem Parameter "dnorm".

Anschließend wählt man den gewünschten Dynamikumfang aus (z. B. Film Standard). Voraussetzung, dass die Dynamikreduzierung auch auch zu vernünftigen Resultaten führt, ist ein korrekt ermittelter Dialog-Normalisierungswert! In Aften heißt der Parameter "dynrng".

Die Verwendung des Hochpassfilters (DC high-pass filter) und des Tiefpassfilters (Bandwidth low-pass filter) wird empfohlen. "RF Overmodulation Protection" sollte bei DVD-Authoring jedoch nicht aktiviert sein.

Es bleibt die Frage, inwieweit diese Optionen bei DV-Videos – darum geht es mir in erster Linie - überhaupt Sinn machen? Die Dialog-Normalisierung scheint mir ja noch recht sinnvoll zu sein. Aber benötigt man auch eine Dynamikkompression bzw. was bringt diese bei etwas "unsauberen" Quellen? Vielleicht eine etwas moderatere Einstellung, wie z. B. "Film Light", wählen? Einstürzende Hochhäuser, Explosionen, gepaart mit leisen Dialogen sind bei DV-Aufnahmen doch wohl nicht zu erwarten? Warum also für DV-Videos nicht einfach "aften –b 256 input.wav output.ac3" wählen?

Ich seh' schon, ohne zahlreiche Tests wird man da nicht weiter kommen. Ich werde mir mal ein repräsentatives einminütiges DV-Video mit den verschiedensten Enkodierungseinstellungen über eine gute Anlage anhören.

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.

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.

Das, was ich weiter oben als „Hörtest“ deklariert hatte, war eigentlich ein Witz, da ich, erstens, immer wusste, um welche Datei es sich handelt und, zweitens, war die AC3Enc-Datei stets leiser als die Aften-Datei. Selbst beim nachträglichen Korrigieren der Lautstärke (beim Anhören) hörte sich der AC3Enc-Ton „dumpfer“ an.

Ich habe mir deshalb in der Zwischenzeit auch die Mühe gemacht, und ein paar sog. Blindtests (mit besseren Lautsprechern) gemacht. Habe diesmal aber dafür Sorge getragen, dass die Stücke gleich laut waren. Erst damit war es mir möglich, vernünftige Aussagen zu treffen.

Bei 64, 96 und 128 kbps (manchmal auch bei 160 kbps) konnte ich Unterschiede zwischen AC3Enc und Aften heraushören. Hauptsächlich dadurch, weil AC3Enc bis 128 kbps an gewissen Stellen hörbare Verzerrungen produzierte (HeadAC3he übrigens auch). Bei 192 kbps war es mir nicht mehr möglich, Unterschiede zwischen den beiden Encodern festzustellen. Auch konnte ich bei dieser Bitrate bei drei gegebenen Dateien (Original, AC3Enc und Aften) das Original nicht heraushören.

Als Alternative bietet sich auch BeLight in Verbindung mit Aften an. BeLight vereint die beiden AC3-Encoder AC3Enc und Aften auf einer Oberfläche. Zudem kannst du damit auch 5.1-Ton erzeugen.

So was gibt es bereits.

http://forum.doom9.org/showthread.php?p=879846#post879846

Da lese ich gerade, du meinst ja eine DLL.

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.

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).

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).

Also die Variante mit deaktiviertem Autogop und der Einstellung „15-2“ sieht dann doch gefälliger aus. Als Durchschnittswert über alle Frames erhalte ich nun Q = 0,9425. Auch im BitRate Viewer ist die Quantisierungskurve etwas gemäßigter.

HC, „15-2“
[Blockierte Grafik: http://img245.imageshack.us/img245/8736/bitrateviewerhc1520640x0390ho2.jpg]

Hier noch mal die Grafiken, die den Verlauf der SSIM-Werte veranschaulichen. Diesmal allerdings mit der „15-2-Variante“ des HC-Clips.

SSIM-Kurve, Frame 150 bis 407, Wasserszene mit leichtem Schwenk
HC: 0,9214
 [Blockierte Grafik: http://img170.imageshack.us/img170/5272/ssimframehc1520150bis0407pu7.jpg]

SSIM-Kurve, Frame 408 bis 671, langsamer gefühlvoller Schwenk
HC: 0,9444
[Blockierte Grafik: http://img171.imageshack.us/img171/1259/ssimframehc1520408bis0671xk5.jpg]

SSIM-Kurve, Frame 672 bis 821, Nahaufnahme eines Tieres
HC: 0,9496
[Blockierte Grafik: http://img181.imageshack.us/img181/6231/ssimframehc1520672bis0821rz2.jpg]

SSIM-Kurve, Frame 1097 bis 1146, Wasserspringbrunnen
HC: 0,8835
[Blockierte Grafik: http://img169.imageshack.us/img169/9449/ssimframehc1521097bis1146sw0.jpg]

Die Aufsplittung des Framebereichs von 672 bis 821 ergibt diesmal:
Frame 672 bis 744: 0,9422
Frame 745 bis 821: 0,9566

Wenn man sich nun den Framebereich von 672 bis 821 als Video ansieht bzw. die Einzelbilder schnell nacheinander betrachtet, sind auch keine Verblockungen mehr sichtbar. "Auffällig" ist jetzt vielleicht nur noch die Wasserszene (Framebereich von 150 bis 407).

Noch ein kleiner Nachtrag. Ich habe auch noch einen Versuch mit der Einstellung „15-1“ gemacht. Für Q erhalte ich den Wert 0,9418. Da mir aber diese Zahl – aus den oben erwähnten Gründen – noch nicht viel sagt, habe ich mir also wieder die Verlaufskurve angesehen. Und siehe da, das Ergebnis ist wieder schlechter geworden ist. Auch im laufenden Video bzw. beim Betrachten der Einzelbilder sieht man wieder Verblockungen.

Hier noch mal der Framebereich von 672 bis 821 mit dem „15-1-Clip“ des HC-Encoders.

[Blockierte Grafik: http://img168.imageshack.us/img168/3432/ssimframehc1510672bis0821dw4.jpg]

Kopernikus:
Das sind dann die berühmten Bildvergleiche, wo in einem Bild ein Loch bzw. ein kleiner schwarzer Kreis abgebildet ist, rundherum ist das Bild aber völlig identisch.
Das Problem beim minimalen SSIM ist halt auch, wo tritt der auf und wie oft treten solche schlechten Werte überhaupt auf? In Randbereichen stört das weniger als in bildwichtigen Bereichen. Vielleicht so was wie eine Standardabweichung der SSIM-Werte innerhalb eines Frames einführen? Obwohl, wenn ich da an den soeben genannten schwarzen Kreis denke, eher nicht. Vielleicht dann doch eher den kleinsten SSIM-Wert ermitteln.

LigH:
Autogop könnte durchaus der Schlüssel sein. Bei Frame 672 geht es z. B. schon mal los mit 3 x IPPPPPPPPPPPPPP, gefolgt von IPPPPPPPPPPPPPPB und IBPBPBPBPBPBPB.

Ich deaktiviere mal Autogop und lasse den HC mit der Einstellung „15-2“ durchlaufen (bei sonst gleichen Einstellungen).

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?

Bis jetzt dachte ich eigentlich immer, der durchschnittliche SSIM-Wert (über einen gewissen Framebereich) wäre ein guter Anhaltspunkt für eine Beurteilung. Tja, wie man sich täuschen kann. Auch den Verlauf der SSIM-Kurve (über diesen Framebereich) gilt es zu berücksichtigen.

Wenn man z. B. den Framebereich von 672 bis 821 (siehe oben) nur anhand des ermittelten SSIM-Wertes begutachten würde, dann würde man (fälschlicherweise) zu der Erkenntnis gelangen, dass der HC da nicht viel schlechter als der CCE Basic ist. Beim normalen Betrachten des HC-Videos fallen die Ausreißer zu Beginn der Szene dann aber doch deutlich auf. Ab Frame 745 verbessert sich die Situation beim HC-Video dann wieder.

Hier noch mal eine Aufsplittung des untersuchten Framebereichs. Hier kann man an den Zahlen sehr gut erkennen, wie deutlich der HC im Framebereich von 672 bis 744 gegenüber den anderen Encodern abfällt.

Frame 672 bis 744:
- Cinema Craft Encoder Basic: 0,9416
- HC: 0,9274
- Canopus Procoder Express: 0,9543
- QuEnc: 0,9565

Frame 745 bis 821:
- Cinema Craft Encoder Basic: 0,9537
- HC: 0,9584
- Canopus Procoder Express: 0,9606
- QuEnc: 0,9622

Ich weiß jetzt natürlich nicht, inwieweit diese Aufstellungen überhaupt nützlich für Hank ist. Eventuell weiß er mittlerweile aber auch, woran es liegen könnte, da er mich diesbezüglich bereits kontaktiert hat.

Ich habe jetzt einen etwas repräsentativeren Clip hergenommen. Und zwar habe ich aus einem Film über einen Zoobesuch einen 60-Sekunden-Kurzfilm gemacht. Darin enthalten sind sowohl ruhige Szenen als auch Szenen mit viel Bewegung (Schwenk, Wasserszene, Wasserspringbrunnen etc.). Alle Encoder enkodierten in 2 Durchgängen bei einer mittleren Bitrate von 6500 kbps (bei möglichst optimalen Einstellungen). Die Dateigrößen waren weitestgehend identisch. Alle enthaltenen 1500 Frames wurden einer Analyse unterzogen.

Die durchschnittlichen SSIM-Werte über alle 1500 Frames ergaben sich dabei wie folgt.

Cinema Craft Encoder Basic
Q in Y: 0,9386

HC
Q in Y: 0,9414

Canopus Procoder Express
Q in Y: 0,9449

QuEnc
Q in Y: 0,9439

Die Ausgabe des BitRate Viewers brachte folgendes zu Tage.

Cinema Craft Encoder Basic
[Blockierte Grafik: http://img169.imageshack.us/img169/9839/bitrateviewerccebasic0640x0390fg3.jpg]

HC
[Blockierte Grafik: http://img244.imageshack.us/img244/32/bitrateviewerhc0640x0390qa1.jpg]

Canopus Procoder Express
[Blockierte Grafik: http://img208.imageshack.us/img208/7222/bitrateviewerprocoderexpress0640x0390zu9.jpg]

QuEnc
[Blockierte Grafik: http://img144.imageshack.us/img144/7878/bitrateviewerquenc0640x0390qs9.jpg]

Eine grafische Darstellung der SSIM-Kurve habe ich wegen der besseren Lesbarkeit für jede Szene einzeln gemacht. Ich erspare mir an dieser Stelle, alle Grafiken zu veröffentlichen. Die Grafiken, in denen der HC etwas „Auffälliges“ zeigte, sind hier zu sehen. Ich habe auch die durchschnittlichen SSIM-Werte für den jeweiligen Framebereich mit angefügt, so dass man sehen kann, wie sich ein Encoder hier schlägt. Die Werte sind aber mit Vorsicht zu genießen, da sie, erstens nur einen Ausschnitt repräsentieren und, zweitens, nicht jeder Encoder mit einem I-Frame bei einer neuen Szene beginnt etc. Die kleinen Bilder in den Grafiken zeigen immer den ersten Frame der jeweiligen Szene.

SSIM-Kurve, Frame 150 bis 407, Wasserszene mit leichtem Schwenk
- Cinema Craft Encoder Basic: 0,9226
- HC: 0,9217
- Canopus Procoder Express: 0,9354
- QuEnc: 0,9190
[Blockierte Grafik: http://img214.imageshack.us/img214/1830/ssimframe0150bis0407kc8.jpg]

SSIM-Kurve, Frame 408 bis 671, langsamer gefühlvoller Schwenk
- Cinema Craft Encoder Basic: 0,9398
- HC: 0,9434
- Canopus Procoder Express: 0,9438
- QuEnc: 0,9511
[Blockierte Grafik: http://img244.imageshack.us/img244/9026/ssimframe0408bis0671ms9.jpg]

SSIM-Kurve, Frame 672 bis 821, Nahaufnahme eines Tieres mit leichtem Schwenk
- Cinema Craft Encoder Basic: 0,9478
- HC: 0,9433
- Canopus Procoder Express: 0,9575
- QuEnc: 0,9594
[Blockierte Grafik: http://img167.imageshack.us/img167/7430/ssimframe0672bis0821od5.jpg]

SSIM-Kurve, Frame 1097 bis 1146, Wasserspringbrunnen
- Cinema Craft Encoder Basic: 0,8738
- HC: 0,8858
- Canopus Procoder Express: 0,8827
- QuEnc: 0,9095
[Blockierte Grafik: http://img80.imageshack.us/img80/1754/ssimframe1097bis1146cn1.jpg]