Rilis Opus 1.5: Opus yang Di-upgrade dengan Machine Learning

• Dengan fitur berbasis machine learning, ditambahkan packet loss concealment, peningkatan kualitas suara bitrate rendah, dan transmisi redundan DRED sambil tetap mempertahankan kompatibilitas penuh dengan RFC 6716
• Fitur baru berbasis ML dinonaktifkan secara default, dan karena ukuran serta biaya CPU, memerlukan sakelar saat build dan sakelar saat runtime
• Deep PLC dibangun dengan --enable-deep-plc dan harus dijalankan dengan kompleksitas decoder 5 atau lebih agar berfungsi; karena hanya memengaruhi decoder, tidak ada dampak terhadap kompatibilitas
• DRED diaktifkan dengan --enable-dred dan juga otomatis mengaktifkan --enable-deep-plc; belum distandardisasi, dan DRED di Opus 1.5 tidak kompatibel dengan versi final, tetapi ketidakcocokan dideteksi melalui nomor versi eksperimental pada bitstream sehingga payload DRED diabaikan
• DRED mengirim hingga 1 detik audio redundan sekaligus, dengan overhead sekitar 12~32 kb/s, pada dasarnya setara dengan mengirim paket 20 ms sebanyak 50 kali
• Untuk meningkatkan suara bitrate rendah, ditambahkan LACE dan NoLACE; setelah build dengan --enable-osce, LACE aktif pada kompleksitas decoder 6 dan NoLACE aktif pada 7 atau lebih tinggi
• LACE dan NoLACE saat ini hanya diterapkan ketika ukuran frame 20 ms dan bandwidth wideband atau lebih tinggi, dan karena peningkatannya independen dari encoder, tidak ada dampak terhadap kompatibilitas
• Penggunaan DRED memerlukan integrasi yang lebih dekat dengan jitter buffer, dan DRED dapat diuji melalui patch webrtc-opus-ng, sebuah fork dari repositori Google WebRTC
• Di kelompok kerja IETF mlcodec, sedang berlangsung pekerjaan standardisasi untuk mekanisme ekstensi Opus, deep redundancy, dan speech coding enhancement
• Ditambahkan dukungan AVX2/FMA dan deteksi runtime sehingga kode DNN baru dan encoder SILK menggunakan SIMD 256-bit pada perangkat yang didukung
• Pada AArch64, optimisasi ARMv7 Neon diaktifkan kembali, dan ekstensi Arm dot product pada Cortex-A75 atau lebih baru dideteksi saat runtime untuk mempercepat inner product integer 8-bit pada kode DNN baru
• Ditambahkan simulator packet loss yang realistis, dan setelah build dengan --enable-lossgen, dapat digunakan di opus_demo dengan -sim-loss <percentage>

[GN⁺]

Pendapat di Hacker News

• Batasan utama codec seperti ini adalah CPU dan daya tahan baterai, dan saya suka karena di sini machine learning diterapkan secara selektif di sana-sini lalu digabungkan dengan algoritma tradisional non-machine-learning, sehingga mendapatkan kompromi yang baik antara kualitas dan CPU
  Misalnya, dalam dukungan bitrate rendah/LACE, mereka mengatakan “memulai dari ide postfilter yang sudah teruji, lalu menaburkan sedikit saja sihir jaringan saraf deep learning di atasnya, tepat sesuai kebutuhan”
  Intinya adalah tidak memasukkan sampel audio mentah ke jaringan saraf. Pendekatannya adalah “audio itu sendiri tidak pernah melewati DNN. Hasilnya adalah model yang kecil menurut standar DNN dan memiliki kompleksitas sangat rendah, sehingga bisa dijalankan bahkan di ponsel lama”
  Ini tampak seperti arah yang tepat untuk algoritma embedded, dan dibandingkan machine learning end-to-end yang sedang populer akhir-akhir ini, kelihatannya merupakan area yang masih relatif kurang dieksplorasi

  • Ini contoh penggunaan machine learning yang sangat cerdas. Mereka membiarkannya membantu di tepi, sambil mencegah algoritma machine learning secara tidak sengaja mengarang fonem atau seluruh kata
    Speech recognition berbasis machine learning juga lebih baik pada beberapa benchmark, tetapi punya kompromi serupa berupa halusinasi hasil

• Ini kabar yang sangat menyenangkan karena saya memakai Opus sebagai salah satu codec utama di library streaming audio P2P (https://git.iem.at/cm/aoo/ - masih alfa)
  Saya pasti akan mencoba sendiri fitur-fitur machine learning baru ini

• Mendapatkan kualitas suara sebagus ini pada 9kbps dengan NoLACE benar-benar luar biasa

  • Pada 1999 saya adalah lead developer di sebuah startup streaming musik besar. Kami bahkan belum punya kantor, jadi saya bekerja dari rumah, tetapi koneksi kabel terputus dan satu-satunya internet yang tersisa hanya 9600bps lewat port serial Nokia 9000
    Agar bisa terus menguji kode produksi, saya harus meng-encode ulang seluruh katalog musik ke WMA 8000kbps dan melakukan streaming
    Kualitasnya agak mengecewakan
  • Saya ingin tahu seperti apa bunyinya dibandingkan realaudio 1.0, codec audio streaming yang benar-benar awal
    $ ffmpeg -i female_ref.wav - acodec real_144 female_ref.ra
    Karena mungkin tidak didukung, saya mengubahnya kembali ke wav dan mengunggahnya di sini: http://9ol.es/female_ref-ra.wav
    Ini dulu dianggap sebagai audio “14.4” untuk dial-up 14,4kb/s pada pertengahan 90-an. Sangat mengesankan melihat kualitas yang bisa didapat, bahkan dengan jumlah byte yang sebenarnya lebih sedikit, telah meningkat sejauh ini dalam hampir 30 tahun

• Menarik melihat bagaimana codec audio, sintesis suara, dan pengenalan suara berkembang saling terkait. Kemajuan di satu sisi biasanya mengarah pada kemajuan di sisi lain

• Yang saya penasaran adalah apakah mereka menangani pertanyaan-pertanyaan umum seputar etika machine learning. Secara spesifik, apakah algoritmanya berkinerja lebih baik atau lebih buruk pada suara pria dan wanita, bagaimana dengan berbagai bahasa atau dialek, dan apakah sejak awal memang disetel hanya untuk suara manusia atau juga bekerja baik pada musik atau kicau burung
  Meski begitu, contohnya mengesankan, dan saya berharap kualitas yang bisa dipahami seperti ini menjadi standar dalam panggilan telepon

  • Menurut makalahnya, pelatihan dilakukan dengan “205 jam audio suara 16kHz dari kombinasi dataset TTS yang mencakup 34 bahasa dan dialek serta lebih dari 900 pembicara”
    Mereka terutama mengujinya dalam bahasa Inggris, tetapi karena ini belum distandardisasi, salah satu alasan mereka merilisnya lebih awal adalah agar orang bisa mencobanya sendiri dan melaporkan masalah
    Rasio pembicara pria dan wanita hampir sama. Namun codec memang selalu memiliki sedikit bias kualitas perseptual ke satu arah atau lainnya tergantung tinggi nada. Dan semua yang ada di sini khusus untuk suara manusia
  • Ini pertanyaan penting, tetapi bias serupa juga bisa dengan mudah ada pada algoritma non-machine-learning yang disetel secara manual
    Dalam kasus seperti itu pun, test set, dan kadang bahkan set “training” dan “validation”, digunakan untuk menemukan parameter yang baik. Data seperti ini, maupun telinga evaluator yang mengambil keputusan, semuanya bisa menjadi sumber bias
    Dalam machine learning, pertanyaan bias sering muncul karena pada dasarnya algoritma tidak bekerja tanpa data, tetapi semua algoritma dirancang manusia dan banyak algoritma menggunakan data untuk pengaturan parameter. Keduanya bisa menjadi sumber bias
    Menurut saya machine learning lebih terkenal dalam hal ini karena memiliki bias induktif yang lebih sedikit daripada algoritma tradisional, sehingga lebih mudah menyerap bias yang ada dalam dataset
  • Saya tidak mengerti mengapa isu etika penting di sini. Ini fitur baru untuk codec audio, bukan buku ajar baru yang akan dimasukkan ke kurikulum anak-anak
  • Sebagai orang yang menggunakan bahasa dan aksen lain, saya sering mengalami hal seperti ini. Penutur asli tidak punya masalah, tetapi asisten seperti Siri tidak memahami apa yang ingin saya katakan
    Sebelum UTF digunakan luas, situs web dan aplikasi yang mengabaikan karakter khusus yang dipakai dalam bahasa saya juga mirip
    Saya melihat ini lebih sebagai keterbatasan teknis atau ketidaktahuan daripada masalah etika

• Saya bertanya-tanya bagaimana kalau menyertakan stream subtitle teks. Encoder bisa mengubah suara menjadi teks dengan machine learning, lalu decoder dapat menggunakan teks itu bersama audio di sekitar bagian audio yang terputus dan memasukkannya ke DNN text-to-speech bersyarat
  Dengan begitu jaringan tidak perlu mempelajari masalah yang lebih sulit, yaitu menginterpolasi bagian yang terputus secara buta hanya dari audio. Stream teks memiliki bitrate rendah, jadi redundansi yang cukup besar juga bisa ditambahkan untuk meningkatkan kemungkinan pesan teks tertentu diterima

  • Sebenarnya apa yang dilakukan DRED tidak terlalu jauh dari usulan itu. Perbedaannya adalah ia mempertahankan lebih banyak informasi tentang suara/aksen, dan tidak membutuhkan latensi tambahan yang akan ditambahkan ASR
    Pada akhirnya, output disintesis dari informasi tingkat lebih tinggi yang dikompresi secara efisien

• Sangat keren. Tampaknya mereka menangani masalah halusinasi. Akan menarik melihat contoh ketika halusinasi muncul saat tidak ada redundansi, lalu diperbaiki dengan redundansi

  • Bukankah packet loss concealment (PLC) juga semacam halusinasi? Bukan berarti buruk, tetapi memang semacam Making Shit Up™ dengan cara yang secara statistik masuk akal

• Saya penasaran apakah versi Opus baru ini memperkecil jarak dengan xHE-AAC yang selama ini unggul pada bitrate rendah

  • Tergantung apakah yang di-encode adalah suara atau musik

• Saya suka bahwa Opus 1.5 sekarang praktis transparan untuk suara bahkan pada 16kbps, dan pada 96kbps masih lebih baik daripada MP3 192kbps
  Sebaliknya, xHE-AAC masih terasa setengah matang karena rentang 96~256kbps justru tampak lebih buruk dalam praktik dibanding sekitar 160kbps AAC-LC (Apple, FDK)

• Saya bertanya-tanya apakah ada profiler atau pengaturan yang membantu agar tidak menambahkan terlalu banyak artefak saat meng-encode ulang format lossy yang sudah ada
  Koleksi besar akan menghadapi masalah ini jika tidak mudah mengakses master lossless
  Jika saya bisa tahu bahwa penurunan kualitas tambahannya minimal, saya sangat tertarik memindahkan berbagai file mp3, aac, dan vorbis ke Opus