Constrained-Energy Lapped Transform

Constrained-Energy Lapped Transform (CELT; deutsch etwa: überlappende Transformation mit vorgegebener Energie) ist ein (patent-)freies Datenformat/Verfahren zur verlustbehafteten Audiodatenkompression mit besonders niedriger Codec-Latenz, um bei Echtzeit-Anwendungen in der Verarbeitung des typischerweise unmittelbar vor der komprimierten Übertragung erzeugten Signales möglichst wenig Verzögerung (Latenzzeit) zu verursachen. Das Verfahren ist offen dokumentiert und frei von Software-Patentrestriktionen nutzbar. Es wurde von der Xiph.Org Foundation (als Teil der Ogg-Codec-Familie) und der Codec-Arbeitsgruppe der Internet Engineering Task Force (IETF) entwickelt, ist mittlerweile jedoch in der Weiterentwicklung Opus aufgegangen. Damit ist CELT als eigenständiges Format aufgegeben worden und wird nur noch in seiner mit SILK integrierten, hybridisierten Form als eine Schicht von Opus weiterentwickelt. Dieser Artikel behandelt das historische, eigenständige Format, für die integrierte Form und die seit der Integration in Opus erfolgten Weiterentwicklungen siehe den Artikel zu Opus.

Eigenschaften

Die Zielsetzung ist ein Verfahren für Echtzeit-Anwendungen. Zentrales angestrebtes Merkmal dafür ist niedrige Codec-Latenz. CELT ermöglicht Latenzen von typischerweise 3 bis 9, jedoch konfigurierbar bis hinunter zu unter 2 Millisekunden, wobei niedrigere Latenzen höhere Bitraten brauchen, um wieder vergleichbare Qualität zu erreichen.<ref name="presentation" /> CELT unterbietet damit deutlich die mit anderen Standard-Codecs möglichen Latenzen.

Dabei ist es wie das Schwesterprojekt Vorbis ein breitbandiges (gesamter menschlicher Hörbereich abbildbar) Allzweck-Verfahren, also ohne Spezialisierung auf bestimmte Arten von Signalen, was es von seinem anderen Schwesterprojekt Speex abhebt. Es verarbeitet Audio-Signale mit Abtastraten zwischen 32 und 96 kHz und bis zu zwei Kanälen (Stereophonie). Damit ermöglicht das Format prinzipiell transparente Ergebnisse, jedoch auch Bitraten von bis hinunter zu 24 kBit/s.<ref name="presentation" /> Die Kompressionsfähigkeiten sollen insgesamt MP3 deutlich überlegen sein. Als weitere für einige Echtzeit-Anwendungen wie Telephonie nützliche Eigenschaft weist CELT eine sehr gute Leistung bei niedrigen Bitraten auf. Hier soll die Klangqualität mit Hilfe der Frequenzbandfaltung auch Vorbis deutlich überlegen und sogar ähnlich der von HE-AACv1 sein.<ref name="Jason" /><ref name="monty" /> In vergleichenden Doppelblind-Hörtests erwies es sich bei ~64 kBit/s als auch HE-AACv1 deutlich überlegen.<ref name="MPeX" />

Es hat eine vergleichsweise geringe Komplexität; der Berechnungsaufwand ähnelt dem der verzögerungsarmen Variante von AAC (AAC-LD) und hält sich deutlich unter dem von Vorbis.<ref name="TASL" />

Es ermöglicht konstante und variable Bitraten. Verschwindet in Sprechpausen und ähnlichen Fällen auf Encoder-Seite das Signal im Rauschteppich, so kann die Übertragung darauf beschränkt werden, dem Dekodierer die Überbrückung mit erzeugtem Komfortrauschen zu signalisieren. Die meisten Einstellungen des selbstverständlich streamingfähigen Formates können im laufenden Datenstrom gewechselt werden.

Das Format reagiert robust auf Übertragungsfehler. Sowohl der Verlust ganzer Pakete als auch Bitfehler können mit einer gleichmäßigen Zunahme an Störungen maskiert werden (Packet Loss Concealment, PLC).

Technik

CELT ist ein Transformations-Codec auf Basis der modifizierten diskreten Kosinustransformation (MDCT) und Ansätzen von CELP (Codebuch zur Anregung, jedoch in der Frequenzdomäne).

Das ursprüngliche PCM-codierte Signal wird für die MDCT (Fensterfunktion) in vergleichsweise kleine, überlappende Blöcke zerlegt und in Frequenzkoeffizienten transformiert. Durch die Wahl einer besonders geringen Blocklänge wird einerseits geringe Latenz ermöglicht, ergibt sich andererseits aber auch eine schlechte Frequenzauflösung, die ausgeglichen werden muss. Zur weiteren Reduzierung der Codec-Latenz auf Kosten geringfügiger Qualitätsverluste wird die ihrer Natur nach jeweils 50-prozentige Überlappung der MDCT-Zeitfenster praktisch halbiert, indem Anfang und Ende des Fensters für jeweils ein Achtel der Zeit das Signal auf Null gesetzt wird.<ref name="presentation" /> Unter anderem zur besseren Ausnutzung von blockübergreifenden Korrelationen trotz der sehr kurzen Blocklängen ist das Verfahren zustandsbehaftet und stützt die Kodierung eines CELT-Blockes auf Daten vergangener Blöcke.

Die Koeffizienten werden gruppiert zu Frequenzgruppen, die weitgehend denen der menschlichen Wahrnehmung entsprechen. Der gesamte Energiegehalt jeder Gruppe wird ausgewertet und diese Energiewerte werden quantisiert (=Datenreduktion) und mit einer Vorhersage komprimiert, indem nur noch Korrekturwerte zu den Vorhersagewerten übertragen werden müssen (Delta-Kodierung).

Aus den DCT-Koeffizienten werden jeweils die (unquantisierten) Energiewerte herausgerechnet (Normierung). Die Koeffizienten des somit erhaltenen Restsignales (englisch „band shape“) werden mit Pyramid Vector Quantisation (PVQ, einer sphärische Vektorquantisierung)<ref name="PVQ" /> kodiert. Diese Kodierung führt zu Codeworten von fester (vorhersehbarer) Länge, was Toleranz gegenüber Bitfehlern ermöglicht, und macht weiterhin eine Entropiekodierung überflüssig.<ref name="monty" /> Zum Abschluss werden dennoch alle Ausgangsdaten des Encoders noch mit einer Bereichskodierung zu einem einzigen Bitstrom zusammengepackt.<ref name="spec2" /> In Verbindung mit der PVQ nutzt CELT eine als Frequenzbandfaltung bezeichnete Technik, die durch die Wiederverwendung von Koeffizienten tieferer für höhere Frequenzbänder ähnliches wie die Spektralband-Replikation (SBR) leisten soll und dabei wesentlich niedrigere Implikationen für die Codec-Latenz und die Komplexität (Berechnungsaufwand) hat. Die dadurch erhöhte Reichhaltigkeit in den entsprechenden Frequenzbereichen verhindert die sonst üblicherweise auftretenden störenden Zwitscher-Artefakte (englisch „birdie artifacts“, „musical noise artifacts“).

Der Dekodierer entpackt den Bitstrom wieder in seine Bestandteile, multipliziert die errechneten separaten Energiewerte wieder mit den DCT-Koeffizienten des Restsignals zusammen und überführt sie mit der inversen MDCT wieder in PCM-Daten. Die einzelnen Blöcke werden mittels gewichteter segmentierter Faltung (englisch „weighted overlap add“, WOLA) wieder zusammengefügt. Viele Parameter werden nicht explizit übertragen, sondern stattdessen im Dekodierer mittels derselben Funktion gewonnen, wie im Encoder.

Für die Kanalkopplung stehen bei CELT M/S-Stereo und Pegeldifferenzstereophonie zur Verfügung. Blöcke können auch unabhängig beschrieben werden (Intra-kodierter Schlüsselblock), um zum Beispiel dem Dekodierer einen Einstieg in einen laufenden Datenstrom zu ermöglichen. Da bei Transformations-Codecs scharfe, energiereiche Klangereignisse (Transienten) hörbare Quantisierungsfehler im gesamten DCT-Block erzeugen können, welche vom Transienten in rückwärtiger zeitlicher Richtung weit weniger maskiert werden als danach, können als vorauseilende Echos wahrnehmbare Artefakte (englisch „pre-echo artifacts“) auftreten. Bei CELT können die Blöcke jeweils nochmal unterteilt werden, um solchen Artefakten entgegenzuwirken.

Geschichte

2005 arbeitete man bei Xiph im Rahmen des Ghost-Projekts erstmals an Plänen und Entwürfen für einen Vorbis-Nachfolger (anfangs im Gespräch als Vorbis II). Daraus entsprang neben den Codec-Plänen von Vorbis-Schöpfer Christopher Montgomery, die zugunsten der Weiterentwicklung von Theora auf Eis liegen, auch Jean-Marc Valins Konzept für ein besonders latenzarmes Verfahren. Seit 2007 entwickelt Valin an CELT und übertrug am 29. November ersten Code ins Repositorium des Projektes.<ref name="monty" /> Im Dezember 2007 wurde die erste Entwicklungsversion 0.0.1 veröffentlicht, zunächst benannt als Code-Excited Lapped Transform.<ref name="0.0.1" /> CELT liegt seit Juli 2009 bei der IETF als Vorschlag für einen freien Codec-Standard für Telekommunikation über das Internet vor<ref name="IETF" /><ref name="spec1" />, womit nun auch die Codec-Arbeitsgruppe der IETF an der Entwicklung beteiligt ist.

Ab Version 0.9 ist die bisher eingesetzte Tonhöhen-Vorhersage in der Frequenz-Domäne durch eine weniger komplexe Lösung mit einem Vor- und einem Nachfilter in der Zeitdomäne ersetzt,<ref name="complexity" /> welche von Raymond Chen von Broadcom beigesteuert wurde.<ref name="monty" />

Mit CELT 0.11 vom 4. Februar 2011 wurde das Bitstromformat vorläufig festgelegt – unter Vorbehalt eventueller, wider Erwarten nötiger letzter Änderungen.

Obwohl das Format noch nicht endgültig festgelegt ist, wird das Verfahren seit Januar 2009 in den IP-Telefonie-Anwendungen Ekiga und FreeSWITCH sowie mittlerweile auch Mumble, TeamSpeak und weiterer<ref name="software" /> Software verwendet. Kurz nach dem Erscheinen des Hybrid-Codecs Opus (früher bekannt als „Harmony“) ist CELT als Grundlage von Opus in diesem aufgegangen und wird ausschließlich im Rahmen dieses Nachfolgeprojektes weiterentwickelt.<ref name="opus" /> Opus stellt eine Obermenge zu CELT und dem Verfahren SILK dar, in dem die CELT-Algorithmen für einen oberen Frequenzanteil, die von SILK für den unteren zuständig sind. Der entsprechende Entwurf liegt bei der IETF seit September 2010 vor.

Im April 2011 wurde Unterstützung für CELT in FFmpeg aufgenommen.<ref name="ffmpeg1" /><ref name="ffmpeg2" />

Software

Referenzimplementierung ist eine in der Programmiersprache C geschriebene Programmbibliothek namens libcelt, die als freie Software unter Xiphs eigener dreiklausliger BSD-artiger Lizenz veröffentlicht wird.

Weblinks

• Offizielle Webpräsenz
• detailreicher Artikel von Vorbis-Schöpfer Christopher Montgomery (englischsprachig)
• IETF-Internet-Entwurf des RTP-Nutzlast-Formates

Quellen

<references> <ref name="presentation">Präsentation des Verfahrens von Timothy B. Terriberry (65 Minuten Video in ~100 MiB OggTheora+Vorbis, siehe auch Präsentationsfolien in PDF, ~2,3 MiB)</ref>

<ref name="Jason">Jason Garrett-Glaser: Important: upcoming CELT bitstream freeze! In: ffmpeg-devel.mplayerhq.hu - FFmpeg development discussions and patches mailing list. mplayerhq.hu, 18. November 2010, abgerufen am 25. Januar 2011 (englisch). </ref>

<ref name="MPeX">Dirk Bösel: CELT beeindruckt beim 64 kb/s Multiformat Hörtest (2011). In: MPeX.net. MPeX.net GmbH, 18. April 2011, abgerufen am 25. April 2011. </ref>

<ref name="TASL"> Jean-Marc Valin, Timothy B. Terriberry, Christopher Montgomery, Gregory Maxwell: A High-Quality Speech and Audio Codec With Less Than 10 ms Delay. In: IEEE Signal Processing Society (Hrsg.): IEEE Transactions on Audio, Speech and Language Processing. 18, Nr. 1, 17. April 2009 (http://people.xiph.org/~jm/papers/celt_tasl.pdf, abgerufen am 16. Februar 2011).</ref>

<ref name="PVQ"> Thomas R. Fischer: A pyramid vector quantizer. In: IEEE (Hrsg.): IEEE Transactions on Information Theory. 32, Nr. 4, Juli 1986.</ref>

<ref name="monty">Christopher Montgomery: next generation audio: CELT update 20101223. In: Monty's demo pages. Xiph.Org, 23. Dezember 2010, abgerufen am 26. Januar 2011 (english). </ref>

<ref name="spec2">zweiter bei der IETF eingereichter Entwurf der Spezifikation</ref>

<ref name="0.0.1">Jean-Marc Valin: Experimental release of Ghost/CELT 0.0.1. In: Hydrogenaudio Forums. 9. Dezember 2007, abgerufen am 26. Januar 2011 (englisch). </ref>

<ref name="IETF">Monika Ermert: IETF kümmert sich um lizenzfreien Audiocodec. In: heise online. 13. November 2009, abgerufen am 12. Februar 2011. </ref>

<ref name="spec1">erster bei der IETF eingereichter Entwurf der Spezifikation</ref>

<ref name="complexity">Jean-Marc Valin: CELT decoder complexity. In: CELT-dev-Mailingliste. Xiph.Org, 15. Februar 2011, abgerufen am 16. Februar 2011 (englisch). </ref>

<ref name="software">Software that uses or supports CELT. In: CELT-Website. Xiph.Org, abgerufen am 25. Januar 2011 (englisch). </ref>

<ref name="opus">Jean-Marc Valin, Koen Vos: Definition of the Opus Audio Codec. In: IETF Internet-Drafts. IETF Network Working Group, Oktober 2010, abgerufen am 25. Januar 2011 (englisch). </ref>

<ref name="ffmpeg1">http://ffmpeg.org/pipermail/ffmpeg-devel/2011-April/110850.html</ref>

<ref name="ffmpeg2">http://git.videolan.org/?p=ffmpeg.git;h=89451dd6e4da40ed73b8bbee2d48d8d8be1d5b0c</ref> </references>