Daher taugen traditionelle Bewertungskriterien wie der Rauschabstand und der Frequenzgang nicht mehr. Eine subjektive Bewertung durch ein geschultes Ohr ist der einzige gangbare Weg.
MPEG Audio kann man entweder für die Archivierung oder die Ausstrahlung über eine nach oben beschränkte Bandbreite benutzen. Bei der Ausstrahlung reserviert man üblicherweise eine bestimmte Bandbreite, die man dann nicht überschreiten darf, weil es sonst zu Aussetzern kommt. Es ist daher eine wichtige Frage, ob ein Encoder direkt ausstrahlen kann oder ob ein Interface zur Verfügung steht, mit dem man das selber implementieren kann. Traditionelle Consumer-Encoder werden gewöhnlich nur in Dateien ausgeben können.
Bei der Archivierung ist es nicht wichtig, daß man eine bestimmte Bandbreite nicht überschreitet. Außerdem möchte man gewöhnlich an wenig dynamischen Stellen das Signal auch möglichst kompakt ablegen. Dafür gibt es im MPEG-Standard die variable Bitrate (VBR). MPEG zerlegt das Eingangssignal grundsätzlich in kurze Abschnitte, Frames genannt. Normalerweise haben alle Frames die gleiche Bitrate, aber man kann die Bitrate auch der Komplexität des Signals anpassen. Das Ergebnis nennt sich VBR und ist ein wichtiges Qualitätsmerkmal besonders für den Hobbyisten, der seine CD-Sammlung auf ein paar DatenCDs reduzieren möchte.
Es kommt oft vor, daß man die MPEG-Ströme, die man ausstrahlt, auch archivieren möchte. In diesem Fall muß man die maximale Bitrate beschränken können, aber in sehr ruhigen Passagen soll die Bitrate nicht immer voll ausgenutzt werden, damit man bei der Archivierung Platz spart. Daher ist es wünschenswert, bei VBR-Encodern die maximale Bitrate einstellen zu können.
Bei der heutigen Encoder- und Hardwaregeneration stellt sich die Echtzeitfrage nicht mehr, weil praktisch alle Encoder auf heutiger Hardware in der Lage sind, ein Signal in Echtzeit oder schneller zu encoden. Für die Archivierung des CD-Turms spielt natürlich der Zeitfaktor eine entscheidende Rolle, d.h. wie viel Zeit braucht die Archivierung im Vergleich zum bloßen Abspielen. Hierbei spielt auch die Geschwindigkeit des CD-ROM-Laufwerkes eine tragende Rolle, daher sollte man diesen Faktor auch nicht überbewerten. Man kann zwar das Audio-Grabben und das Encoden einer anderen Datei parallel durchführen, aber praktisch wird dadurch beides deutlich langsamer.
Da man für unter DM 1000 ein Mainboard mit zwei Celerons kaufen kann, ist SMP inzwischen relativ weit verbreitet. Natürlich kann man unter einem Multitasking-Betriebssystem mit SMP-Unterstützung einfach zwei Dateien parallel encoden, aber das MP3-Encoden von Audio an sich ist auch parallelisierbar. Ein weiteres gewünschtes Feature ist also, ob ein Encoder SMP ausnutzen kann.
Außerdem ist es natürlich wichtig, ob die Software frei ist und ob es den Quellcode gibt. Wenn man sich eine Stereoanlagen-Komponente mit einem ARM-Evaluation-Board bauen möchte, dann hilft einem eine Intel-Windows-DLL natürlich nicht weiter. Der eine oder andere hat vielleicht auf dem Flohmarkt einen älteren Alpha-Rechner gekauft, der zwar nach heutigen Standards nicht gerade schnell ist, aber für DM 100 kriegt man Hardware, die durchaus MPEG in Echtzeit encoden kann -- wenn man den Quellcode zum Encoder hat.
Eine sehr wichtige Frage ist, ob ein Encoder einen DWIM-Modus (DWIN = "do what I mean") hat, d.h. ein Satz Parameter, der bei praktisch allen Musikdateien zufriedenstellende MPEG-Dateien ergibt, die auch die Platzverschwendung minimieren. Hiermit ist gemeint, ob der Anwender vor der Benutzung erstmal einen Monat mit Herumprobieren, Tweaking und Tuning verbringen muß, bevor er die optimalen Parameter herausgefunden hat.
Neben diesen objektiv entscheidbaren Merkmalen gibt es natürlich noch die Frage, ob der Encoder denn Dateien auch gut encoded, d.h. wie weit man die Bitrate senken kann, ohne daß man Fehler in Form von Rauschen oder Verzerrungen hören kann. Diese Frage ist nur subjektiv zu klären, und letztendlich hängt sie auch von dem Equipment des Hörers ab. Bei einer schlechten Soundkarte mit passiv mit Strom versorgten "Brüllwürfeln" als Klanggeber kommt natürlich nur eine relativ kleine Teilmenge des Signals beim Ohr an, d.h. wenn man Glück hat, werden die MPEG-Artefakte von den Einstrahlungen des ungeschirmten Audiokabels und dem Hintergrundrauschen des Ventilators und der Festplatten komplett maskiert. Außerdem hört man bei Soundkarten oft das Anfahren des CD-ROM-Motors als Einstrahlung. Bei einem Setup mit einem Verstärker und Boxen kommen gewöhnlich Höhen deutlich weniger hörbar beim Anwender an als wenn man einen guten Kopfhörer direkt an den Ausgang der Soundkarte anschließt. Die Hörtests hier sind mit einem Ensoniq 1371 Chip und einem High-End Sony-Kopfhörer durchgeführt worden. Aber auch wenn das Equipment perfekt ist, entscheidet auch das Training der Ohren. Auch der Autor fragt sich beim Hören von alten MPEGs oft, wie er die Artefakte (Codierungsfehler) damals beim Encoden nicht hören konnte, da er sie heute unerträglich findet.
Warum gibt es kein Tool, das die Encoder-Qualität mißt? Um die Qualität zu messen, müßte das Tool ein psychoakustisches Modell anwenden, um die Störgeräusche von absichtlich eingefügtem Quantisierungsrauschen zu trennen. Dieses psychoakustische Modell müßte akkurater sein als alle anderen psychoakustischen Modelle, wenn man es für Qualitätsmessungen benutzen will. Wenn man so ein Modell hätte, würde man damit kein Meßtool schreiben, sondern einen Encoder. Das hindert natürlich niemanden daran, so ein Tool zu schrieben, wenn man damit Geld verdienen kann. Fraunhofer hat also so ein Tool geschrieben. Wenn jetzt aber jemand ein besseres psychoakustisches Modell entwickelt, würde das Test-Tool das neue Modell als schlecht testen. Damit ist so etwas nur als Marketing-Gag zu bewerten.
Um die Codierungsqualität eines Encoders zu testen, muß man Signale encoden, die besonders schwer zu encoden sind. Es empfielt sich also, das Verfahren verstanden zu haben (siehe Grundlagenartikel in diesem Heft). Bei MPEG Layer 3 Audiokompression wird neben den relativ kurzen Frames im psychoakustischen Modell auch ein Kontext betrachtet, der deutlich länger als ein Frame ist (Größenordnung: eine Sekunde). Ein besonders gut hörbarer Fehler ist das Pre-Echo, das entsteht, wenn ein Signal sich innerhalb dieses Kontextes stark ändert, z.B. weil es bei 50 Hertz beginnt und dann schnell auf 10 Kilohertz hochspringt. Den gleichen Effekt erzielt man, wenn ein Signal intermittierend ist, z.B. bei den diversen Percussion-Instrumenten. Als besonders kritisch haben sich Kastagnetten herausgestellt.
Generell basiert MPEG Audiokompression darauf, daß das Signal in Bänder unterteilt wird, und in den für das Ohr unwichtigeren Bändern Quantisierungsrauschen eingefügt wird. Dieses Verfahren funktioniert perfekt bei einem Eingangssignal, das z.B. aus einer Sinuswelle besteht. Daher sind Encodertests, die eine Sinuswelle benutzen, nicht sinnvoll. Jeder noch so schlechte Encoder erkennt sofort, daß nur in einem Band Daten anliegen und benutzt seine komplette Bandbreite für dieses Band.
Wenn man auf allen Bändern ein Signal anlegt, bemerkt man die Qualität eines Encoder sehr gut, allerdings darf das Signal kein Rauschen sein. Der Encoder würde nämlich bei mit wenig Bits abgelegten Bändern Quantisierungsrauschen einfügen, das von dem vorigen Rauschen nur schwierig zu unterscheiden ist. Im Übrigen will man ja auch Musik oder Sprache encoden, nicht Rauschen. Es gibt allerdings eine Art von Rauschen, die genügend Struktur hat, um sie mit dem bloßen Ohr von Quantisierungsrauschen zu unterscheiden, nämlich Applaus bei Liveaufnahmen. Bei Applaus kann man das Pre-Echo (eher niederfrequent im Vergleich zum Applausrauschen) auch relativ gut hören.
Es ist ganz interessant zu sehen, wie das Ohr auf Rauschen reagiert. Das Ohr kann Rauschen sehr gut wegfiltern, d.h. es ist beim Hören der Sprache und der Musik praktisch nicht im Wege, aber man merkt sofort, wenn das Rauschen dann verschwindet. Dieser Effekt ist so stark, daß man bei Mobiltelefonen künstlich im Telefon Rauschen erzeugt, wenn keine Daten übertragen werden, damit es so klingt, als wäre eine Verbindung da. Der GSM-Standard bezeichnet dieses Rauschen als comfort noise. Wir haben für das Testen der Encoder also diverse Liveaufnahmen mit Applaus gewählt und mit verschiedenen Bitraten encoded. Wir haben neben Musik auch Sprachaufnahmen gewählt, die wir in Mono mit viel geringerer Bitrate encoded haben. Die Tests haben wir auf einem Pentium II mit 266 MHz unter Linux 2.2.14 bzw. Windows 98 durchgeführt.
Der Markt der Encoder ist relativ groß, aber es gibt nur wenige tatsächlich verschiedene Engines, auf denen die ganzen Programme letztendlich basieren. Die verbreitetsten Engines kommen von Fraunhofer und Xing, aber besonders die Free- und Shareware-Encoder basieren oft auch auf der ISO-Referenzimplementation. Ansonsten behauptet nur noch QDEsign, einen eigenen Codec geschrieben zu haben, und es gibt LAME, einen freien MP3-Encoder mit einer eigenen Engine.
Wir haben stellvertretend für die anderen Programme, die einen Xing und Fraunhofer Codec benutzen, den Musicmatch-Encoder gewählt, den es einmal mit Xing und einmal mit Fraunhofer Codec gibt. Den Xing Encoder gibt es auch für Intel-Linux als Binary, vom Fraunhofer-Codec gibt es leider nur eine relativ alte und langsame Version 3.1 für Intel-Linux als Binary. Stellvertretend für die ISO-Codecs haben wir BladeEnc unter die Lupe genommen, und neben LAME haben wir noch gogo getestet, der eine in Intel-Assembler aufgebohrte Version von LAME darstellt.
| Fraunhofer | ISO | LAME/gogo | ||
|---|---|---|---|---|
| Version im Test | Musicmatch 4 | Musicmatch 4/Linux V1.5 | BladeEnc 0.91 | LAME 0.6/gogo 2.23 |
| Joint Stereo? | ja | ja | nein | ja |
| Variable Bitrate? | ja | ja | nein | ja |
| Life encoden und ausstrahlen? | modul | modul | nein | ja |
| VBR-Bitrate beschränkbar? | n/a | nein | n/a | ja |
| Sourcecode frei? | nein | nein | ja | ja |
| Nutzt SMP? | nein | nein | nein | nein/ja |
| DWIM-Mode | VBR | VBR | 192+ kbps | VBR |
| Performance: 128 kbps | 4.2 | 4.8/2.97 | 0.73 | 1.84/2.4 |
| Performance: VBR | 4.2 | 4.8/3.07 | n/a | 0.68/1.28 |
Wenn man sich die MPEGs unter einem Frame-Analyser anschaut, stellt man bei Fraunhofer fest, daß ihr Codec auch Problemfälle behandeln kann, die mit den dokumentierten Methoden (ISO-Referenzcode und diverse Papers) nicht erreichbar sind. Diesen Vorsprung nutzt Fraunhofer, um mit Firmen zusammen Geschäfte zu machen. So ging erst vor kurzem eine Zusammenarbeit mit Texas Instruments durch die Presse. Der letzte käuflich erwerbbare Fraunhofer-Encoder von Opticom ist aus dem Jahre 1998 und beherrscht keine variablen Bitraten, aber inzwischen gibt es für Nero und Musicmatch Fraunhofer-Encoder-Plugins mit VBR. Das Plugin samt Nero kostet übrigens knapp DM 60, während der Opticom-Encoder $ 49 kostet (ohne VBR und nicht mit allen Bitraten freigeschaltet). Opticom wird also offenbar von Fraunhofer nicht bevorzugt behandelt...
Es gibt keine offene Möglichkeit, als Privatuser einen programmierbaren Fraunhofer-Codec zu bekommen, und die kaufbaren Encoder können nicht Live encoden und ins Netz multicasten. Die Einstellungen sind ein bißchen mager bei den auf Fraunhofer basierenden Codecs. So kann man bei VBR die Bitrate nicht beschränken, man kann nur ein Prozentschieber für die Qualität hin- und herschieben. Für Nicht-Intel-Windows-Plattformen sieht es für Privatanwender schwarz aus in Sachen Fraunhofer-Encoder, an Source-Code gar nicht zu denken.
Wenn einen diese Einschränkungen nicht stören, ist man mit dem Fraunhofer-Codec sicher hervorragend bedient. Die Qualität ist legendär, es gibt ja jetzt auch VBR, die Geschwindigkeit hat gewaltig zugenommen und ist von Xing kaum zu unterscheiden. Nur am fehlenden VBR-Tag in den MP3-Dateien und an einem Hexdump der Encoder-Module ist der Unterschied erkennbar.
Der Xing-Encoder war anfangs unter Profis verrufen, weil die MP3s deutliche Artefakte hatten. Außerdem hat der Encoder bei 16 kHz abgeschnitten, was gewöhnlich nicht hörbar sein sollte, aber sich wie ein Lauffeuer durch das Internet kolportierte, und fortan galt der Xing-Encoder als qualitativ schlecht. Xing hat das ausgebügelt, hat aber auch den Geschwindigkeitsvorsprung inzwischen verloren. Den Xing-Encoder kann man für verschiedene Plattformen kaufen, einen Encoder gibt es gleich bei Xing im Web für eine handvoll Dollar zu bestellen. Insgesamt hat man ein bißchen das Gefühl, daß ohne Xing die Fraunhofer Innovationen nie beim Endkunden angekommen wären.
Vor allem auf dem Mac erfreuen sich Xing-basierte Encoder großer Beliebtheit. Xing hat aber auch für Linux eine Version des Encoders im Angebot, die allerdings deutlich langsamer ist als die Windows-Version.
Der prominenteste Vertreter der ISO-Encoder ist bladeenc, für den es inzwischen auch den Quellcode frei im Netz gibt. Von Fraunhofer gab es zwar frühe Implementationen ihres MP3-Encoders, der damals noch l3enc hieß, aber bei dem war an Echtzeit-Encoden noch nicht zu denken. Daher sind viele Unix-Leute auf bladeenc umgestiegen und benutzen es noch heute. Auf den Webseiten von bladeenc schreibt der Autor, dass die Qualität besser sei als die von Fraunhofer, wenn man die Bitrate sehr hoch setzt. Dabei übersieht er, daß man für hohe Bitraten auch MPEG Layer 2 benutzen kann, wobei der Encoder viel weniger komplex ist und weniger Latenz erzeugt. Man muß konstatieren, daß die ISO-Sourcen und die daraus resultierenden Encoder stark benachteiligt sind, weil sie kein VBR und kein Joint Stereo können. Besonders letzteres ist für Bitraten bis 128 kbps aber unerläßlich.
Konkret hat Fraunhofer den kompletten Prozeß patentiert, mit dem man aus Audio-Samples eine MPEG Layer 3 Audiokompression vornimmt. Das Patent bezieht sich explizit darauf, daß man alle Schritte nacheinander macht. Wenn man also einen Encoder schriebe, der die Huffman-Kompression am Ende nicht durchführen würde, und ein Programm veröffentlichen würde, das die Huffman-Kompression nachträglich durchführt, wäre man von dem Patent nicht betroffen. In Deutschland ist ein Algorithmus nicht patentierbar, so daß Fraunhofer hierzulande nicht viel in der Hand hat. Trotzdem hat Fraunhofer 1998 einige Dutzend Briefe an Betreiber von Webservern verschickt, die mp3-Encoder zum Download angeboten haben. In dem Brief stand, daß sich der Betreiber strafbar mache, wenn er das nicht sofort unterbinden würde, und so sind damals fast alle Freeware-Encoderprojekte gestorben. Auch der Autor von Bladeenc hat damals einen Brief bekommen, hat den aber seinem Anwalt gezeigt, und der hat ihm gesagt, daß er nicht betroffen sei, und so gibt es Bladeenc heute noch. Bladeenc kommt aus Norwegen, wo die Gesetzeslage sehr ähnlich der in Deutschland ist.
Zurück zu lame: lame kommt mit einem grafischen Frame-Analyser. Von lame gibt es auch betas im Netz, bei denen sich teilweise drastische Änderungen ergeben. lame ist der schnellste portable MP3-Encoder, der im Quellcode vorliegt. Man kann umfangreiche Optionen einstellen, die Bitraten limitieren, man kann sogar mp3-Dateien als Quelle nehmen (wenn man eine andere Bitrate haben möchte). Da der Quellcode vorhanden ist, kann man lame auch relativ einfach erweitern. Für den jährlichen Kongress des Chaos Computer Club sollte ein Live-Multicast der drei parallelen Vorträge im LAN in den Hackcentern stattfinden, und es war eine Sache von einer Stunde, einen multicast-RTP-Sender in lame einzubauen, der inzwischen auch Teil der regulären lame-Betas geworden ist.
Der VBR-Modus unterliegt bei lame kürzlich größeren Schwankungen. Neuerdings scheint er durch eine auf Ausprobieren basierende Strategie implementiert zu sein, jedenfalls ist VBR-Encoden im Moment um den Faktor 3 langsamer als Encoden mit fester Bitrate. Aber wer eine nicht-Mainstream-Plattform einsetzt oder aus anderen Gründen den Quellcode braucht, für den ist lame die einzige Wahl.
Als besonderen Clou bietet gogo als einziger Encoder SMP-Support an. Das funktioniert bei fester Bitrate praktisch perfekt: die Encode-Zeit halbiert sich. Bei VBR allerdings ist der lame-Ansatz nicht so gut parallelisierbar, so daß der Geschwindigkeitszuwachs einer zweiten CPU "nur" bei 50-70% liegt.
Interessant ist an dieser Stelle die Reaktion des Ohres. Eigentlich ist Applaus Rauschen, aus dem man ab und zu ein einzelnes Klatschen heraushören kann. Das Gehirn hält Applaus und einen laufenden Wasserhahn anhand dieser einzelnen Klatscher auseinander. MPEG Audio zerlegt das Signal in Bänder und ordnet den Bändern Bandbreite zu, d.h. für alle beteiligten Bänder bleibt nur wenig Bandbreite übrig. MPEG benachteiligt Höhen überproportional, weil das Ohr auf Höhen nicht so empfindlich reagiert. Bei Applaus sind viele Bänder komplett mit Rauschen gefüllt, aber die einzelnen Klatscher treten als Höhen hervor. Der Encoder hat an der Stelle sowieso wenig Bandbreite übrig, und weil es Höhen sind, werden sie noch zusätzlich benachteiligt. Daher ist Applaus ein guter Test für MPEG Audiokompression. Ein einzelner Klatscher hat wegen Joint Stereo außerdem mehr Überlebenschancen, wenn er mittig ist, als wenn er nur auf einem Kanal zu hören ist.
Das Ohr reagiert (wie auch die anderen Sinnesorgane) besonders auf Änderungen. Wenn in einem Band die ganze Zeit über verwaschener Applaus läuft, fällt dem Ohr das nicht auf. Wenn der Encoder aber besonders gut ist und die Bitverteilung über die Bänder dynamisch regelt, dann fällt das auf. Wenn der Encoder also einen Teil des Spektrums die ganze Zeit über ignoriert, fällt das nicht so auf, als wenn der Bereich die ganze Zeit über relativ gut klingt, bis dann plötzlich jemand rechts laut klatscht, woraufhin sich die Belegung so ändert, daß man die Verwaschung links bemerkt.
Bei den einzelnen Klatschern ergibt sich auch noch das gefürchtete Pre-Echo, was ein bißchen wie ein Weichspüler klingt. Für sich genommen ist der Effekt nicht schlimm, aber über dem Rauschen hört man es doch.
Eines der Testsamples war daher Track 3 der Herbert Grönemeyer Live CD, welches mit Applaus und Johlen der Fans anfängt, dann kommen ein paar Instrumente und schließlich verhältnismäßig lauter Gesang. Um die Artefakte zu erzwingen, haben wir die Bitrate auf 96 kbps gesetzt und alle Encoder auf die Datei angesetzt.
Konfrontiert mit diesen "schwierigen" Audiodaten erzeugt bladeenc sogar bei 128 kbps deutlich hörbare Fehler neben obigen Effekten, die auf Bugs im psychoakustischen Modell zurückzuführen sind. Außerdem kann man sowohl das Pre-Echo ausmachen als auch das Verwaschen hören. Das Ergebnis ist nicht zufriedenstellend.
Beim Fraunhofer-Encoder ist das Verwaschen relativ deutlich zu hören, dafür aber praktisch kein Pre-Echo. Der Fraunhofer-Encoder benachteiligt Höhen noch stärker als die anderen Encoder, was sich wie ein Verlust an Klangtiefe anhört. Außerdem kann man einen Verlust an Raumklang ausmachen. Offenbar kürzt Fraunhofer den zweiten Kanal bei Joint Stereo übermäßig. Das Ergebnis klingt dem Original noch sehr nahe, und man braucht eine Weile, bis man einen Finger darauf legen kann, was einen stört.
Der Xing-Encoder rundet die Klatscher ziemlich weg, so daß sie sich bei genauerem Hinhören nicht wie Klatscher anhören. Dieser Effekt ist deutlicher als bei Fraunhofer, und auch das Pre-Echo bei den nicht so lauten Klatschern ist deutlich zu hören. Xing kürzt auch die Höhen hörbar weg. Auch hier klingt das Ergebnis dem Original nahe genug, daß der Unterschied nur geschulten Ohren auffällt.
lame hinterläßt ein hörbares Zischeln bei den Höhen. Dieser Effekt ist ziemlich deutlich hörbar. lame verwendet bei 96 kbps normalerweise 32 kHz als Samplerate (und resampled die Eingabe automatisch entsprechend), was das Zischeln deutlich geringer ausfallen läßt als die 44.1 kHz, die alle anderen Encoder benutzen. Die Artefakte sind ungefähr in der Größenordnung des Fraunhofer-Encoders.
Zusammenfassend für die Kategorie Konstante Bitrate bei 96 kbps kann man sagen, daß sich Fraunhofer und lame nicht viel nehmen, während Xing qualitativ leicht abfällt. Bladeenc ist mangels Joint Stereo nicht konkurrenzfähig.
Die nächst höhere Bitrate ist 112 kbps. Hier sieht das Bild ähnlich aus wie bei 96 kbps: Fraunhofer und lame haben winzige Artefakte, Xing fällt leicht ab.
Nachdem wir mit diesem Beispiel Artefakte geradezu erzwungen haben, stellt sich die Frage, wie die VBR-Routinen der Encoder funktionieren. Auch das Grönemeyer-Stück ist ja nur am Anfang und am Ende kurz mit Applaus versehen, d.h. hier sollten VBR-Routinen großzügig Platz allozieren. Gleichzeitig sollte die Dateilänge insgesamt minimiert werden.
Der Xing-Encoder hat mit 50 von 150 als VBR-Setting unter Linux eine gleich große und gut klingende Datei erstellt wie lame mit -V 6. Das Ergebnis des Fraunhofer-Encoders hingegen hat bei gleicher Dateigröße noch deutliche Artefakte am Anfang. gogo benutzt eine ältere Version der lame-Engine, aber -v 2 erzeugt eine kleinere Dateigröße mit äquivalenten Ergebnisse.
In der Kategorie Variable Bitrate kann man sagen, daß sich die Plätze umgekehrt haben. lame und Xing nehmen sich nicht so viel, während Fraunhofer deutlich abfällt. Die VBR-Routinen müssen sich die Fraunhofer-Programmierer offenbar nochmal anschauen.
Ein ganz anderes Problem ist das Encoden von Sprache bei sehr niedrigen Bitraten wie 32 kbps. Bei so einer kleinen Bitrate geht bei BladeEnc und dem Xing-Encoder das Signal in einer Welle von Clicks, Pops und Piepser unter. Bei lame ist das Signal in überraschend guter Qualität zu hören und hat neben einem leicht metallischen Klang an einigen Stellen keine Artefakte. An dieser Stelle überzeugt der Fraunhofer-Encoder durch absolut saubere Kompression, nicht einmal der leicht metallische Klang war zu hören.
Auf dem Mac hat sich der Xing-Encoder etabliert, aber auch hier werden sich Programmierer der Sourcen wegen für lame entscheiden.
Unter Unix steht lame als Encoder der Wahl fest. Wenn man ein x86-Unix einsetzt, kann man mit gogo einen deutlichen Performance-Gewinn herausholen.
Letztendlich entscheiden aber auch die Features des speziellen Tools. Es ist auch Geschmacksfrage, ob man eher auf Command-Line-Tools steht oder auf GUIs. Und bei den GUI-Verfechtern gibt es auch gewichtige Unterschiede bei den einzelnen GUIs. Die Qualitätsunterschiede der Encoder sind heute nicht mehr so entscheidend, wenn man nicht Sprache bei sehr kleiner Bitrate encoden möchte. In diesem Fall ist der Fraunhofer-Encoder ungeschlagen, oder man weicht auf GSM oder H.232 aus.