Sortie d’Opus 1.5 : Opus amélioré grâce au machine learning

• Des fonctionnalités basées sur le machine learning ont été ajoutées pour la dissimulation des pertes de paquets, l’amélioration de la qualité de la voix à faible débit binaire et la transmission redondante DRED, tout en conservant une compatibilité totale avec la RFC 6716
• Les nouvelles fonctionnalités basées sur le ML sont désactivées par défaut et nécessitent à la fois des options à la compilation et à l’exécution en raison de leur taille et de leur coût CPU
• Deep PLC se compile avec --enable-deep-plc et nécessite une complexité du décodeur définie à 5 ou plus pour fonctionner ; comme cela n’affecte que le décodeur, il n’y a aucun impact sur la compatibilité
• DRED s’active avec --enable-dred et active aussi automatiquement --enable-deep-plc ; ce n’est pas encore standardisé, et le DRED d’Opus 1.5 n’est pas compatible avec la version finale, mais l’incompatibilité est détectée via le numéro de version expérimentale du bitstream afin d’ignorer la charge utile DRED
• DRED permet de transmettre jusqu’à 1 seconde d’audio redondant en une seule fois, avec un surcoût d’environ 12 à 32 kb/s, ce qui revient en pratique à transmettre un paquet de 20 ms environ 50 fois
• Pour améliorer la voix à faible débit binaire, LACE et NoLACE ont été ajoutés ; après compilation avec --enable-osce, LACE s’active avec une complexité du décodeur de 6, et NoLACE à partir de 7
• LACE et NoLACE ne s’appliquent actuellement que lorsque la taille de trame est de 20 ms et que la bande passante est au moins wideband ; comme il s’agit d’améliorations indépendantes de l’encodeur, il n’y a aucun impact sur la compatibilité
• L’utilisation de DRED nécessite une intégration plus étroite avec le buffer de gigue, et il est possible de tester DRED avec le patch webrtc-opus-ng, un fork du dépôt Google WebRTC
• Le groupe de travail IETF mlcodec travaille à la standardisation du mécanisme d’extension d’Opus, de la redondance profonde et de l’amélioration du codage de la parole
• La prise en charge de AVX2/FMA et la détection à l’exécution ont été ajoutées afin que le nouveau code DNN et l’encodeur SILK utilisent le SIMD 256 bits sur les machines compatibles
• Sur AArch64, les optimisations ARMv7 Neon ont été réactivées, et l’extension Arm dot product est détectée à l’exécution sur les Cortex-A75 et plus récents afin d’accélérer les produits scalaires entiers 8 bits du nouveau code DNN
• Un simulateur réaliste de perte de paquets a été ajouté ; après compilation avec --enable-lossgen, il peut être utilisé dans opus_demo avec -sim-loss <percentage>

[GN⁺]

Avis sur Hacker News

• Les principales limites de ce genre de codec sont le CPU et l’autonomie de la batterie, et j’aime bien ici le fait qu’ils appliquent le machine learning par touches, ici et là, en le combinant avec des algorithmes traditionnels non ML pour trouver un bon compromis qualité/CPU
  Par exemple, pour la prise en charge du bas débit/LACE, ils disent être « partis d’une idée éprouvée de post-filtre, puis avoir saupoudré dessus juste ce qu’il faut de magie de réseau neuronal deep learning »
  Le point clé est de ne pas envoyer les échantillons audio bruts dans le réseau neuronal. Leur approche est la suivante : « l’audio lui-même ne passe jamais par le DNN. Il en résulte un modèle petit selon les standards des DNN et de très faible complexité, capable de tourner même sur de vieux téléphones »
  Cela semble être la bonne direction pour les algorithmes embarqués, et un domaine assez peu exploré comparé au machine learning de bout en bout à la mode ces temps-ci

  • C’est un usage très intelligent du machine learning. Il l’utilise comme assistance en périphérie, tout en empêchant l’algorithme de machine learning d’inventer par hasard des phonèmes ou des mots entiers
    La reconnaissance vocale basée sur le machine learning fait aussi mieux sur certains benchmarks, mais présente un compromis similaire avec des résultats hallucinés

• C’est une très bonne nouvelle, car nous utilisons Opus comme l’un des principaux codecs dans une bibliothèque de streaming audio P2P (https://git.iem.at/cm/aoo/ - encore en alpha)
  J’ai vraiment l’intention de mettre moi-même les mains sur ces nouvelles fonctionnalités de machine learning

• Obtenir une qualité vocale aussi bonne à 9 kbps avec NoLACE, c’est vraiment incroyablement impressionnant

  • En 1999, j’étais lead developer dans une grande startup de streaming musical. Nous n’avions même pas encore de bureaux, donc je travaillais depuis chez moi, mais ma connexion câble était tombée et il ne me restait qu’Internet en 9600 bps via le port série d’un Nokia 9000
    Pour continuer à tester le code de production, j’avais dû réencoder tout le catalogue musical en WMA à 8000 kbps et le streamer
    La qualité laissait un peu à désirer
  • J’ai voulu voir ce que cela donnerait comparé à realaudio 1.0, un codec audio de streaming vraiment ancien
    $ ffmpeg -i female_ref.wav - acodec real_144 female_ref.ra
    Comme il est possible que ce ne soit pas pris en charge, je l’ai reconverti en wav et mis en ligne : http://9ol.es/female_ref-ra.wav
    C’était considéré comme de l’audio « 14.4 » pour accès commuté à 14,4 kb/s au milieu des années 90. C’est vraiment impressionnant de voir à quel point la qualité que l’on peut obtenir, en fait avec encore moins d’octets, s’est améliorée en presque 30 ans

• Il est intéressant de voir comment les codecs audio, la synthèse vocale et la reconnaissance vocale progressent de manière interdépendante. Les avancées dans un domaine entraînent généralement des avancées dans les autres

• Ce que je me demande, c’est s’ils ont traité les questions courantes d’éthique du machine learning. Plus précisément, je me demande si l’algorithme fonctionne mieux ou moins bien avec les voix masculines ou féminines, selon les langues ou les dialectes, et s’il est d’abord adapté uniquement à la voix ou s’il fonctionne aussi bien pour la musique ou le chant des oiseaux
  Cela dit, les exemples sont impressionnants, et j’espère qu’une qualité intelligible de ce niveau deviendra la norme pour les appels

  • D’après l’article, l’entraînement a été effectué sur « 205 heures de parole à 16 kHz issues d’une combinaison de jeux de données TTS couvrant 34 langues et dialectes, avec plus de 900 locuteurs »
    Ils ont surtout testé en anglais, mais comme ce n’est pas encore standardisé, l’une des raisons de cette publication précoce est précisément de permettre aux gens de l’essayer eux-mêmes et de signaler les problèmes
    La proportion de locuteurs hommes/femmes est presque égale. Cela dit, les codecs introduisent toujours, selon la hauteur de voix, un léger biais de qualité perçue dans un sens ou dans l’autre. Et tout ce qui est présenté ici est uniquement destiné à la voix
  • C’est une question importante, mais des biais similaires peuvent facilement exister aussi dans des algorithmes non ML réglés à la main
    Dans ces cas-là aussi, on utilise des jeux de test, et parfois même des jeux « d’entraînement » et de « validation », pour trouver de bons paramètres. Ces données, tout comme les oreilles des évaluateurs qui prennent les décisions, peuvent être des sources de biais
    Avec le machine learning, la question du biais revient souvent parce que, fondamentalement, l’algorithme ne fonctionne pas sans données ; mais tous les algorithmes sont conçus par des humains, et beaucoup utilisent des données pour régler leurs paramètres. Les deux peuvent être des sources de biais
    À mon avis, si le machine learning est davantage pointé du doigt, c’est parce qu’il a moins de biais inductif que les algorithmes traditionnels et absorbe donc plus facilement les biais présents dans les jeux de données
  • Je ne vois pas pourquoi les questions d’éthique seraient importantes. C’est une nouvelle fonctionnalité d’un codec audio, pas un nouveau manuel scolaire à intégrer au programme des enfants
  • Quand on parle d’autres langues et avec d’autres accents, on rencontre souvent ce genre de problème. Les locuteurs natifs n’ont pas de souci, mais des assistants comme Siri ne comprennent pas ce que j’essaie de dire
    Avant que l’UTF soit largement utilisé, les sites web et les applications ignoraient de la même manière les caractères spéciaux utilisés dans ma langue
    Je vois cela davantage comme une limite technique ou de l’ignorance que comme une question d’éthique

• Je me demande ce que donnerait l’ajout d’un flux de sous-titres texte. L’encodeur pourrait utiliser le machine learning pour convertir la parole en texte, et le décodeur pourrait utiliser ce texte avec l’audio autour des coupures pour alimenter un DNN de synthèse vocale conditionnée par le texte
  Ainsi, le réseau n’aurait pas à apprendre le problème plus difficile consistant à interpoler aveuglément les portions manquantes uniquement à partir de l’audio. Le flux texte étant à faible débit, on pourrait aussi y ajouter beaucoup de redondance afin d’augmenter les chances qu’un message texte donné soit reçu

  • En réalité, ce que fait DRED n’est pas si éloigné de cette proposition. La différence est qu’il conserve davantage d’informations sur la voix/l’intonation, et qu’il n’a pas besoin de la latence supplémentaire qu’aurait ajoutée l’ASR
    Au final, la sortie est synthétisée à partir d’informations de plus haut niveau, compressées efficacement

• Très sympa. Ils semblent avoir traité le problème des hallucinations. Il serait intéressant de voir des exemples où des hallucinations apparaissent en l’absence de redondance, puis sont corrigées grâce à cette redondance

  • La dissimulation de perte de paquets (PLC) n’est-elle pas aussi une forme d’hallucination ? Je ne dis pas que c’est mauvais, mais c’est bien du Making Shit Up™ d’une manière statistiquement plausible

• Je me demande si cette nouvelle version d’Opus réduit l’écart avec xHE-AAC, qui était supérieur aux faibles débits

  • Cela dépend si l’on encode de la voix ou de la musique

• J’apprécie le fait qu’Opus 1.5 soit désormais pratiquement transparent pour la voix même à 16 kbps, et qu’à 96 kbps il reste meilleur que du MP3 à 192 kbps
  En revanche, xHE-AAC donne encore l’impression d’être sorti un peu à la va-vite, car entre 96 et 256 kbps il semble en pratique moins bon que l’AAC-LC (Apple, FDK) autour de 160 kbps

• Je me demande s’il pourrait y avoir un profileur ou des réglages aidant à ne pas ajouter trop d’artefacts lors du réencodage de formats avec perte existants
  Les grosses collections se heurtent à ce problème lorsqu’on n’a pas facilement accès aux originaux lossless
  Si je pouvais savoir que la perte de qualité supplémentaire est minimale, je serais très intéressé par la migration de nombreux fichiers mp3, aac et vorbis vers Opus