Opus 1.5 रिलीज़: मशीन लर्निंग से अपग्रेड किया गया Opus

• मशीन लर्निंग आधारित फीचर्स के साथ packet loss concealment, low-bitrate speech quality improvement, और DRED redundant transmission जोड़े गए हैं, जबकि RFC 6716 के साथ पूर्ण संगतता बनाए रखी गई है
• नए ML आधारित फीचर्स डिफ़ॉल्ट रूप से निष्क्रिय हैं, और size तथा CPU cost के कारण build-time switch और runtime switch दोनों की आवश्यकता होती है
• Deep PLC को --enable-deep-plc के साथ build करना होता है और decoder complexity को 5 या उससे अधिक पर सेट करना होता है; यह केवल decoder को प्रभावित करता है, इसलिए compatibility पर कोई असर नहीं पड़ता
• DRED को --enable-dred से सक्षम किया जाता है और यह --enable-deep-plc को भी अपने आप सक्षम कर देता है; यह अभी standardize नहीं हुआ है, और Opus 1.5 का DRED अंतिम version के साथ compatible नहीं होगा, लेकिन bitstream के experimental version number से mismatch का पता लगाकर DRED payload को ignore कर दिया जाएगा
• DRED एक बार में अधिकतम 1 सेकंड तक का redundant audio भेजता है, और लगभग 12~32 kb/s overhead के साथ 20ms packet को व्यावहारिक रूप से 50 बार भेजने जैसा काम करता है
• low-bitrate speech improvement के लिए LACE और NoLACE जोड़े गए हैं; --enable-osce build के बाद decoder complexity 6 पर LACE, और 7 या उससे अधिक पर NoLACE सक्षम होता है
• LACE और NoLACE फिलहाल केवल तब लागू होते हैं जब frame size 20ms हो और bandwidth wideband या उससे अधिक हो; यह encoder से स्वतंत्र enhancement है, इसलिए compatibility पर कोई असर नहीं पड़ता
• DRED के उपयोग के लिए jitter buffer के साथ अधिक करीबी integration की आवश्यकता है, और Google WebRTC repository fork webrtc-opus-ng patch के जरिए DRED को आज़माया जा सकता है
• IETF mlcodec working group में Opus extension mechanism, deep redundancy, और speech coding enhancement के standardization पर काम चल रहा है
• AVX2/FMA support और runtime detection जोड़े गए हैं, जिससे supported hardware पर नया DNN code और SILK encoder 256-bit SIMD का उपयोग करते हैं
• AArch64 पर ARMv7 Neon optimization को फिर से सक्षम किया गया है, और Cortex-A75 या उससे ऊपर Arm dot product extension को runtime पर detect करके नए DNN code के 8-bit integer inner product को accelerate किया जाता है
• एक realistic packet loss simulator जोड़ा गया है, और --enable-lossgen build के बाद opus_demo में -sim-loss <percentage> के साथ इसका उपयोग किया जा सकता है

[GN⁺]

Hacker News की राय

• ऐसे codec की मुख्य सीमा CPU और battery life होती है, और यहां मुझे यह बात पसंद आई कि उन्होंने machine learning को जगह-जगह सीमित तौर पर लागू करके पारंपरिक non-machine-learning algorithms के साथ जोड़ा है, जिससे CPU बनाम quality का अच्छा trade-off मिला है
  उदाहरण के लिए, low-bitrate/LACE support में उन्होंने कहा कि “हमने proven postfilter ideas से शुरुआत की और उसके ऊपर deep-learning neural-network magic की बस उतनी ही परत डाली जितनी जरूरत थी”
  मुख्य बात यह है कि raw audio samples को neural network में नहीं डाला जाता। तरीका यह है: “audio खुद कभी DNN से होकर नहीं गुजरता। इसके परिणामस्वरूप DNN मानकों के हिसाब से model छोटा और बहुत कम complexity वाला है, जिसे पुराने phones पर भी चलाया जा सकता है”
  embedded algorithms के लिए यह सही दिशा लगती है, और आजकल लोकप्रिय end-to-end machine learning की तुलना में यह काफी कम explored क्षेत्र लगता है

  • यह machine learning के बहुत चतुर इस्तेमाल का उदाहरण है। इसे किनारे पर सहायक की तरह रखा गया है, और machine-learning algorithm को गलती से phonemes या पूरे शब्द गढ़ने से रोका गया है
    machine-learning आधारित speech recognition भी कुछ benchmarks में बेहतर होती है, लेकिन उसमें भी results hallucinate करने जैसा मिलता-जुलता trade-off है

• P2P audio streaming library (https://git.iem.at/cm/aoo/ - अभी alpha) में Opus को मुख्य codecs में से एक के तौर पर इस्तेमाल कर रहा हूं, इसलिए यह बहुत अच्छी खबर है
  नई machine-learning features को खुद जरूर आजमाना चाहूंगा

• NoLACE के साथ 9kbps पर इतनी अच्छी voice quality मिलना सच में अविश्वसनीय रूप से शानदार है

  • 1999 में मैं एक बड़े music streaming startup में lead developer था। तब तक office भी नहीं था, इसलिए घर से काम कर रहा था, और cable connection कट गया था, तो बचा हुआ internet सिर्फ Nokia 9000 serial port के जरिए 9600bps था
    production code की testing जारी रखने के लिए पूरे music catalog को 8000kbps WMA में दोबारा encode करके stream करना पड़ा
    quality थोड़ी निराशाजनक थी
  • सच में शुरुआती streaming audio codec, realaudio 1.0, से तुलना में यह कैसा सुनाई देगा, यह देखना चाहता था
    $ ffmpeg -i female_ref.wav - acodec real_144 female_ref.ra
    शायद support न हो, इसलिए फिर से wav में बदलकर अपलोड कर दिया: http://9ol.es/female_ref-ra.wav
    इसे 90 के दशक के मध्य में 14.4kb/s dial-up के लिए “14.4” audio माना जाता था। करीब 30 साल में, और असल में इससे भी कम bytes में, quality इतनी बेहतर हो गई है—यह सच में प्रभावित करता है

• audio codecs, speech synthesis और speech recognition जिस तरह एक-दूसरे से जुड़कर आगे बढ़ते हैं, वह दिलचस्प है। एक तरफ की प्रगति आम तौर पर दूसरी तरफ की प्रगति की ओर ले जाती है

• मेरी जिज्ञासा यह है कि क्या उन्होंने आम machine-learning ethics questions को address किया है। खासकर, algorithm पुरुष और महिला voices पर बेहतर या खराब perform करता है या नहीं, languages या dialects के हिसाब से कैसा है, और क्या यह शुरू से सिर्फ speech के लिए tuned है या music और birdsong पर भी अच्छा काम करता है
  फिर भी examples प्रभावशाली हैं, और उम्मीद है कि calls में समझ में आने वाली इस स्तर की quality standard बन जाए

  • paper के अनुसार training “34 languages और dialects, 900 से अधिक speakers वाले TTS datasets के combination से आए 16kHz speech के 205 hours” पर की गई थी
    testing मुख्यतः English में की गई, लेकिन यह अभी standardized नहीं है, इसलिए जल्दी public करने का एक कारण यह भी है कि लोग खुद इसे इस्तेमाल करें और समस्याएं report करें
    पुरुष और महिला speakers का ratio लगभग बराबर है। हालांकि codecs में pitch के आधार पर किसी न किसी दिशा में थोड़ा perceptual quality bias हमेशा होता है। और यहां की सारी चीजें सिर्फ speech के लिए हैं
  • यह महत्वपूर्ण सवाल है, लेकिन non-machine-learning के हाथ से tune किए गए algorithms में भी ऐसी bias आसानी से हो सकती है
    ऐसे मामलों में भी अच्छे parameters खोजने के लिए test sets, और कभी-कभी “training” व “validation” sets तक इस्तेमाल होते हैं। ये data, या decisions लेने वाले evaluators के कान—दोनों bias के source हो सकते हैं
    machine learning में bias का सवाल अक्सर इसलिए उठता है क्योंकि मूल रूप से data के बिना algorithm काम नहीं करता, लेकिन सभी algorithms इंसान design करते हैं और कई algorithms parameter setting के लिए data का सहारा लेते हैं। दोनों bias के source हो सकते हैं
    मेरे हिसाब से machine learning ज्यादा बदनाम इसलिए है क्योंकि इसमें traditional algorithms की तुलना में inductive bias कम होता है, इसलिए यह dataset में मौजूद bias को अधिक आसानी से अपना लेती है
  • मुझे नहीं समझ आता कि ethics issue क्यों महत्वपूर्ण है। यह audio codec का नया feature है, बच्चों के curriculum में डालने के लिए नई textbook नहीं
  • अलग languages और accents इस्तेमाल करने वाले के तौर पर मैं यह अक्सर झेलता हूं। native speakers को समस्या नहीं होती, लेकिन Siri जैसे assistants मेरी बात समझ नहीं पाते
    UTF के व्यापक होने से पहले websites और apps मेरे language में इस्तेमाल होने वाले special characters को ignore कर देते थे, यह भी कुछ वैसा ही था
    मैं इसे ethics issue से ज्यादा technical limitation या ignorance मानता हूं

• सोच रहा हूं कि अगर साथ में text subtitle stream भी डाल दी जाए तो कैसा होगा। encoder machine learning से speech को text में बदल सकता है, और decoder उस text तथा audio gap के आसपास के audio को साथ में इस्तेमाल करके conditional text-to-speech DNN में डाल सकता है
  तब network को सिर्फ audio देखकर missing segment को अंधाधुंध interpolate करने वाली कठिन समस्या सीखने की जरूरत नहीं पड़ेगी। text stream low-bitrate होगी, इसलिए किसी खास text message के receive होने की संभावना बढ़ाने के लिए काफी redundancy भी डाली जा सकती है

  • असल में DRED जो करता है, वह इस suggestion से बहुत दूर नहीं है। फर्क यह है कि यह voice/accent के बारे में ज्यादा जानकारी बचाए रखता है, और ASR द्वारा जोड़ा गया delay नहीं चाहिए होता
    आखिरकार output higher-level, efficiently compressed information से synthesize होता है

• बहुत बढ़िया। ऐसा लगता है कि उन्होंने hallucination problem को address किया है। जब redundancy नहीं होती तो hallucination पैदा होती है, और redundancy से वह ठीक होती है—ऐसे examples देखना दिलचस्प होगा

  • packet loss concealment (PLC) भी एक तरह की hallucination नहीं है क्या? मेरा मतलब बुरा नहीं है; यह statistically plausible तरीके से Making Shit Up™ ही तो है

• जानना चाहूंगा कि यह नया Opus version low bitrates पर बेहतर रहे xHE-AAC से gap कम कर पाया है या नहीं

  • यह इस पर निर्भर करता है कि आप speech encode कर रहे हैं या music

• अच्छा है कि Opus 1.5 अब speech में 16kbps पर भी practically transparent है, और 96kbps पर भी 192kbps MP3 से अब भी बेहतर है
  वहीं xHE-AAC में 96~256kbps range AAC-LC (Apple, FDK) के लगभग 160kbps से भी असल में खराब लगती है, इसलिए वह अभी भी अधपका सा लगता है

• काश कोई profiler या settings हों जो मौजूदा lossy formats को re-encode करते समय बहुत ज्यादा artifacts जोड़ने से बचाने में मदद करें
  बड़े collections में अगर lossless originals तक आसानी से access नहीं है तो यह समस्या आती है
  अगर यह पता चल सके कि अतिरिक्त quality loss minimal है, तो कई mp3, aac, vorbis files को Opus में migrate करने में मेरी काफी दिलचस्पी होगी