Thomas Becker Softwareentwicklung
steht f?r (T)om's verlustfreier (A)udio(k)ompressor. Nebenbei ist es eine Reminiszenz an eine (nicht sehr menschenfreundliche) Figur aus Stephen King's "Regulators". Fr?he halb?ffentliche Evaluationsversionen firmierten unter dem Arbeitstitel YALAC.
Das folgende ZIP-Archiv enth舁t die aktuelle Version TAK 2.3.3 incl. Zubeh?r (Winamp plugin, SDK usw.):
Ich bin regelm葹ig im Forum "Lossless / Other Codecs" auf Hydrogenaudio aktiv. Dies ist derzeit der beste Ort um Unterst?tzung zu bekommen, Verbesserungsvorsch臠e zu machen oder Fehler zu berichten.
Audiokompressoren (nicht zu verwechseln mit Dynamikkompressoren!) werden eingesetzt, um den Platzbedarf von Audiodateien (z.B. Musik) zu reduzieren. Durch den Vorgang der Kompression bzw. Kodierung wird eine m?glichst kompakte Repr舖entation der Daten erzeugt und in eine Datei geschrieben. Das Gegenst?ck stellt die Dekomprimierung bzw. Dekodierung dar, die die komprimierten Daten wieder in eine Form zur?ckverwandelt, die zur Wiedergabe oder Weiterverarbeitung in Audiosoftware geeignet ist.
TAK geh?rt zur Famile der verlustfreien Audiokompressoren wie auch z.B. Flac, WavPack, Monkey's Audio usw. Im Gegensatz zu verlustbehafteten Audiokompressionsverfahren wie z.B. MP3 erlauben sie eine originalgetreue Wiederherstellung der Originaldatei aus den komprimierten Daten. Dabei entstehen keinerlei Verluste; das Ergebnis stellt eine bitgenaue Kopie des Originals dar. Verlustfreie Audiokompressoren verhalten sich also 臧nlich wie die bekannten ZIP-Pack-Programme, die ja in der Lage sind, ihnen anvertraute Daten wie z.B. Texte unverf舁scht zu reproduzieren.
Verlustbehaftete Audiokompressoren dagegen entfernen unwiederbringlich Bestandteile des ursp?nglichen Audiosignals, die von Menschen mit normalem H?rverm?gen ?blicherweise nicht wahrgenommen werden. Das Originalsignal kann also nicht wiederhergestellt werden.
Daf?r erzielen verlustbehaftete Audiokompressoren deutlich h?here Kompressionsraten, erzeugen also deutlich kleinere Dateien als verlustfreie Kompressoren. Eine MP3-Datei, die mit der g舅gigen konstanten Bitrate von 128 KBit komprimiert wurde, ist um etwa den Faktor 11 kleiner als die Originaldatei im CD-Audio Format. Verlustfreie Kompressoren erzielen dagegen im Schnitt nur eine Reduktion um den Faktor 2. (Tats臘hlich schwankt der Kompressionsfaktor in Abh舅gigkeit vom Audiomaterial: So lassen sich z.B. leisere Audiosignale leichter komprimieren als laute).
W臧rend der Umgang mit verlustbehafteten Audiokompressionsverfahren wie MP3 heutzutage f?r die meisten Musikliebhaber und Computernutzer allt臠lich ist, fristen verlustfreie Verfahren bislang eher ein Nischendasein. Nichtdestotrotz sind sie den verlustbehafteten Verfahren in vielen F舁len ?berlegen oder k?nnen sie hervorragend erg舅zen, z.B.:
Bei der Musikproduktion durchl舫ft das Originalsignal meist eine Vielzahl von Bearbeitungsschritten. Sollen Zwischenergebnisse zun臘hst gespeichert und sp舩er weiterverarbeitet werden, sind Verluste g舅zlich inakzeptabel, da die Verluste aller Speichervorg舅ge kumulieren und schnell zu h?rbaren Verf舁schungen f?hren. Ferner werden Signalver舅derungen der verlustbehafteten Kompression, die normalerweise nicht h?rbar sind, durch die ?blichen Klangmanipulationen der Produktion schnell ?ber die Wahrnehmungsgrenze gehoben.
Bei der Archivierung privater Musikbest舅de mag eine verlustbehaftete Kompression in einem Format, das f?r den Anwender keine h?rbaren Artefakte erzeugt, zun臘hst ausreichend erscheinen. Soll aber sp舩er ein Wechsel zu einem anderen verlustbehafteten Format durchgef?hrt werden (z.B. um Kompatibilit舩 zu neueren Wiedergabeger舩en herzustellen), besteht die Gefahr, da? die Kumulation der Signalverf舁schungen des urspr?nglichen sowie des neuen Kompressionsverfahrens eben doch zu h?rbaren Artefakten f?hrt.
Trotz aller beeindruckenden Fortschritte der verlustbehafteten Kompressionsverfahren lassen sich fast immer Musikst?cke finden, die zu h?rbaren Artefakten f?hren. Derzeit k?nnen nur verlustfreie Verfahren eine unverf舁schte Klangqualit舩 garantieren.
Um eine kompaktere Repr舖entation -also Kompression- der Daten zu erreichen, suchen alle verlustfreien Audiokompressoren nach Regelm葹igkeiten im Audiosignal. So besteht zumeist eine starke Abh舅gigkeit zwischen aufeinanderfolgenden Signalwerten, so da? nachfolgende Werte aus den vorangegangenen vorhergesagt werden k?nnen. Dazu m?ssen einige geeignete Parameter berechnet werden, die die Art der Abh舅gigkeit m?glichst gut beschreiben. Diese k?nnen dann zur Vorhersage bzw. Pr臈iktion eingesetzt werden. Anstelle der Originaldaten speichert der Kodierer dann die Differenzen zwischen der Vorhersage und dem Originalsignal, also den Pr臈iktionsfehler. Da die Differenzen bei einer guten Pr臈iktion viel kleiner sind als die Originalwerte und da kleinere Werte weniger Speicherplatz ben?tigen, erzielt man eine Kompression.
Im Dekodierer wird dieselbe Pr臈iktion vorgenommen, wobei der vom Kodierer gespeicherte Pr臈iktionsfehler zu den vorhergesagten Werten addiert wird, um die Originalwerte zur?ckzuerhalten.
Die Berechnung der otpimalen Parameter f?r die Pr臈iktion ist der zeitaufwendigste Vorgang der Kompression.
Pr臈iktionsparameter m?ssen zu dem Signal passen, f?r dessen Vorhersage sie eingesetzt werden sollen. Ver舅dern sich entscheidende Aspekte des Audiosignals, mu? eine Neuberechnung bzw. Adaption der Pr臈iktionsparameter durchgef?hrt werden.
TAK basiert im wesentlichen auf adaptiver linearer Vorw舐ts-Pr臈iktion. Dieselbe Technik wird z.B. von FLAC, LPAC, Mpeg4Als (in der Standardeinstellung) und Shorten verwendet.
Alle genannten Programme geh?ren zur Klasse der asymmetrischen Audiokompressoren. Die Asymmetrie bezieht sich auf den unterschiedlichen Rechenaufwand f?r den Vorgang der Kodierung und Dekodierung.
Alle f?r die Kompression relevanten Parameter (vor allem die der Pr臈iktion) werden einmalig w臧rend der Kodierung berechnet und in der komprimierten Datei gespeichert. Der Dekodierer liest diese Parameter einfach aus der Datei, braucht die entsprechenden Berechnungen also nicht zu wiederholen und kann so sehr hohe Geschwindigkeiten erzielen. Ferner ist es m?glich, den Rechenaufwand im Kodierer zu erh?hen, um bessere Parameter f?r eine st舐kere Kompression zu erhalten, ohne da? dies den Rechenaufwand im Dekodierer signifikant steigern w?rde. In der Folge sinkt die Verarbeitungsgeschwindigkeit des Kodierers, w臧rend die des Dekodierers konstant (hoch) bleibt.
Bei symmetrischen Verfahren (eingesetzt z.B. in WavPack, Monkey's Audio, OptimFrog, LA) dagegen werden die Berechnungen der Kompressionsparameter sowohl im Kodierer als auch im Dekodierer durchgef?hrt, soda? auf beiden Seiten ungef臧r derselbe Rechenaufwand entsteht. Wird der Rechenaufwand im Enkodierer erh?ht, um die Kompressionsleistung zu verbessern, steigt der Rechenaufwand im Dekodierer gleicherma?en.
Aber symmetrische Verfahren bieten auch Vorteile. Sie verwenden in der Regel die sogenannte R?ckw舐tspr臈iktion, die die Kompressionsparameter kontinuierlich aufgrund des vorangegangenen Signals berechnet. Da dies gleicherma?en im Kodierer wie im Dekodierer geschieht, brauchen die Kompressionsparameter nicht gespeichert werden, was Platz spart und die Kompressionsrate erh?ht. Und da die Parameter nicht gespeichert werden m?ssen, k?nnen sie beliebig oft bzw. schnell an Ver舅derungen des Audiosignal angepa?t werden, was die Kompressionsrate weiter erh?ht. Symmetrische Verfahren mit Vorw舐ts-Pr臈iktion dagegen k?nnen diese Adaption nur in gr??eren Intervallen vornehmen, da andernfalls der Speicherbedarf f?r die h舫figer aktualisierten Kompressionsparameter den Gewinn der schnellen Anpassung ?bersteigen w?rde.
Anmerkung: Auf die M?glichkeit, beide Verfahren zu kombinieren, soll an dieser Stelle nicht eingegangen werden.
Vergleichstests der Leistung aktuell g舅giger verlustfreier Kompressionsprogramme best舩igen im gro?en und ganzen die Vorhersagen, die sich aus den unterschiedlichen Funktionsprinzipien ergeben: Asymmetrische Verfahren dekodieren deutlich schneller, w臧rend symmetrische Verfahren die h?chsten Kompressionsraten erzielen k?nnen, wenn auch auf Kosten der Dekodiergeschwindigkeit.
Bei der Entwicklung von TAK standen diese Anforderungen in Vordergrund:
Das gesamte Design wurde auf hohe Geschwindigkeit ausgerichtet und unterscheidet sich in einigen Punkten deutlich von dem anderer asymmetrischer Kompressoren.
Einige Merkmale:
Die vom Enkodierer erzeugten komprimierten Frames werden in ein eigenes, propriet舐es Containerformat verpackt, das folgende Merkmale aufweist:
geplanter Erweiterungen:
Die Position in der Liste wird durch wenistens zwei Faktoren bestimmt: die Priorit舩, die eine Erweiterung f?r mich (und die Anwender) hat, sowie durch den erforderlichen Aufwand. So messe ich der Unterst?tzung f?r andere Plattformen eigentlich eine recht hohe Bedeutung zu, habe sie aber aufgrund des betr臘htlichen Aufwandes zun臘hst zur?ckgestellt.
Meine ersten Gehversuche im Bereich (verlustbehafteter) Audiokompression erfolgten bereits 1994. Ich erfoschte eine Reihe eher simpler Verfahren, die zun臘hst mehr oder weniger auf ADPCM (Adaptive Delta Pulse Code Modulation) basierten und von mir zur Kompression von Sprachaufnahmen eingesetzt wurden.
Etwa 1996 wandte ich mich der verlustfreien Audiokompression mittels linearer Pr臈iktion zu. Da ich kaum Ahnung von den Standardverfahren der digitalen Signalverarbeitung hatte, nutzte ich zun臘hst eine (laaangsame) multiple Regression zur Bestimmung der P臈iktionskoeffizienten.
1997 brachte mir einen Internetzugang und es dauerte nicht lange, bis ich auf den Audiokompressor Shorten stie?. Auch wenn Shorten aus heutiger Sicht nicht mehr konkurrenzf臧ig ist, sollte seine Bedeutung f?r die Entwicklung der Audiokompression keinesfalls untersch舩zt werden. Zum einen war es der erste Quasi-Standard f?r den Austauch verlustfrei komprimierter Audiodateien via Internet, zum anderen haben sein Quellcode und die ausf?hrliche Dokumentation der eingesetzten Verfahren sicher vielen Entwicklern anderer Kompressoren als Einstig und Anregung gedient. Mir jedenfalls zeigte es ein schnelleres Verfahren zur Berechnung der Pr臈iktionskoeffizienten, n舂lich den Levinson-Durbin-Algorithmus.
Mein anf舅gliche Euphorie dar?ber, wie leicht es mir fiel, mittels meiner Verfahren deutlich bessere Kompressionsergebnisse als Shorten zu erzielen, war dahin, als ich auf Monkey's Audio stie?. Es war meinem damaligen Entwicklungsstand in jeder Hinsicht ?berlegen: Es komprimierte nicht nur besser sondern dazu auch noch mit h?herer Geschwindigkeit! In den Folgejahren konzentrierte sich meine Entwicklungsarbeit darauf, diesen Vorsprung aufzuholen.
Ende M舐z 2006 war -salopp gesagt- "die Luft raus". Ich hatte meine Ziele erreicht und sah keine M?glichkeit mehr, aus meinem Design deutliche Verbesserungen herauszuarbeiten. Da ich mir nicht sicher war, was ich nun sinnvolles mit dem Ergebnis meiner Arbeit anstellen sollte, fragte ich meine potentielle Zielgruppe im renomierten Audioforum hydrogenaudio.org: Yet another lossless audio compressor: Braucht die Welt ein weiteres verlustfreies Audiokompressionsverfahren?
Dieser Post brachte einiges an Dynamik in die weitere Entwicklungsgeschichte. Zun臘hst versorgte mich die ?berwiegend positive Resonanz auf die von mir ver?ffentlichten Daten zur Kompressionsleistung mit neuer Motivation. Weiterer Antrieb erwuchs aus meinem ausgesprochen schlechten Timing: Wer als Neuling ausgerechnet am 1. April ?berraschend gute Ergebnisse seines unver?ffentlichten Programmes postet, darf sich nicht beklagen, wenn ihm die H舁fte der Leser nicht glaubt...
Da ich mich nun in Beweisnot sah, entwickelte ich innerhalb weniger Tage einen funktionsf臧igen Prototypen (YALAC V0.01) und schickte ihn an einen kleinen Kreis interessierter Tester aus den Reihen der Forumsmitglieder.
Versehen mit neuer Motivation und mit teilweise unglaublich umfangreicher Unterst?tzung der Tester verbrachte ich die folgenden Monate mit Verbesserungen der Kompressionsleistung und vor allem der Geschwindigkeit (es war doch noch einiges rauszukitzeln...). Die Optimierungen wurden bis zur Version V0.10 fortgesetzt. Danach begann die Arbeit am Streaming-Support, der Finalisierung des Dateiformates sowie an der Verbesserung der Anwenderfreundlichkeit.
Die erste finale Version 1.0 wurde am 26.1.07 ver?ffentlicht.