Opus 1.5 veröffentlicht: Mit Machine Learning aufgerüstetes Opus

 (opus-codec.org)
1 Punkte von GN⁺ 2024-03-05 | 1 Kommentare | Auf WhatsApp teilen
  • Fügt Machine-Learning-basierte Funktionen für Packet Loss Concealment, verbesserte Sprachqualität bei niedrigen Bitraten und DRED-Redundanzübertragung hinzu und bleibt dabei vollständig kompatibel mit RFC 6716
  • Die neuen ML-basierten Funktionen sind standardmäßig deaktiviert und erfordern wegen Größen- und CPU-Kosten sowohl einen Schalter beim Build als auch zur Laufzeit
  • Deep PLC wird mit --enable-deep-plc gebaut und funktioniert nur, wenn die Decoder-Komplexität auf 5 oder höher gesetzt ist; da es nur den Decoder betrifft, gibt es keine Auswirkungen auf die Kompatibilität
  • DRED wird mit --enable-dred aktiviert und aktiviert automatisch auch --enable-deep-plc; es ist noch nicht standardisiert, und DRED in Opus 1.5 ist nicht mit der finalen Version kompatibel, erkennt aber Abweichungen über die experimentelle Versionsnummer des Bitstreams und ignoriert dann die DRED-Payload
  • DRED überträgt bis zu 1 Sekunde redundantes Audio auf einmal und sendet 20-ms-Pakete mit einem Overhead von etwa 12–32 kb/s praktisch 50-mal
  • Für Verbesserungen von Sprache bei niedrigen Bitraten wurden LACE und NoLACE hinzugefügt; nach dem Build mit --enable-osce wird bei Decoder-Komplexität 6 LACE und ab 7 NoLACE aktiviert
  • LACE und NoLACE gelten derzeit nur bei einer Frame-Größe von 20 ms und einer Bandbreite von mindestens Wideband; da es sich um encoderunabhängige Verbesserungen handelt, gibt es keine Auswirkungen auf die Kompatibilität
  • Für den Einsatz von DRED ist eine engere Integration mit dem Jitter Buffer erforderlich; mit dem Patch des Google-WebRTC-Repository-Forks webrtc-opus-ng lässt sich DRED testen
  • In der IETF-Arbeitsgruppe mlcodec läuft die Standardisierung von Opus-Erweiterungsmechanismen, tiefer Redundanz und Sprachcodierungsverbesserungen
  • Unterstützung für AVX2/FMA und Laufzeiterkennung wurde hinzugefügt, sodass der neue DNN-Code und der SILK-Encoder auf unterstützter Hardware 256-Bit-SIMD verwenden
  • Auf AArch64 wurden ARMv7-Neon-Optimierungen wieder aktiviert, und auf Cortex-A75 oder neuer wird die Arm-Dot-Product-Erweiterung zur Laufzeit erkannt, um 8-Bit-Integer-Skalarprodukte im neuen DNN-Code zu beschleunigen
  • Ein realistischer Packet-Loss-Simulator wurde hinzugefügt und kann nach dem Build mit --enable-lossgen in opus_demo mit -sim-loss <percentage> verwendet werden

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-03-05
Hacker-News-Kommentare

  • Die größten Einschränkungen solcher Codecs sind CPU und Akkulaufzeit, und mir gefällt hier, dass Machine Learning nur punktuell eingesetzt und mit klassischen Nicht-ML-Algorithmen kombiniert wird, um einen guten Kompromiss zwischen Qualität und CPU-Aufwand zu finden.
    Zum Beispiel heißt es zur Unterstützung niedriger Bitraten/LACE, man habe „mit einer bewährten Postfilter-Idee begonnen und darüber genau so viel Deep-Learning-Neural-Network-Magie gestreut, wie nötig war“.
    Entscheidend ist, dass die rohen Audiosamples nicht in ein neuronales Netz gegeben werden. Der Ansatz lautet: „Das Audio selbst läuft nie durch das DNN. Das Ergebnis ist ein für DNN-Maßstäbe kleines Modell mit sehr geringer Komplexität, das auch auf älteren Smartphones laufen kann.“
    Für eingebettete Algorithmen wirkt das wie die richtige Richtung, und verglichen mit dem heute populären End-to-End-Machine-Learning scheint es ein ziemlich wenig erkundetes Gebiet zu sein.

    • Ein sehr cleverer Einsatz von Machine Learning. Es unterstützt nur am Rand und verhindert, dass der ML-Algorithmus zufällig Phoneme oder ganze Wörter erfindet.
      ML-basierte Spracherkennung schneidet in manchen Benchmarks zwar besser ab, hat aber einen ähnlichen Trade-off mit halluzinierten Ergebnissen.

  • In einer P2P-Audiostreaming-Bibliothek (https://git.iem.at/cm/aoo/ – noch Alpha) nutze ich Opus als einen der wichtigsten Codecs, daher sind das sehr erfreuliche Nachrichten.
    Die neuen Machine-Learning-Funktionen werde ich mir auf jeden Fall selbst ansehen.

  • Mit NoLACE bei 9 kbps eine so gute Sprachqualität zu erreichen, ist wirklich absurd beeindruckend.

    • 1999 war ich Lead Developer bei einem großen Musikstreaming-Startup. Wir hatten noch nicht einmal ein Büro, also arbeitete ich von zu Hause, aber meine Kabelverbindung fiel aus, und als Internet blieb mir nur noch 9600 bps über den seriellen Port eines Nokia 9000.
      Um den Produktionscode weiter testen zu können, musste ich den gesamten Musikkatalog neu als WMA mit 8000 kbps encodieren und streamen.
      Die Qualität war etwas enttäuschend.
    • Ich wollte hören, wie das im Vergleich zu RealAudio 1.0 klingt, einem wirklich frühen Streaming-Audio-Codec.
      $ ffmpeg -i female_ref.wav - acodec real_144 female_ref.ra
      Da das möglicherweise nicht unterstützt wird, habe ich es wieder in WAV umgewandelt und hochgeladen: http://9ol.es/female_ref-ra.wav
      Das galt Mitte der 90er als „14.4“-Audio für 14,4-kb/s-Einwahlverbindungen. Es ist wirklich beeindruckend, wie sehr sich die Qualität, die man mit tatsächlich weniger Bytes erreichen kann, in fast 30 Jahren verbessert hat.

  • Es ist interessant, wie Audiocodecs, Sprachsynthese und Spracherkennung sich gegenseitig voranbringen. Fortschritte auf einer Seite führen meist zu Fortschritten auf der anderen.

  • Ich frage mich, ob die üblichen Ethikfragen rund um Machine Learning behandelt wurden. Konkret: Ob der Algorithmus bei männlichen oder weiblichen Stimmen besser oder schlechter funktioniert, wie es je nach Sprache oder Dialekt aussieht und ob er überhaupt nur auf Sprache optimiert ist oder auch bei Musik oder Vogelgesang gut funktioniert.
    Die Beispiele sind trotzdem beeindruckend, und ich hoffe, dass eine so gut verständliche Qualität bei Telefonaten zum Standard wird.

    • Laut Paper wurde mit „205 Stunden 16-kHz-Sprache aus einer Kombination von TTS-Datensätzen mit 34 Sprachen und Dialekten sowie über 900 Sprechern“ trainiert.
      Getestet wurde hauptsächlich auf Englisch, aber weil es noch nicht standardisiert ist, ist einer der Gründe für die frühe Veröffentlichung, dass Leute es selbst ausprobieren und Probleme melden können.
      Das Verhältnis männlicher und weiblicher Sprecher ist nahezu ausgeglichen. Allerdings haben Codecs je nach Tonhöhe immer eine gewisse wahrgenommene Qualitätsverzerrung in die eine oder andere Richtung. Und alles hier ist ausschließlich für Sprache gedacht.
    • Das ist eine wichtige Frage, aber ähnliche Biases können auch in handoptimierten Nicht-ML-Algorithmen leicht existieren.
      Auch dort nutzt man Testsets, manchmal sogar „Trainings“- und „Validierungs“-Sets, um gute Parameter zu finden. Sowohl diese Daten als auch die Ohren der Bewertenden, die Entscheidungen treffen, können Quellen von Bias sein.
      Bei Machine Learning kommt die Bias-Frage häufig auf, weil der Algorithmus ohne Daten grundsätzlich nicht funktioniert. Aber alle Algorithmen werden von Menschen entworfen, und viele Algorithmen nutzen Daten zur Parametereinstellung. Beides kann eine Quelle von Bias sein.
      Ich denke, Machine Learning ist dafür bekannter, weil es weniger induktiven Bias hat als klassische Algorithmen und daher Biases aus dem Datensatz leichter übernimmt.
    • Ich verstehe nicht, warum Ethik hier wichtig sein soll. Das ist ein neues Feature eines Audiocodecs, kein neues Lehrmaterial für den Schulunterricht von Kindern.
    • Als jemand mit einer anderen Sprache und einem anderen Akzent erlebe ich so etwas häufig. Muttersprachler haben kein Problem, aber Assistenten wie Siri verstehen nicht, was ich sagen will.
      Bevor UTF weit verbreitet war, war es ähnlich, wenn Websites und Apps Sonderzeichen ignorierten, die in meiner Sprache verwendet werden.
      Ich sehe das eher als technische Einschränkung oder Unwissenheit, nicht als Ethikproblem.

  • Ich frage mich, wie es wäre, zusätzlich einen Text-Untertitelstream einzubetten. Der Encoder könnte per Machine Learning Sprache in Text umwandeln, und der Decoder könnte diesen Text zusammen mit dem Audio rund um Aussetzer in ein bedingtes Text-to-Speech-DNN geben.
    Dann müsste das Netz nicht das schwierigere Problem lernen, fehlende Abschnitte blind nur aus dem Audio zu interpolieren. Der Textstream hat eine niedrige Bitrate, sodass man beträchtliche Redundanz einbauen könnte, um die Wahrscheinlichkeit zu erhöhen, dass eine bestimmte Textnachricht empfangen wird.

    • Tatsächlich ist das, was DRED macht, gar nicht so weit von diesem Vorschlag entfernt. Der Unterschied ist, dass mehr Informationen über Stimme/Akzent erhalten bleiben und die zusätzliche Latenz, die ASR verursacht hätte, nicht nötig ist.
      Am Ende wird die Ausgabe aus höherwertigen, effizient komprimierten Informationen synthetisiert.

  • Sehr cool. Es sieht so aus, als hätten sie das Halluzinationsproblem angegangen. Interessant wären Beispiele, bei denen Halluzinationen ohne Redundanz auftreten und durch Redundanz behoben werden.

    • Ist Packet Loss Concealment (PLC) nicht auch eine Art Halluzination? Nicht im negativen Sinn, aber es ist schon Making Shit Up™ auf statistisch plausible Weise.

  • Ich frage mich, ob diese neue Opus-Version den Abstand zu xHE-AAC verringert hat, das bei niedrigen Bitraten überlegen war.

    • Das hängt davon ab, ob man Sprache oder Musik encodiert.

  • Mir gefällt, dass Opus 1.5 bei Sprache jetzt schon bei 16 kbps praktisch transparent ist und bei 96 kbps immer noch besser als 192-kbps-MP3.
    xHE-AAC dagegen wirkt immer noch etwas halbgar, weil der Bereich von 96 bis 256 kbps tatsächlich schlechter aussieht als etwa 160 kbps bei AAC-LC (Apple, FDK).

  • Ich frage mich, ob es einen Profiler oder Einstellungen geben könnte, die dabei helfen, beim erneuten Encodieren vorhandener verlustbehafteter Formate nicht zu viele Artefakte hinzuzufügen.
    Große Sammlungen stoßen auf dieses Problem, wenn man keinen einfachen Zugriff auf verlustfreie Originale hat.
    Wenn ich wüsste, dass der zusätzliche Qualitätsverlust minimal ist, hätte ich großes Interesse daran, diverse MP3-, AAC- und Vorbis-Dateien nach Opus zu migrieren.