Guter DVD-Sound für Ihren Film selbst gemacht
	Teil 5 - MPEG-1 Audio Layer II

In der letzen Folge haben wir die Basis für unseren Ton kennen gelernt. In dieser und in den nächsten Folgen geht es um die Frage, ob wir MPEG-1 Audio Layer II oder Dolby Digital als Tonspur für unseren eigenen DV-Film einsetzen.

Zuerst beleuchten wir einmal MPEG-1:

Sie wissen, dass es - wie bei der Audio-CD - unkomprimierten Ton gibt, oder wie bei der DVD-Audio verlustfreie, reversible Kompressionsverfahren (vergleichbar mit Komprimierungen, wie sie beim ZIP-Format eingesetzt werden).

Dolby Digital - nachstehend nur noch AC3 genannt - und auch MPEG 1 Layer II nutzen aber Komprimierungen, die sich an der akustischen Wahrnehmung orientierten.

Da Sie als Zuhörer vermutlich sowieso keine hohen Frequenzen (über 16.000 Hz) mehr hören, ;-) braucht man diese auch nicht zu übertragen. So die Theorie.

Wir wollen uns in diesem Zusammenhang nicht mit den Details einer solchen Komprimierung beschäftigen. Man kann jedoch vereinfacht sagen, dass Sounddateien durch das Entfernen unhörbarer Informationen ober- und unterhalb der menschlichen Hörschwelle aus der entsprechenden Ausgangs-Datei heraus komprimiert werden. 

Auch hört man leise Töne nicht mehr, wenn etwas lautes diese "verdeckt". Das oft benutzte Beispiel ist eine leise Stimme vor einem Presslufthammer.

Diese Erkenntnis machen sich alle Komprimierungsverfahren mehr oder weniger stark zu nutze.

Man kann das ganz einfach selbst feststellen:

Wir nehmen wieder unseren bereits aus Folge I bekannten Gleitton mit einem Frequenzgang zwischen 20 und knapp 21 kHz mit einer umgerechneten Sampling-Frequenz von 48 kHz.

Abb 1: Darstellung eines Test-WAVs (C) by Stefan Uchrin

Diesen Ton schicken wir einfach durch TMPGEnc (Version 2.59.47.155) und zwar bei folgender Einstellung:
 

Den Sound encoden wir damit zu MPEG-1 Audio Layer II. Die Datenrate beschränke ich mal bewusst auf 64 kbps.

Schaut man sich das Ergebnis an

Abb 2: Darstellung eines Test-WAVs (C) by Stefan Uchrin

so kann man erkennen, dass der Frequenzverlauf bei 6.117 Hz abrupt abbricht. Die Wiedergabe erinnert entfernt etwas an eine Musikübertragung per Telefon.

Allerdings war mein Testfile auch nur rund 10 MB groß. Bei einer Datenrate von 384 kbps wuchs es hingegen auf 65 MB an.

Aber schon bei 112 kbps wurde fast der ganze Frequenzumfang meines Gleittons übertragen. Wobei hier allerdings auch bei 20.100 Hz Schluss war.

Zur genaueren Analyse werfen wir noch einen Blick auf die digital erzeugten Töne mit den Frequenzen 1, 18, 20 und 22 kHz zur Prüfung des Hochtonfrequenzgangs.

Aus den vorangegangenen Versuchen wissen wir ja noch, dass es sich um recht "reine" Töne handelt, die also im Frequenzverlauf als scharfe Spitze auftauchen (PrintScreen unten):

 
Nicht so unser 20 kHz-Ton nach der MPEG-1-Codierung mit 112 kbps:
 

Um den Ton herum sehen wir im obigen Bild noch jede Menge Müll. Frequenzen, die da nicht hingehören. Vermutlich werden viele User das nicht so deutlich hören, aber dem geschulten Ohr wird das nicht entgehen.

Erst bei 128 kbps wurde der Ton wieder brauchbar:

Hier schwingt noch was mit (gelber Pfeil), was da nicht hingehört, aber das ist im Prinzip erträglich. Übrigens konnte man die Datenrate weiter bis auf 384 kbps erhöhen, ohne dass sich an diesem Wandlungsfehler etwas änderte.

Da diese "Oberwelle" auch bei einer WAV-MPEG-Wandlung mit der MP2enc.dll aus BeSweet vorhanden war, habe ich zur Sicherheit auch noch direkt das Original, also CDex version 1.50 von Albert Faber zum Vergleich getestet:

Doch der 20 kHz-Ton in MPEG-1 Layer II war mit keinem der Programme zu verbessern.

Außerdem war bei den Testläufen zu sehen, dass keiner der beiden Kandidaten und auch keine der möglichen Einstellungen eine Frequenz größer 20 kHz durchließ. Allen Versuchen war gemeinsam, dass der vorhandene 22 kHz-Ton nicht berücksichtigt wurde.

Bis jetzt haben wir uns nur auf reine Sinustöne beschränkt. Doch Sprache oder Musik besteht nicht nur aus reinen Tönen mit einer einzigen Frequenz. Sie besteht aus einer Vielzahl von Frequenzen und so habe ich meinen Versuch etwas ausgeweitet. Und zwar auf die Einbeziehung eines möglichst großen Frequenzspektrums, denn nur damit ist es möglich, einen Encoder richtig zu beurteilen.

Einige von Ihnen haben sicher schon einmal etwas von 'weißem' oder von 'farbigem' Rauschen gehört.

Weißes Rauschen beinhaltet sämtliche hörbare Frequenzen mit zufälligen Amplitudenwerten. Dabei ist Weißes Rauschen spektral flach, d.h. die Energie in jedem beliebigen Ausschnitt aus dem hörbaren Frequenzbereich ist gleich.

Ein anderer Typ von Rauschen ist das Rosa Rauschen (engl. pink noise). Es enthält ebenfalls sämtliche hörbare Frequenzen, jedoch mit gleicher Energie pro Oktave. Dabei sind die tiefen Frequenzanteile im Spektrum stärker betont.

Damit klingt Weißes Rauschen etwas heller als Rosa Rauschen. Da mir kein Weißes Rauschen zur Verfügung stand, habe ich mich auf einen Versuch mit Rosa Rauschen beschränkt.

Beim "Einrauschen" eines Systems gibt man übrigens dieses Rosa Rauschen auf z.B. eine Beschallungsanlage. Wenn man Rosa Rauschen direkt in den Analyzer-Eingang gibt, zeigen alle Bänder den gleichen Pegel an. Sollten sie zumindest. ;-)

Für meinen Test habe ich zwei Rauschelemente hintereinander geschnitten. Es handelte sich dabei um korreliertes und unkorreliertes (links und rechts unabhängig voreinander) Rosa Rauschen. Auch diese Signale wurden auf eine Sampling-Frequenz von 48 kHz umgerechnet.

Wie Sie sehen, haben wir zu jedem Zeitpunkt alle Frequenzanteile bis hoch zu 22 kHz im Signal vorhanden.

Lassen Sie nun die folgenden Bilder einfach mal auf sich wirken:

Bei 64 kbps (erzeugt mittels TMPGEnc) ist alles oberhalb ca. 6.300 Hz abgeschnitten, wie wir im obigen Bild sehen. Wir hatten das oben ja schon mal angesprochen.

Bei meiner persönlichen Lieblingseinstellung für die SVCD von 192 kbps sah das so aus:

Die max. Frequenz lag da bei etwa 16 kHz.

Klavier, Violine und Violoncello hören sich dabei allerdings nicht so toll an. Doch auf einer SVCD war ja auch nicht unendlich Platz, so dass man einen Kompromiss zwischen Qualität einerseits und Spiellänge andererseits eingehen musste.

Etwas besseren Hörgenuss dürfte vermutlich erst der MPEG-Audio-Stream mit 224 kbps geben.

Hier fällt allerdings auf, dass TMPGEnc die beiden Kanäle beim korrelierten Signal etwas unterschiedlich zu bewerten scheint und er das Volumen generell bei etwa 15 kHz absenkt. Die max. encodierte Frequenz liegt jedoch bei ca. 18 kHz.

Richtig Spaß machte es erst ab 256 kbps:

Eine Steigerung auf 384 kbps brachte keine Ausweitung des Frequenzspektrums mehr mit sich.

Ein Bekannter sprach mich während meiner Testreihe an, ob ich nicht seinen "ultimativen Formatkonverter", den Canopus Procoder mit berücksichtigen könnte.

Nun ist die Software über den USB-Anschluss "gedongelt" und so habe ich meinen Test bei meinem Bekannten weitergeführt, um mir dort das von einigen Fachzeitungen hinsichtlich der Bildqualität hoch gelobte Programm auch mit Zielrichtung Sound einmal im Detail anzusehen.

Wir haben bei meinem Film folgende Soundeinstellung gemacht:

Basis war übrigens die Version 1.0.xx. Aktuell ist zwischenzeitlich die Version 1.2, da ich aber nicht erneut 200 km für einen EDV-TIPP-Test fahren wollte, müssen die Procoder-Anwender vermutlich selbst herausfinden, ob sich die Ton-Qualität verbessert oder verschlechtert hat.

Hier meine Messungen an der Version 1.0.xx:

Während die grüne Hüllkurve den TMPGEnc bei 256 kbps zeigt, stellt die lila Fläche den Frequenzverlauf des Procoder im rechten Kanal dar. Die im Hintergrund zu erahnende blaue Fläche zeigt den linken Kanal. Auch der Procoder arbeitet -wie oben von mir eingestellt- mit 256 kbps.

Da beide Verläufe fast identisch waren, habe ich zur Sicherheit den Test nochmals gemacht und mir auch andere Bereiche im Stream angesehen. TMPGEnc und Procoder sehen hier fast gleich in der Tonqualität aus. Man hat das Gefühl, sie nutzen exakt die gleichen Programm-Routinen.

Ich muss gestehen, ich hatte mir etwas mehr Bandbreite vom Procoder erhofft, denn der Preis von knapp 700,- US$ für den Procoder gegen 48,- US$ für TMPGEnc ist ja doch recht erheblich. Doch vermutlich ist der Unterschied mehr auf der Bildseite zu suchen.

 
Nun gut, wenn uns die gekauften Encoder nicht so richtig weiterhelfen wollen oder auch können, so werfen wir nochmals einen Blick auf den Freeware-Markt, bzw. auf die Programme unter GNU-Lizenz.

Durch das Internet geistert bei Fragen um den "guten Ton" immer wieder das Programm LAME von Mike Cheng bzw. Mark Taylor, was soviel wie "LAME Ain't an Mp3 Encoder" bedeutet. Ain't" ist, für alle die nicht so fitt in der englischen Sprache sind, ein Ausdruck für "is not". LAME ist also kein MP3-Encoder.

Nun wird LAME zwar unter der GNU-Lizenz angeboten, doch muss man dazu wissen, dass das Frauenhofer Institut spezielle Patente auf das Encoden von MP3 besitzt. Und solche Patente kosten Geld, wenn man sie nutzen will!

Lame basiert allerdings auf einem Patch des "dist10 source code" und umgeht damit offensichtlich das Hauptpatent zu MP3.

Was ist denn nun schon wieder "dist10"?

Es gibt für MP3 so etwas wie eine frei zugängliche ISO-Referenzimplementation (120,- US$), die unter dem Namen "dist10" bekannt ist. Diese Quellcodes kann man sich quasi im Internet herunterladen und daraus einen eigenen MP3-Encoder stricken.

Nun ist dieser Source-Code nicht nur recht fehlerhaft und unvollständig, sondern auch offensichtlich sehr langsam in der Anwendung.

Mike Cheng hat nun einen Patch geschrieben, um aus dem "dist10" eine gescheite Applikation zu machen. Der "Patch" ist allerdings in eigenständiger Form überhaupt nicht in der Lage MPEG Layer III - Files zu produzieren. Er ist ohne "dist10" nicht ausführbar und auch nicht kompilierbar. Man benötigt, um einen funktionsfähigen MPEG-Encoder zu bauen, immer den ISO-Source-Code.

Mike Cheng umging damit geschickt die Patentfrage. Denn dieser Patch als "Vertriebsmodell" setzt voraus, dass der Programmierer, der den eigentlichen Encoder kompiliert, erst "dist10" patchen (also "flicken" oder verändern) muss, um den Quellcode für den Encoder zu erhalten.

Das was Freaks wie z.B. "Dibrom" oder "Mitiok" durch kompilieren der so entstandenen Quellen daraus machen, gehört meiner Meinung nach weltweit zu den besten MP3-Encodern - besonders was Geschwindigkeit und Stabilität angeht.

Mir persönlich ist unklar, ob Sie mit der privaten Nutzung des LAME-Encoders evtl. gegen das gültige Patentrecht verstoßen. Meiner Information nach sind hierzulande solche Algorithmen nicht patentierbar, so dass das Fraunhofer-Institut vermutlich nicht viel in der Hand hat. Aber ich mag mich täuschen.

Zumindest hat man in den vergangenen Jahren zahlreiche Briefe an die Betreiber von Webservern verschickt, mit dem Ziel, die Downloadmöglichkeit für auf diesem Weg entstandene Encoder zu unterbinden.

Vergleichen Sie zur weiteren Information http://www.mp3-tech.org/ sowie http://www.mp3licensing.com/.
 

Nun werden Sie zu recht sagen, was sollen wir mit MP3 auf unserer DVD?

MP3 steht ja für Layer III und wir beschäftigen uns bei der Herstellung der DVD mit MPEG-1 Audio Layer II.

Richtig, doch es gibt auch einen LAME für MPEG 1 Audio Layer II, den TooLAME. Die entsprechende Projektseite finden Sie unter http://sourceforge.net/projects/toolame. Und da kümmert uns das MP3-Patent vermutlich noch etwas weniger.

Die letzte Version ist TooLAME 0.2i - auch wieder von Mike Cheng. Wo Sie im Internet diese oder eine neuere EXE-Version von TooLAME finden, sagt Ihnen sicher Google.

Auch TooLAME ist ebenfalls ein Kommandozeilenprogramm, das eine etwas kryptische Eingabe erfordert.

Wenn Sie die Befehle des Programms kennen lernen wollen, so tippen Sie einfach mal von der DOS-Oberfläche

• toolame --help > help.txt

ein. Der Hilfetext wird dann in die Datei "help.txt" kopiert, wo sie ihn in Ruhe ansehen können.

Um ein WAV mittels TooLAME in ein MP2-File zu wandeln, gebe ich z.B. folgenden Syntax ein:

• tooLAME.exe" -s 48 -m s -b 256 "input.wav" "output.mp2"

Für die Leute, die es damit nicht so haben und lieber mit der Maus arbeiten, kann ich eine sehr schöne grafische Benutzeroberfläche empfehlen und zwar das BeSweet GUI von Danni Din:

Das Programm ist u.a. auf der BeSweet-Seite http://dspguru.doom9.org zu finden. Wir werden es in der kommenden Folge nochmals für BeSweet direkt nutzen.

Über den Button "2Lame" bekommen Sie etwa folgendes Bild:

Ausschnitt aus BeSweet GUI - "Total Bitrate" muss 256 nicht 258 heißen

Sie können TooLAME aber auch direkt in TMPGEnc als externe "Audio engine" einbinden.

Das BeSweet-GUI hat da allerdings ein paar mehr Einstellmöglichkeiten als TMPGEnc, so dass ich hier lieber mit dem GUI arbeite als mit TMPGEnc. Nachteil: Sie müssen die getrennt entstandenen Files (Video in TMPEG und Audio via TooLAME) nachher wieder zusammenmuxen.

Schauen wir uns nun einmal die Qualität des Tons bei einer Datenrate von 256 kbps an:

Zuerst die Reinheit unserer Töne bei 1, 18 und 20 kHz:

Die Unsauberkeit (gelber Pfeil) bei 20 kHz haben wir ja auch schon bei den anderen Programmen weiter oben gesehen.

Interessant wurde es aber bei der Bandbreite:

Während die lila Fläche TMPGEnc darstellt, zeigt die grüne Kurve den Frequenzverlauf von TooLAME.

Beim TMPGEnc war bei knapp 20 kHz Schluss und TooLAME legte noch 500 Hz oben drauf. Und auch der im rechten Kanal vorhandene Frequenzeinbruch an einer bestimmten Stelle im Stream bei TMPEG wird von TooLAME an der gleichen Stelle ganz souverän gemeistert.

Für die experimentierfreudigen User dürfte die variable Bitrate (VBR) von TooLAME noch von Interesse sein. Bei der Grundeinstellung des o.a. GUI konnte ich unter Beibehaltung der Bandbreite beim Rosa Rauschen etwa 14% an Filegröße einsparen.

Lediglich bei den hohen Frequenzen (und nur in der Musikdarbietung zu erkennen) fehlte bei der VBR-Einstellung plötzlich etwas die Musikinformation bei einem Kanal (hier ab etwa 13 kHz am blauen Kurvenverlauf zu erkennen):

 
Gegenüberstellung CBR/VBR bei TooLAME
(C) by S.Uchrin

Vermutlich liegt das hohe "Einsparpotential" bei meinem Teststream auch in dem besonders großen Anteil von hohen Frequenzen, denn im niederfrequenten Bereich konnte ich nicht so viel "Reduktion" erkennen. Aber ACHTUNG die VBR ist als experimentell bezeichnet und so brauchen Sie sich aber Artefakte und Fehler nicht wundern. Und ob sich das nachher auf DVD wirklich abspielen lässt, ist mehr als umstritten.

Wer aber losgelöst von allen Patentfragen mit TooLAME und einer CBR arbeiten will, ist sicher damit ganz ausgezeichnet bedient.

Empfehlung für MPEG-1 Audio Layer II

Abweichend von meinen Tipps für die SVCD mit 192 kbps und 224 kbps empfehle ich für die DVD, da wir ja da etwas mehr Platz haben, aus Gründen der Qualität beim TMPGEnc, aber auch für andere Encoder (mit MPEG-1 Audio Layer II) 256 kbps als Datenrate für einen guten Sound mit möglichst vielen Frequenzanteilen.

Klänge werden dadurch harmonischer und wie man sagt "wärmer" klingen.

Und wenn Sie schon unbedingt MPEG-1 nutzen wollen, so sollten Sie über TooLAME nachdenken.

Die hier empfohlene Datenrate deckt sich übrigens auch mit der für Digital Broadcast Audio (DBA) genutzt Rate. Auch hier ist eine Datenrate von 256 kbps Standard.

----

Nachtrag vom 22.12.04

Wem der BeSweet GUI von Danni Din etwas zu umständlich erscheint, dem sei BeLight, aktuell in der Version 0.20 Final, von "Kurtnoise" empfohlen.