Opus 1.5 duyuruldu: makine öğrenimiyle yükseltilen Opus

• Makine öğrenimi tabanlı özellikler eklenerek paket kaybı gizleme, düşük bitrate ses kalitesi iyileştirmesi ve DRED yedekli iletim sağlanırken RFC 6716 ile tam uyumluluk korunuyor
• Yeni ML tabanlı özellikler varsayılan olarak devre dışıdır ve boyut ile CPU maliyeti nedeniyle hem derleme zamanında hem de çalışma zamanında anahtar gerektirir
• Deep PLC, --enable-deep-plc ile derlenmeli ve çalışması için decoder karmaşıklığı 5 veya üzerine ayarlanmalıdır; yalnızca decoder'ı etkilediği için uyumluluk üzerinde etkisi yoktur
• DRED, --enable-dred ile etkinleştirilir ve --enable-deep-plc seçeneğini de otomatik olarak etkinleştirir; henüz standartlaşmamıştır ve Opus 1.5'teki DRED son sürümle uyumlu değildir, ancak bit akışındaki deneysel sürüm numarasıyla uyuşmazlık algılanıp DRED payload'u yok sayılır
• DRED, bir seferde en fazla 1 saniyelik yedek sesi iletir; bu, yaklaşık 12~32 kb/s ek yükle 20 ms'lik paketi fiilen 50 kez göndermek anlamına gelir
• Düşük bitrate konuşma iyileştirmesi için LACE ve NoLACE eklendi; --enable-osce ile derlendikten sonra decoder karmaşıklığı 6'da LACE, 7 ve üzerinde NoLACE etkinleşir
• LACE ve NoLACE şu anda yalnızca 20 ms frame boyutu ve wideband veya üzeri bant genişliğinde uygulanır; encoder'dan bağımsız iyileştirmeler oldukları için uyumluluk üzerinde etkileri yoktur
• DRED kullanımı, jitter buffer ile daha yakın entegrasyon gerektirir; Google WebRTC deposunun bir fork'u olan webrtc-opus-ng yamasıyla DRED test edilebilir
• IETF mlcodec çalışma grubunda Opus genişletme mekanizması, deep redundancy ve konuşma kodlama iyileştirmesinin standardizasyonu üzerinde çalışılıyor
• AVX2/FMA desteği ve çalışma zamanı algılaması eklendi; böylece desteklenen donanımlarda yeni DNN kodu ile SILK encoder 256 bit SIMD kullanır
• AArch64 üzerinde ARMv7 Neon optimizasyonları yeniden etkinleştirildi ve Cortex-A75 veya üzerindeki sistemlerde Arm dot product uzantısı çalışma zamanında algılanarak yeni DNN kodunun 8 bit tamsayı iç çarpımları hızlandırılıyor
• Daha gerçekçi bir paket kaybı simülatörü eklendi; --enable-lossgen ile derlendikten sonra opus_demo içinde -sim-loss <percentage> ile kullanılabilir

[GN⁺]

Hacker News yorumları

• Bu tür codec’lerin başlıca sınırlaması CPU ve pil ömrü; burada makine öğrenmesini yer yer, seyrek biçimde uygulayıp geleneksel makine öğrenmesi dışı algoritmalarla birleştirerek CPU’ya karşı kalite dengesini iyi yakalamış olmaları hoşuma gitti
  Örneğin düşük bit hızı/LACE desteğinde “kanıtlanmış bir post-filter fikriyle başlayıp üstüne tam gerektiği kadar derin öğrenme sinir ağı sihri serpiştirdiklerini” söylüyorlar
  Kilit nokta, ham ses örneklerini sinir ağına sokmamaları. Yaklaşımları şu: “Sesin kendisi asla DNN’den geçmez. Sonuç olarak DNN ölçütlerine göre küçük ve karmaşıklığı çok düşük bir model ortaya çıkar; eski telefonlarda bile çalışabilir”
  Gömülü algoritmalar için doğru yön gibi görünüyor; bugünlerde moda olan uçtan uca makine öğrenmesine kıyasla epey daha az araştırılmış bir alan gibi duruyor

  • Makine öğrenmesini çok akıllıca kullanmışlar. Kenarda destekleyici olarak çalıştırıyorlar ve makine öğrenmesi algoritmasının tesadüfen fonemler ya da bütün kelimeler uydurmasını engelliyorlar
    Makine öğrenmesi tabanlı konuşma tanıma da bazı benchmark’larda daha iyi sonuç veriyor, ama benzer biçimde sonucu halüsinasyonla üretme ödünleşimi var

• P2P ses akışı kütüphanesinde (https://git.iem.at/cm/aoo/ - hâlâ alfa) Opus’u başlıca codec’lerden biri olarak kullandığımız için bu çok sevindirici bir haber
  Yeni makine öğrenmesi özelliklerini mutlaka kendim deneyeceğim

• NoLACE ile 9kbps’de bu kadar iyi konuşma kalitesi elde etmek gerçekten inanılmaz derecede etkileyici

  • 1999’da büyük bir müzik streaming startup’ında baş geliştiriciydim. Henüz ofisimiz bile yoktu, evden çalışıyordum; kablo bağlantım kesilince elimde kalan tek internet Nokia 9000 seri portu üzerinden 9600bps idi
    Üretim kodunu test etmeye devam edebilmek için tüm müzik kataloğunu 8000kbps WMA’ya yeniden encode edip stream etmem gerekti
    Kalite biraz hayal kırıklığıydı
  • Gerçekten erken dönem streaming ses codec’i olan realaudio 1.0 ile karşılaştırınca nasıl duyulacağını görmek istedim
    $ ffmpeg -i female_ref.wav - acodec real_144 female_ref.ra
    Desteklenmeyebilir diye tekrar wav’a çevirip yükledim: http://9ol.es/female_ref-ra.wav
    Bu, 90’ların ortasında 14.4kb/s çevirmeli bağlantı için “14.4” ses olarak görülürdü. Neredeyse 30 yılda, üstelik gerçekte daha az baytla elde edilebilen kalitenin bu kadar iyileşmiş olması gerçekten etkileyici

• Ses codec’leri, konuşma sentezi ve konuşma tanımanın birbirini besleyerek gelişme biçimi ilginç. Bir taraftaki ilerleme genellikle diğer tarafta da ilerlemeye yol açıyor

• Merak ettiğim şey, yaygın makine öğrenmesi etiği sorularını ele alıp almadıkları. Özellikle algoritmanın erkek ve kadın seslerinde daha iyi ya da daha kötü performans gösterip göstermediğini, dillere veya lehçelere göre durumun nasıl olduğunu, en başta yalnızca konuşmaya mı göre ayarlandığını yoksa müzik ya da kuş seslerinde de iyi çalışıp çalışmadığını merak ediyorum
  Yine de örnekler etkileyici; bu düzeyde anlaşılabilir kalitenin aramalarda standart hâline gelmesini umuyorum

  • Makaleye göre eğitim, “34 dil ve lehçe ile 900’den fazla konuşmacıyı içeren TTS veri setleri birleşiminden gelen 16kHz konuşma sesinden 205 saat” ile yapılmış
    Testler çoğunlukla İngilizce üzerinde yapılmış, ama henüz standartlaştırılmadığı için erken yayımlama nedenlerinden biri de insanların kendilerinin deneyip sorunları bildirmesini sağlamak
    Kadın ve erkek konuşmacı oranı neredeyse eşit. Ancak codec’ler her zaman ses perdesine bağlı olarak bir yönde az da olsa algısal kalite yanlılığı oluşturur. Ayrıca buradaki her şey yalnızca konuşma için
  • Önemli bir soru, ama makine öğrenmesi dışı, elle ayarlanmış algoritmalarda da benzer yanlılıklar kolayca bulunabilir
    Bu durumlarda da iyi parametreleri bulmak için test setleri, hatta bazen “eğitim” ve “doğrulama” setleri kullanılır. Bu veriler ya da karar veren değerlendiricilerin kulakları da yanlılık kaynağı olabilir
    Makine öğrenmesinde yanlılık sorusu sık gündeme geliyor, çünkü temelde veri olmadan algoritma çalışmaz; ama tüm algoritmalar insanlar tarafından tasarlanır ve birçok algoritma parametre ayarı için veriden yararlanır. İkisi de yanlılık kaynağı olabilir
    Bence makine öğrenmesinin daha çok bilinmesinin nedeni, geleneksel algoritmalara göre tümevarımsal yanlılığının daha az olması ve bu yüzden veri setindeki yanlılıkları daha kolay benimsemesi
  • Etik meselesinin neden önemli olduğunu anlamıyorum. Bu, bir ses codec’inin yeni özelliği; çocukların müfredatına konacak yeni bir ders kitabı değil
  • Farklı dil ve aksan kullanan biri olarak bunu sık yaşıyorum. Ana dili konuşanlarda sorun yokken Siri gibi asistanların benim söylemek istediğimi anlayamaması gibi
    UTF yaygınlaşmadan önce web siteleri ve uygulamaların dilimde kullanılan özel karakterleri yok sayması da benzerdi
    Bunu etik bir mesele olmaktan çok teknik bir sınırlama ya da bilgisizlik olarak görüyorum

• Yanına metin altyazı akışı eklemeye ne dersiniz diye düşünüyorum. Encoder, makine öğrenmesiyle konuşmayı metne dönüştürebilir; decoder da bu metni ve ses kopmalarının çevresindeki sesi birlikte kullanıp koşullu metinden konuşmaya DNN’ine verebilir
  Böylece ağın, yalnızca sese bakarak kopan bölümleri körlemesine enterpole etmeyi gerektiren daha zor problemi öğrenmesine gerek kalmaz. Metin akışı düşük bit hızlı olduğundan, belirli bir metin mesajının alınma olasılığını artırmak için ciddi miktarda yedeklilik de eklenebilir

  • Aslında DRED’in yaptığı şey bu öneriden çok da uzak değil. Farkı, ses/entonasyon hakkında daha fazla bilgiyi koruması ve ASR’ın ekleyeceği gecikmeye ihtiyaç duymaması
    Sonuçta çıktı, daha yüksek seviyeli ve verimli biçimde sıkıştırılmış bilgiden sentezleniyor

• Çok havalı. Halüsinasyon sorununu ele almış gibi görünüyor. Yedeklilik olmadığında halüsinasyonun ortaya çıktığı, yedeklilikle düzeldiği örnekleri görmek ilginç olurdu

  • Paket kaybı gizleme (PLC) de bir tür halüsinasyon değil mi? Kötü anlamda söylemiyorum; istatistiksel olarak makul bir şekilde Making Shit Up™ yapmak sonuçta

• Bu yeni Opus sürümünün, düşük bit hızlarında üstün olan xHE-AAC ile arasındaki farkı kapatıp kapatmadığını merak ediyorum

  • Konuşma mı yoksa müzik mi encode ettiğinize bağlı

• Opus 1.5’in artık konuşmada 16kbps’de bile fiilen şeffaf olması ve 96kbps’de de 192kbps MP3’ten hâlâ daha iyi olması güzel
  Buna karşılık xHE-AAC’nin 96~256kbps aralığı, AAC-LC’nin (Apple, FDK) yaklaşık 160kbps’inden bile pratikte daha kötü göründüğü için hâlâ baştan savma çıkmış gibi duruyor

• Mevcut kayıplı formatları yeniden encode ederken fazla artefakt eklememeye yardımcı olacak profiler ya da ayarlar olsa nasıl olur diye düşünüyorum
  Büyük koleksiyonlarda, kayıpsız orijinallere kolay erişim yoksa bu sorunla karşılaşılıyor
  Ek kalite kaybının minimum olduğunu bilebilsem, çeşitli mp3, aac ve vorbis dosyalarını Opus’a taşımaya ciddi ilgi duyarım