เปิดตัว Opus 1.5: Opus ที่อัปเกรดด้วยแมชชีนเลิร์นนิง

 (opus-codec.org)
1 คะแนน โดย GN⁺ 2024-03-05 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • รักษาความเข้ากันได้อย่างสมบูรณ์กับ RFC 6716 พร้อมเพิ่ม ความสามารถบนพื้นฐานของแมชชีนเลิร์นนิง ได้แก่ packet loss concealment, การปรับปรุงคุณภาพเสียงพูดที่บิตเรตต่ำ และการส่งซ้ำแบบ DRED
  • ความสามารถใหม่ที่อิง ML จะถูกปิดไว้เป็นค่าเริ่มต้น และเนื่องจากมีต้นทุนด้านขนาดและ CPU จึงต้องมีทั้งสวิตช์ตอน build และสวิตช์ตอนรันไทม์
  • Deep PLC ต้อง build ด้วย --enable-deep-plc และตั้งค่า decoder complexity เป็น 5 ขึ้นไปจึงจะทำงานได้ และเพราะมีผลเฉพาะกับตัวถอดรหัส จึงไม่มีผลต่อความเข้ากันได้
  • DRED เปิดใช้ด้วย --enable-dred และจะเปิด --enable-deep-plc ให้อัตโนมัติ; ยังไม่ได้ผ่านการทำให้เป็นมาตรฐาน และ DRED ใน Opus 1.5 ไม่เข้ากันได้กับเวอร์ชันสุดท้าย แต่จะตรวจจับความไม่ตรงกันด้วยหมายเลขเวอร์ชันทดลองของบิตสตรีมแล้วละทิ้ง DRED payload
  • DRED ส่งเสียงซ้ำได้สูงสุด 1 วินาทีในครั้งเดียว โดยมีโอเวอร์เฮดราว 12~32 kb/s ซึ่งเทียบได้กับการส่งแพ็กเก็ต 20ms ซ้ำแทบจะ 50 ครั้ง
  • เพิ่ม LACE และ NoLACE สำหรับปรับปรุงเสียงพูดที่บิตเรตต่ำ โดยหลังจาก build ด้วย --enable-osce จะเปิด LACE ที่ decoder complexity 6 และเปิด NoLACE ที่ 7 ขึ้นไป
  • ขณะนี้ LACE และ NoLACE ใช้ได้เฉพาะเมื่อขนาดเฟรมเป็น 20ms และแบนด์วิดท์เป็น wideband ขึ้นไป และเป็นการปรับปรุงที่แยกจาก encoder จึงไม่มีผลต่อความเข้ากันได้
  • การใช้งาน DRED ต้องการการผสานรวมกับ jitter buffer อย่างใกล้ชิดมากขึ้น และสามารถทดลอง DRED ได้ด้วยแพตช์ webrtc-opus-ng ซึ่งเป็นฟอร์กของคลังเก็บ Google WebRTC
  • คณะทำงาน IETF mlcodec กำลังดำเนินการมาตรฐานสำหรับกลไกส่วนขยายของ Opus, deep redundancy และ speech coding enhancement
  • เพิ่มการรองรับ AVX2/FMA และการตรวจจับขณะรันไทม์ ทำให้อุปกรณ์ที่รองรับสามารถใช้ 256-bit SIMD สำหรับโค้ด DNN ใหม่และ SILK encoder
  • บน AArch64 ได้เปิดใช้การปรับแต่ง ARMv7 Neon อีกครั้ง และตรวจจับ Arm dot product extension ขณะรันไทม์บน Cortex-A75 ขึ้นไป เพื่อเร่ง inner product ของจำนวนเต็ม 8 บิตในโค้ด DNN ใหม่
  • เพิ่มตัวจำลอง packet loss ที่สมจริง และหลังจาก build ด้วย --enable-lossgen แล้วสามารถใช้ใน opus_demo ด้วย -sim-loss <percentage>

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-03-05
ความคิดเห็นบน Hacker News

  • ข้อจำกัดหลักของโคเดกแบบนี้คือ CPU และอายุแบตเตอรี่ ซึ่งในกรณีนี้ชอบตรงที่นำแมชชีนเลิร์นนิงมาใช้แบบประปรายในหลายจุด แล้วผสานกับอัลกอริทึมแบบดั้งเดิมที่ไม่ใช่แมชชีนเลิร์นนิง ทำให้หาจุดประนีประนอมระหว่างคุณภาพกับการใช้ CPU ได้ดี
    เช่น ในการรองรับบิตเรตต่ำ/LACE พวกเขาบอกว่า “เริ่มจากไอเดียโพสต์ฟิลเตอร์ที่พิสูจน์แล้ว แล้วโรยเวทมนตร์โครงข่ายประสาทเชิงลึกลงไปเท่าที่จำเป็นพอดี”
    ประเด็นสำคัญคือไม่ป้อนตัวอย่างเสียงดิบเข้าโครงข่ายประสาท “ตัวเสียงเองจะไม่ผ่าน DNN เลย ผลคือได้โมเดลที่เล็กและซับซ้อนต่ำมากตามมาตรฐาน DNN จนรันบนโทรศัพท์รุ่นเก่าได้” นี่คือแนวทางของพวกเขา
    ดูเหมือนเป็นทิศทางที่ถูกสำหรับอัลกอริทึมแบบฝังตัว และเมื่อเทียบกับ แมชชีนเลิร์นนิงแบบ end-to-end ที่กำลังเป็นกระแส ก็ดูเหมือนยังเป็นพื้นที่ที่ถูกสำรวจค่อนข้างน้อย

    • เป็นตัวอย่างการใช้แมชชีนเลิร์นนิงที่ฉลาดมาก ให้มันช่วยอยู่ตามขอบ ๆ และป้องกันไม่ให้อัลกอริทึมแมชชีนเลิร์นนิงบังเอิญ แต่งหน่วยเสียงหรือทั้งคำขึ้นมาเอง
      การรู้จำเสียงพูดที่ใช้แมชชีนเลิร์นนิงก็ทำได้ดีกว่าในบาง benchmark แต่ก็มีการแลกเปลี่ยนคล้ายกันเรื่องผลลัพธ์ที่หลอนขึ้นมา

  • เป็นข่าวที่น่ายินดีมาก เพราะผมใช้ Opus เป็นหนึ่งในโคเดกหลักในไลบรารีสตรีมเสียงแบบ P2P (https://git.iem.at/cm/aoo/ - ยังเป็นอัลฟา)
    ตั้งใจว่าจะลองจับฟีเจอร์แมชชีนเลิร์นนิงใหม่ ๆ ด้วยตัวเองแน่นอน

  • การได้คุณภาพเสียงพูดที่ดีขนาดนี้ที่ 9kbps ด้วย NoLACE นี่สุดยอดจนน่าเหลือเชื่อจริง ๆ

    • ปี 1999 ผมเป็นหัวหน้านักพัฒนาของสตาร์ทอัพสตรีมมิงเพลงรายใหญ่ ตอนนั้นยังไม่มีออฟฟิศ เลยทำงานจากบ้าน แล้วสายเคเบิลขาด อินเทอร์เน็ตที่เหลืออยู่มีแค่ 9600bps ผ่าน พอร์ตอนุกรมของ Nokia 9000
      เพื่อจะทดสอบโค้ดโปรดักชันต่อ ต้องเข้ารหัสแคตตาล็อกเพลงทั้งหมดใหม่เป็น WMA ที่ 8000kbps แล้วสตรีม
      คุณภาพก็ไม่ค่อยน่าพอใจนัก
    • อยากฟังเหมือนกันว่าเมื่อเทียบกับ realaudio 1.0 ซึ่งเป็นโคเดกเสียงสตรีมมิงยุคแรกมาก ๆ แล้วจะออกมาเป็นยังไง
      $ ffmpeg -i female_ref.wav - acodec real_144 female_ref.ra
      อาจไม่รองรับ เลยแปลงกลับเป็น wav แล้วอัปโหลดไว้: http://9ol.es/female_ref-ra.wav
      นี่เคยถูกมองว่าเป็นเสียง “14.4” สำหรับการต่ออินเทอร์เน็ตผ่านโทรศัพท์ที่ 14.4kb/s ในช่วงกลางยุค 90 น่าประทับใจจริง ๆ ที่ตลอดเกือบ 30 ปี คุณภาพที่ได้ดีขึ้นขนาดนี้ ทั้งที่จริง ๆ ใช้จำนวนไบต์น้อยกว่าด้วย

  • น่าสนใจที่ โคเดกเสียง การสังเคราะห์เสียงพูด และการรู้จำเสียงพูด พัฒนาควบคู่และเชื่อมโยงกัน ความก้าวหน้าของด้านหนึ่งมักนำไปสู่ความก้าวหน้าของอีกด้าน

  • สิ่งที่สงสัยคือพวกเขาได้จัดการกับ คำถามด้านจริยธรรมของแมชชีนเลิร์นนิง ที่พบบ่อยหรือไม่ โดยเฉพาะอยากรู้ว่าอัลกอริทึมทำงานได้ดีหรือแย่กว่ากันกับเสียงผู้ชายและเสียงผู้หญิงหรือไม่ เป็นอย่างไรกับภาษาและสำเนียงต่าง ๆ และตั้งใจให้เหมาะกับเสียงพูดตั้งแต่แรกเท่านั้นหรือว่าใช้กับเพลงหรือเสียงนกได้ดีด้วย
    ถึงอย่างนั้นตัวอย่างก็น่าประทับใจ และหวังว่าคุณภาพระดับที่ฟังรู้เรื่องขนาดนี้จะกลายเป็นมาตรฐานในการโทร

    • ตามบทความวิจัย ระบุว่าการฝึกใช้ “เสียงพูด 16kHz จำนวน 205 ชั่วโมง จากชุดข้อมูล TTS หลายชุดที่รวม 34 ภาษาและสำเนียง และผู้พูดมากกว่า 900 คน”
      ทดสอบกับภาษาอังกฤษเป็นหลัก แต่เพราะยังไม่ได้มาตรฐาน เหตุผลหนึ่งที่ปล่อยออกมาเร็วก็เพื่อให้ผู้คนลองใช้เองแล้วรายงานปัญหา
      สัดส่วนผู้พูดชายหญิงเกือบเท่ากัน อย่างไรก็ดี โคเดกมักมีอคติด้านคุณภาพที่รับรู้ได้เล็กน้อยไปทางใดทางหนึ่งตามระดับเสียงอยู่เสมอ และทุกอย่างตรงนี้เป็นสำหรับเสียงพูดเท่านั้น
    • เป็นคำถามสำคัญ แต่ อคติ แบบเดียวกันก็เกิดได้ง่ายในอัลกอริทึมที่ปรับแต่งด้วยมือและไม่ใช่แมชชีนเลิร์นนิง
      ในกรณีแบบนั้นก็ยังใช้ชุดทดสอบ และบางครั้งใช้ชุด “ฝึก” กับ “ตรวจสอบ” เพื่อหา parameter ที่ดี ข้อมูลเหล่านี้ หรือแม้แต่หูของผู้ประเมินที่ตัดสินใจ ก็ล้วนเป็นแหล่งที่มาของอคติได้
      ในแมชชีนเลิร์นนิง คำถามเรื่องอคติมักถูกยกขึ้นมาบ่อย เพราะโดยพื้นฐานแล้วถ้าไม่มีข้อมูล อัลกอริทึมก็ทำงานไม่ได้ แต่ทุกอัลกอริทึมถูกออกแบบโดยมนุษย์ และหลายอัลกอริทึมใช้ข้อมูลในการตั้งค่า parameter ทั้งสองอย่างเป็นแหล่งที่มาของอคติได้
      ผมคิดว่าเหตุผลที่แมชชีนเลิร์นนิงเป็นที่พูดถึงมากกว่า เพราะมันมี inductive bias น้อยกว่าอัลกอริทึมดั้งเดิม จึงรับอคติที่อยู่ในชุดข้อมูลได้ง่ายกว่า
    • ไม่เข้าใจว่าทำไมประเด็นจริยธรรมถึงสำคัญ นี่คือฟีเจอร์ใหม่ของโคเดกเสียง ไม่ใช่ตำราเรียนใหม่ที่จะเอาไปใส่ในหลักสูตรเด็ก ๆ
    • ในฐานะคนที่ใช้ภาษาและสำเนียงอื่น ผมเจอเรื่องแบบนี้บ่อย เจ้าของภาษาไม่มีปัญหา แต่ผู้ช่วยอย่าง Siri กลับไม่เข้าใจว่าผมพยายามจะพูดอะไร
      ก่อน UTF จะถูกใช้แพร่หลาย เว็บไซต์และแอปมักมองข้ามอักขระพิเศษที่ใช้ในภาษาของผม ซึ่งก็คล้ายกัน
      ผมมองว่านี่ใกล้เคียงกับข้อจำกัดทางเทคนิคหรือความไม่รู้ มากกว่าจะเป็นประเด็นจริยธรรม

  • ผมคิดว่าจะเป็นอย่างไรถ้าใส่ สตรีมคำบรรยายข้อความ ไปด้วย ตัวเข้ารหัสใช้แมชชีนเลิร์นนิงแปลงเสียงพูดเป็นข้อความ แล้วตัวถอดรหัสใช้ข้อความนั้นร่วมกับเสียงรอบ ๆ จุดที่เสียงขาด ป้อนเข้า DNN แปลงข้อความเป็นเสียงแบบมีเงื่อนไข
    แบบนั้นเครือข่ายก็ไม่ต้องเรียนรู้ปัญหาที่ยากกว่าอย่างการเติมช่วงที่ขาดแบบเดาสุ่มจากเสียงอย่างเดียว สตรีมข้อความมีบิตเรตต่ำ จึงใส่ redundancy ได้มากเพื่อเพิ่มโอกาสให้ข้อความบางข้อความถูกส่งถึง

    • จริง ๆ แล้วสิ่งที่ DRED ทำก็ไม่ไกลจากข้อเสนอนั้นมากนัก ความต่างคือมันเก็บข้อมูลเกี่ยวกับเสียงพูด/สำเนียงไว้มากกว่า และไม่ต้องมี latency เพิ่มจาก ASR
      สุดท้ายเอาต์พุตก็ถูกสังเคราะห์จากข้อมูลระดับสูงกว่าที่ถูกบีบอัดอย่างมีประสิทธิภาพ

  • เจ๋งมาก ดูเหมือนพวกเขาจัดการกับ ปัญหาการหลอน แล้ว น่าจะน่าสนใจถ้าได้เห็นตัวอย่างที่เมื่อไม่มี redundancy แล้วเกิดการหลอน และถูกแก้ด้วย redundancy

    • packet loss concealment (PLC) ก็เป็น การหลอน แบบหนึ่งไม่ใช่หรือ? ไม่ได้หมายความว่าแย่นะ แต่มันก็คือ Making Shit Up™ ในแบบที่น่าจะเป็นไปได้ทางสถิติ

  • สงสัยว่า Opus เวอร์ชันใหม่นี้ลดช่องว่างกับ xHE-AAC ที่เคยเหนือกว่าในบิตเรตต่ำได้หรือยัง

    • ขึ้นอยู่กับว่ากำลังเข้ารหัสเสียงพูดหรือเพลง

  • ชอบตรงที่ตอนนี้ Opus 1.5 แทบโปร่งใสจริง ๆ สำหรับเสียงพูดแม้ที่ 16kbps และที่ 96kbps ก็ยังดีกว่า MP3 192kbps อยู่
    ในทางกลับกัน xHE-AAC ในช่วง 96–256kbps ดูเหมือนจะแย่กว่า AAC-LC (Apple, FDK) ที่ราว 160kbps จริง ๆ จึงยังให้ความรู้สึกเหมือนทำมาแบบลวก ๆ

  • น่าจะดีถ้ามี profiler หรือการตั้งค่า ที่ช่วยไม่ให้เพิ่ม artifact มากเกินไปเมื่อต้องเข้ารหัสซ้ำจากฟอร์แมตแบบสูญเสียข้อมูลเดิม
    คอลเลกชันขนาดใหญ่จะเจอปัญหานี้ ถ้าเข้าถึงต้นฉบับแบบ lossless ได้ไม่ง่าย
    ถ้ารู้ได้ว่าการสูญเสียคุณภาพเพิ่มเติมมีน้อยที่สุด ผมคงสนใจมากที่จะย้ายไฟล์ mp3, aac, vorbis หลาย ๆ ไฟล์ไปเป็น Opus