Phát hành Opus 1.5: Opus được nâng cấp bằng machine learning

 (opus-codec.org)
1 điểm bởi GN⁺ 2024-03-05 | 1 bình luận | Chia sẻ qua WhatsApp
  • Giữ tương thích hoàn toàn với RFC 6716 đồng thời bổ sung các tính năng dựa trên machine learning như che giấu mất gói, cải thiện chất lượng thoại ở bitrate thấp và truyền dư thừa DRED
  • Các tính năng mới dựa trên ML mặc định bị tắt, và do kích thước cùng chi phí CPU nên cần cả công tắc khi build lẫn công tắc lúc chạy
  • Deep PLC cần build với --enable-deep-plc và đặt độ phức tạp của bộ giải mã từ 5 trở lên mới hoạt động; vì chỉ ảnh hưởng đến bộ giải mã nên không ảnh hưởng đến tính tương thích
  • DRED được bật bằng --enable-dred và cũng tự động bật --enable-deep-plc; hiện chưa được chuẩn hóa, và DRED của Opus 1.5 không tương thích với phiên bản cuối cùng, nhưng sẽ phát hiện khác biệt bằng số phiên bản thử nghiệm của bitstream để bỏ qua payload DRED
  • DRED truyền tối đa 1 giây âm thanh dư thừa trong một lần, theo cách về thực chất là truyền gói 20ms tới 50 lần với overhead khoảng 12~32 kb/s
  • Để cải thiện thoại ở bitrate thấp, đã bổ sung LACE và NoLACE; sau khi build với --enable-osce, LACE được kích hoạt ở độ phức tạp bộ giải mã 6, còn NoLACE từ 7 trở lên
  • LACE và NoLACE hiện chỉ áp dụng khi kích thước frame là 20ms và băng thông từ wideband trở lên; đây là cải thiện độc lập với bộ mã hóa nên không ảnh hưởng đến tính tương thích
  • Việc sử dụng DRED cần tích hợp chặt chẽ hơn với jitter buffer, và có thể thử nghiệm DRED bằng bản vá của webrtc-opus-ng, một fork của kho Google WebRTC
  • Nhóm làm việc IETF mlcodec đang tiến hành chuẩn hóa cơ chế mở rộng Opus, deep redundancy và speech coding enhancement
  • Đã bổ sung hỗ trợ AVX2/FMA và phát hiện lúc chạy để mã DNN mới cùng bộ mã hóa SILK dùng SIMD 256-bit trên thiết bị được hỗ trợ
  • Trên AArch64, đã kích hoạt lại tối ưu hóa ARMv7 Neon và phát hiện lúc chạy phần mở rộng Arm dot product trên Cortex-A75 trở lên để tăng tốc tích vô hướng số nguyên 8-bit của mã DNN mới
  • Đã bổ sung trình mô phỏng mất gói thực tế hơn; sau khi build với --enable-lossgen, có thể dùng trong opus_demo bằng -sim-loss <percentage>

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-03-05
Ý kiến trên Hacker News

  • Hạn chế chính của các codec kiểu này là CPU và thời lượng pin, nên tôi thích cách họ áp dụng học máy rải rác ở vài chỗ và kết hợp với các thuật toán truyền thống không dùng học máy để đạt được sự đánh đổi tốt giữa chất lượng và CPU
    Ví dụ, về hỗ trợ bitrate thấp/LACE, họ nói rằng “bắt đầu từ một ý tưởng post-filter đã được kiểm chứng rồi rắc vừa đủ phép màu mạng nơ-ron học sâu lên trên”
    Điểm cốt lõi là không đưa mẫu âm thanh thô vào mạng nơ-ron. Cách tiếp cận là: “Bản thân âm thanh tuyệt đối không đi qua DNN. Kết quả là một mô hình nhỏ theo chuẩn DNN và có độ phức tạp rất thấp, có thể chạy cả trên điện thoại đời cũ”
    Có vẻ đây là hướng đúng cho các thuật toán nhúng, và so với học máy đầu-cuối đang thịnh hành hiện nay thì có vẻ là một lĩnh vực còn khá ít được khai phá

    • Đây là một ví dụ dùng học máy rất khôn khéo. Nó chỉ hỗ trợ ở phần rìa, đồng thời ngăn thuật toán học máy vô tình bịa ra cả âm vị hoặc cả từ
      Nhận dạng giọng nói dựa trên học máy cũng làm tốt hơn trong một số benchmark, nhưng có sự đánh đổi tương tự là kết quả có thể bị ảo giác

  • Vì thư viện streaming âm thanh P2P (https://git.iem.at/cm/aoo/ - vẫn còn alpha) đang dùng Opus như một trong các codec chính, nên đây là tin rất đáng mừng
    Tôi nhất định sẽ tự tay thử các tính năng học máy mới này

  • Đạt được chất lượng giọng nói tốt như vậy ở 9kbps với NoLACE thật sự là ấn tượng đến khó tin

    • Năm 1999, tôi là lead developer của một startup streaming nhạc lớn. Khi đó chúng tôi còn chưa có văn phòng nên tôi làm việc tại nhà, nhưng kết nối cáp bị mất, Internet còn lại chỉ là 9600bps qua cổng nối tiếp Nokia 9000
      Để tiếp tục kiểm thử code production, tôi đã phải mã hóa lại toàn bộ catalog nhạc sang WMA 8000kbps rồi stream
      Chất lượng thì hơi đáng tiếc
    • Tôi muốn xem nó sẽ nghe ra sao nếu so với realaudio 1.0, một codec âm thanh streaming cực kỳ đời đầu
      $ ffmpeg -i female_ref.wav - acodec real_144 female_ref.ra
      Vì có thể không được hỗ trợ nên tôi đã đổi lại thành wav rồi đăng lên đây: http://9ol.es/female_ref-ra.wav
      Đây từng được xem là âm thanh “14.4” cho kết nối quay số 14.4kb/s vào giữa thập niên 90. Thật sự ấn tượng khi sau gần 30 năm, chất lượng có thể đạt được với số byte thực tế còn ít hơn đã cải thiện đến mức này

  • Cách codec âm thanh, tổng hợp giọng nói và nhận dạng giọng nói cùng thúc đẩy lẫn nhau phát triển thật thú vị. Tiến bộ ở một phía thường kéo theo tiến bộ ở phía khác

  • Điều tôi thắc mắc là liệu họ đã xử lý các câu hỏi đạo đức thường gặp về học máy chưa. Cụ thể là thuật toán hoạt động tốt hơn hay kém hơn với giọng nam và giọng nữ, với các ngôn ngữ hay phương ngữ khác nhau thì sao, và ngay từ đầu nó chỉ được tối ưu cho giọng nói hay cũng hoạt động tốt với nhạc hoặc tiếng chim
    Dù vậy, các ví dụ rất ấn tượng, và tôi hy vọng mức chất lượng đủ nghe rõ như thế này sẽ trở thành tiêu chuẩn trong các cuộc gọi

    • Theo bài báo, việc huấn luyện dùng “205 giờ giọng nói 16kHz từ tổ hợp các bộ dữ liệu TTS gồm 34 ngôn ngữ và phương ngữ, hơn 900 người nói”
      Họ chủ yếu kiểm thử bằng tiếng Anh, nhưng vì nó chưa được chuẩn hóa nên một trong những lý do công bố sớm là để mọi người tự dùng thử và báo cáo vấn đề
      Tỷ lệ người nói nam/nữ gần như ngang nhau. Tuy nhiên codec luôn có một chút thiên lệch chất lượng cảm nhận theo hướng nào đó tùy theo cao độ giọng. Và tất cả những gì ở đây đều chỉ dành cho giọng nói
    • Đây là câu hỏi quan trọng, nhưng các thuật toán không dùng học máy và được tinh chỉnh thủ công cũng rất dễ có thiên lệch tương tự
      Trong những trường hợp đó, người ta cũng dùng tập kiểm thử, đôi khi cả tập “huấn luyện” và “xác thực”, để tìm tham số tốt. Những dữ liệu này, hoặc đôi tai của người đánh giá đưa ra quyết định, đều có thể là nguồn tạo ra thiên lệch
      Với học máy, câu hỏi về thiên lệch thường được nêu ra vì về căn bản thuật toán không hoạt động nếu không có dữ liệu, nhưng mọi thuật toán đều do con người thiết kế và nhiều thuật toán dùng dữ liệu để thiết lập tham số. Cả hai đều có thể là nguồn thiên lệch
      Tôi nghĩ lý do học máy nổi tiếng hơn về chuyện này là vì nó có thiên lệch quy nạp ít hơn các thuật toán truyền thống, nên dễ hấp thụ các thiên lệch có trong bộ dữ liệu hơn
    • Tôi không hiểu tại sao vấn đề đạo đức lại quan trọng ở đây. Đây là tính năng mới của một codec âm thanh, chứ không phải giáo trình mới để đưa vào chương trình học của trẻ em
    • Là người dùng ngôn ngữ và giọng khác, tôi thường gặp chuyện như vậy. Người bản ngữ thì không có vấn đề, nhưng trợ lý như Siri lại không hiểu điều tôi muốn nói
      Trước khi UTF được dùng rộng rãi, các website và ứng dụng cũng từng phớt lờ các ký tự đặc biệt dùng trong ngôn ngữ của tôi, tương tự như vậy
      Tôi xem đó là giới hạn kỹ thuật hoặc sự thiếu hiểu biết hơn là vấn đề đạo đức

  • Tôi nghĩ nếu đưa kèm một luồng phụ đề dạng văn bản thì sao. Encoder dùng học máy để chuyển giọng nói thành văn bản, còn decoder có thể dùng cả văn bản đó và âm thanh xung quanh chỗ bị ngắt để đưa vào DNN chuyển văn bản thành giọng nói có điều kiện
    Như vậy mạng không cần học bài toán khó hơn là chỉ nhìn âm thanh rồi nội suy mù quãng bị mất. Luồng văn bản có bitrate thấp, nên cũng có thể thêm khá nhiều dư thừa để tăng khả năng một thông điệp văn bản cụ thể được nhận

    • Thực ra những gì DRED làm không quá xa đề xuất đó. Khác biệt là nó giữ lại nhiều thông tin hơn về giọng nói/ngữ điệu, và không cần độ trễ mà ASR sẽ thêm vào
      Cuối cùng, đầu ra được tổng hợp từ thông tin ở mức cao hơn và được nén hiệu quả

  • Rất hay. Có vẻ họ đã xử lý vấn đề ảo giác. Sẽ rất thú vị nếu xem các ví dụ về việc ảo giác xuất hiện khi không có dư thừa, rồi được sửa bằng dư thừa

    • Che giấu mất gói tin (PLC) chẳng phải cũng là một dạng ảo giác sao? Không có ý nói là xấu, nhưng về bản chất vẫn là Making Shit Up™ theo cách có vẻ hợp lý về mặt thống kê

  • Tôi tò mò liệu phiên bản Opus mới này có thu hẹp khoảng cách với xHE-AAC, vốn vượt trội ở bitrate thấp, hay không

    • Còn tùy là mã hóa giọng nói hay mã hóa nhạc

  • Tôi thích việc Opus 1.5 giờ đây về giọng nói thì gần như trong suốt ngay cả ở 16kbps, và ở 96kbps vẫn tốt hơn MP3 192kbps
    Trong khi đó xHE-AAC ở dải 96~256kbps thực tế còn có vẻ tệ hơn AAC-LC (Apple, FDK) khoảng 160kbps, nên vẫn cho cảm giác được làm khá qua loa

  • Tôi nghĩ sẽ hay nếu có profiler hoặc thiết lập giúp không thêm quá nhiều artifact khi mã hóa lại các định dạng lossy hiện có
    Các bộ sưu tập lớn sẽ gặp vấn đề này nếu không dễ truy cập được bản gốc lossless
    Nếu biết chắc phần suy giảm chất lượng bổ sung là tối thiểu, tôi sẽ rất quan tâm đến việc chuyển nhiều file mp3, aac, vorbis sang Opus