Opus 1.5 출시: 머신 러닝으로 업그레이드된 Opus

 (opus-codec.org)
1P by GN⁺ | ★ favorite | 댓글 1개
  • 머신 러닝 기반 기능으로 패킷 손실 은닉, 저비트레이트 음성 품질 향상, DRED 중복 전송을 추가하면서 RFC 6716과의 완전한 호환성 유지
  • 새 ML 기반 기능은 기본 비활성 상태이며, 크기와 CPU 비용 때문에 빌드 시 스위치와 실행 시 스위치를 모두 필요로 함
  • Deep PLC는 --enable-deep-plc로 빌드하고 디코더 복잡도를 5 이상으로 설정해야 동작하며, 디코더에만 영향을 주기 때문에 호환성 영향 없음
  • DRED는 --enable-dred로 활성화하며 --enable-deep-plc도 자동 활성화함; 아직 표준화되지 않았고 Opus 1.5의 DRED는 최종 버전과 호환되지 않지만, 비트스트림의 실험 버전 번호로 불일치를 감지해 DRED 페이로드를 무시함
  • DRED는 최대 1초 분량의 중복 오디오를 한 번에 전송하며, 약 12~32 kb/s 오버헤드로 20ms 패킷을 사실상 50번 전송하는 방식
  • 저비트레이트 음성 향상을 위해 LACE와 NoLACE를 추가했으며, --enable-osce 빌드 후 디코더 복잡도 6에서 LACE, 7 이상에서 NoLACE 활성화
  • LACE와 NoLACE는 현재 프레임 크기 20ms, 대역폭 wideband 이상일 때만 적용되며, 인코더와 독립적인 향상이어서 호환성 영향 없음
  • DRED 사용에는 지터 버퍼와의 더 가까운 통합이 필요하며, Google WebRTC 저장소 포크인 webrtc-opus-ng 패치로 DRED 시험 가능
  • IETF mlcodec 작업 그룹에서 Opus 확장 메커니즘, deep redundancy, speech coding enhancement 표준화 작업 진행
  • AVX2/FMA 지원 및 런타임 감지를 추가해 지원 장비에서 새 DNN 코드와 SILK 인코더가 256비트 SIMD를 사용함
  • AArch64에서 ARMv7 Neon 최적화를 다시 활성화하고, Cortex-A75 이상에서 Arm dot product 확장을 런타임 감지해 새 DNN 코드의 8비트 정수 내적을 가속함
  • 현실적인 패킷 손실 시뮬레이터를 추가했으며, --enable-lossgen 빌드 후 opus_demo에서 -sim-loss <percentage>로 사용 가능

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 이런 코덱의 주된 한계는 CPU와 배터리 수명인데, 여기서는 기계학습을 여기저기 드문드문 적용하고 전통적인 비기계학습 알고리즘과 결합해 CPU 대비 품질의 절충을 잘 잡은 점이 마음에 듦
    예를 들어 저비트레이트/LACE 지원에서 “검증된 포스트필터 아이디어로 시작하고 그 위에 딥러닝 신경망 마법을 딱 필요한 만큼만 뿌렸다”고 함
    핵심은 원시 오디오 샘플을 신경망에 넣지 않는 것임. “오디오 자체는 절대 DNN을 거치지 않는다. 그 결과 DNN 기준으로 작고 복잡도가 매우 낮은 모델이 되어, 구형 휴대폰에서도 실행할 수 있다”는 접근임
    임베디드 알고리즘에는 맞는 방향으로 보이고, 요즘 유행하는 종단간 기계학습에 비하면 꽤 덜 탐구된 영역처럼 보임

    • 기계학습을 아주 영리하게 쓴 사례임. 가장자리에서 보조하게 하고, 기계학습 알고리즘이 우연히 음소나 단어 전체를 지어내는 일은 막고 있음
      기계학습 기반 음성 인식도 일부 벤치마크에서는 더 잘하지만 결과를 환각하는 비슷한 절충이 있음

  • P2P 오디오 스트리밍 라이브러리(https://git.iem.at/cm/aoo/ - 아직 알파)에서 Opus를 주요 코덱 중 하나로 쓰고 있어서 아주 반가운 소식임
    새 기계학습 기능들을 꼭 직접 만져볼 생각임

  • NoLACE로 9kbps에서 이렇게 좋은 음성 품질을 얻는 건 정말 말도 안 되게 대단함

    • 1999년에 큰 음악 스트리밍 스타트업의 리드 개발자였음. 아직 사무실도 없어서 재택근무 중이었는데, 케이블 연결이 끊겨 남은 인터넷은 Nokia 9000 직렬 포트를 통한 9600bps뿐이었음
      프로덕션 코드를 계속 테스트하려고 전체 음악 카탈로그를 8000kbps WMA로 다시 인코딩해서 스트리밍해야 했음
      품질은 좀 아쉬웠음
    • 정말 초기 스트리밍 오디오 코덱인 realaudio 1.0과 비교하면 어떤 소리일지 보고 싶었음
      $ ffmpeg -i female_ref.wav - acodec real_144 female_ref.ra
      지원이 안 될 수 있어서 다시 wav로 바꿔 올려둠: http://9ol.es/female_ref-ra.wav
      이건 90년대 중반 14.4kb/s 전화 접속용 “14.4” 오디오로 여겨졌음. 거의 30년 동안, 실제로는 더 적은 바이트 수에서 얻을 수 있는 품질이 이만큼 좋아졌다는 게 정말 인상적임

  • 오디오 코덱, 음성 합성, 음성 인식이 서로 맞물려 발전하는 방식이 흥미로움. 한쪽의 진전이 보통 다른 쪽의 진전으로 이어짐

  • 궁금한 점은, 흔한 기계학습 윤리 질문들을 다뤘는지임. 구체적으로 남성 음성과 여성 음성에서 알고리즘 성능이 더 좋거나 나쁜지, 언어나 방언에 따라 어떤지, 애초에 음성에만 맞춰진 것인지 아니면 음악이나 새소리에도 잘 작동하는지 궁금함
    그래도 예제는 인상적이고, 이 정도의 알아들을 수 있는 품질이 통화에서 표준이 되길 기대함

    • 논문에 따르면 학습은 “34개 언어와 방언, 900명 이상의 화자를 포함한 TTS 데이터셋 조합에서 나온 16kHz 음성 205시간”으로 했음
      주로 영어로 테스트했지만, 아직 표준화된 것이 아니기에 일찍 공개한 이유 중 하나가 사람들이 직접 써보고 문제를 보고하게 하려는 것임
      남녀 화자 비율은 거의 같음. 다만 코덱은 항상 음높이에 따라 어느 방향으로든 약간의 지각 품질 편향이 생김. 그리고 여기 있는 것은 전부 음성 전용임
    • 중요한 질문이지만, 비기계학습의 손수 조정한 알고리즘에도 비슷한 편향은 쉽게 존재할 수 있음
      그런 경우에도 좋은 매개변수를 찾기 위해 테스트 세트, 때로는 “학습”과 “검증” 세트까지 쓰임. 이런 데이터나, 결정을 내리는 평가자의 귀 모두 편향의 원천이 될 수 있음
      기계학습에서는 근본적으로 데이터 없이는 알고리즘이 동작하지 않기 때문에 편향 질문이 자주 나오지만, 모든 알고리즘은 사람이 설계하고 많은 알고리즘은 매개변수 설정에 데이터를 동원함. 둘 다 편향의 원천이 될 수 있음
      기계학습이 더 유명한 이유는 전통적 알고리즘보다 귀납적 편향이 적어서 데이터셋에 있는 편향을 더 쉽게 받아들이기 때문이라고 봄
    • 왜 윤리 문제가 중요한지 모르겠음. 이건 오디오 코덱의 새 기능이지, 아이들 교육과정에 넣을 새 교재가 아님
    • 다른 언어와 억양을 쓰는 입장에서 이런 일을 자주 겪음. 원어민은 문제가 없는데 Siri 같은 비서가 내가 하려는 말을 못 알아듣는 식임
      UTF가 널리 쓰이기 전에는 웹사이트와 앱이 내 언어에서 쓰는 특수문자를 무시하던 것도 비슷했음
      이걸 윤리 문제라기보다는 기술적 한계나 무지에 가깝다고 봄

  • 텍스트 자막 스트림을 함께 넣으면 어떨까 싶음. 인코더는 기계학습으로 음성을 텍스트로 변환하고, 디코더는 그 텍스트와 오디오 끊김 주변의 오디오를 함께 써서 조건부 텍스트-음성 변환 DNN에 넣을 수 있음
    그러면 네트워크가 오디오만 보고 끊긴 구간을 맹목적으로 보간하는 더 어려운 문제를 배울 필요가 없어짐. 텍스트 스트림은 낮은 비트레이트라서, 특정 텍스트 메시지가 수신될 가능성을 높이기 위해 상당한 중복성을 넣을 수도 있음

    • 실제로 DRED에서 하는 일이 그 제안과 그리 멀지 않음. 차이는 음성/억양에 대한 정보를 더 많이 유지하고, ASR이 추가했을 지연 시간이 필요 없다는 점임
      결국 출력은 더 높은 수준의, 효율적으로 압축된 정보로부터 합성됨

  • 아주 멋짐. 환각 문제를 다룬 것처럼 보임. 중복성이 없을 때 환각이 생기고, 중복성으로 고쳐지는 예제를 보면 흥미로울 듯함

    • 패킷 손실 은닉(PLC)도 일종의 환각 아닌가? 나쁘다는 뜻은 아니고, 통계적으로 그럴듯한 방식으로 Making Shit Up™ 하는 것이긴 함

  • 이번 새 Opus 버전이 낮은 비트레이트에서 우월했던 xHE-AAC와의 격차를 좁혔는지 궁금함

    • 음성을 인코딩하느냐 음악을 인코딩하느냐에 따라 다름

  • Opus 1.5가 이제 음성에서는 16kbps에서도 사실상 투명하고, 96kbps에서도 192kbps MP3보다 여전히 낫다는 점이 좋음
    반면 xHE-AAC는 96~256kbps 구간이 AAC-LC(Apple, FDK)의 약 160kbps보다도 실제로 나빠 보여서 여전히 대충 나온 느낌임

  • 기존 손실 형식을 다시 인코딩할 때 아티팩트를 너무 많이 추가하지 않도록 도와주는 프로파일러나 설정이 있으면 어떨까 싶음
    큰 컬렉션은 무손실 원본에 쉽게 접근할 수 없으면 이 문제에 부딪힘
    추가 품질 손실이 최소라는 걸 알 수 있다면, 여러 mp3, aac, vorbis 파일을 Opus로 옮기는 데 큰 관심이 있음

답변달기