나무모에 미러 (일반/밝은 화면)
최근 수정 시각 : 2024-10-21 18:19:13

Opus(오디오 코덱)

Ogg Opus에서 넘어옴
파일:Xiph-Logo.svg
컨테이너 비디오 오디오
무손실 음악 겸용 음성
Ogg Theora FLAC Vorbis Opus Speex

🎵 오디오 코덱
{{{#!wiki style="margin: 0 -10px -5px; min-height: 26px"
{{{#!folding [ 펼치기 · 접기 ]
{{{#!wiki style="margin: -6px -1.5px -13px"
<colbgcolor=#555>손실
압축
<colbgcolor=#555><colcolor=#fff>일반MP1 · MP2 · MP3 · mp3PRO · AAC · Musepack · WMA · Vorbis · Opus · USAC
음성 특화AMR-NB · AMR-WB · AMR-WB+ · WMA Voice · Speex · Opus · Codec 2 · EVS · Lyra
다중채널 특화AC-3 · SDDS · DTS · AC-4
블루투스SBC · aptX · AAC · LDAC · SSC(Samsung Seamless Codec · Samsung Scalable Codec) · LC3
무손실 압축FLAC · ALAC · APE · TAK · WMA Lossless · TTA · WavPack
무손실 무압축PCM (WAV · AIFF)
관련 문서: MIDI · DSD
관련 틀: 그래픽 · 오디오 · 비디오
}}}}}}}}} ||
<colbgcolor=#484647><colcolor=#ffffff> 파일:Opus-Logo.svg
Opus
개발 Xiph.org 재단
표준화 IETF mlcodec working group[1]
출시 2012년 9월 11일
버전 1.5.2 / 2024년 4월 12일[2]
분류 오디오 코덱, 손실 압축 포맷
확장자 .opus, .ogg[3], .caf[4]
라이선스 BSD 라이선스[5]
홈페이지 공식 홈페이지

1. 개요2. 개발 과정3. 특징4. 사양
4.1. SILK4.2. CELT
5. 장점6. 단점
6.1. 현재 해결된 단점
7. 현황8. 음질 평가
8.1. 음성(SILK)8.2. 음악(CELT)
8.2.1. 고음질 한계8.2.2. 대역폭 한계
8.2.2.1. 낙관론8.2.2.2. 비관론
8.2.3. 모노 다운믹스 문제8.2.4. 저비트레이트 한계
8.3. 5.1/7.1채널

[clearfix]

1. 개요

Xiph.Org가 주도하여, Xiph.Org 재단의 CELT 코덱과 Skype의 VOIP용 SILK 코덱을 통합해 만든 Speex를 계승한 코덱이다. 로열티 없는 무료 오픈소스 손실 압축 오디오 코덱이다.

초기에는 VOIP용 코덱으로 개발되었지만, 고음질에서도 뛰어난 성능을 보여 '괴물 코덱'으로 불리기도 했다. 그러나 본래 개발 목적이 고음질 보관이 아닌 만큼, 실제로 들리는 음질은 우수할지라도 고의로 노이즈를 추가하거나 가청 주파수 이상을 잘라내는 등 여러 가지 트릭을 사용했기 때문에 고음질 보관용 코덱으로는 부적합하다는 평가를 받고 있다.

2024년 현재, VOIP 서비스[6]와 동영상 스트리밍[7]에서 많이 사용되고 있으며, 2018년 MP4 컨테이너에서 Opus 음성 코덱이 지원되기 시작한 이후로 동영상 파일 분야로도 점차 발을 넓혀가고 있는 중이다.

2019년 4월 1.3.1 버전 이후로 한동안 업데이트가 없었지만, 2023년부터 갑자기 개발이 활발해지며 동년 1.4 버전, 2024년 1.5 버전으로 메이저 업데이트가 빠르게 진행되었다. 마이너 릴리즈를 제외하면, 사실상 2018년 1.3 버전 이후 5년 동안 업데이트가 없었기 때문에 후술된 내용 대부분이 1.3 버전을 기준으로 기술되어 있다. 따라서 2024년 4월, 1.5.2 버전 기준으로는 일부 내용이 틀릴 수 있으니 주의가 필요하다.

2. 개발 과정

참고 글

2000년대 중반만 하더라도 오디오 코덱은 저지연 저음질 음성 및 고지연 고음질 음악 코덱으로 양분되어 있었다. 2007년부터 Xiph.Org[8] 재단에서는 지연 시간이 아주 낮으면서도 고음질을 목표로 한 CELT 코덱을 개발하기 시작했으며, 이와 별개로 2009년부터 Skype에서 고효율 음성용 코덱 SILK를 개발하고 있었다. 이 두 코덱을 Xiph.Org에서 통합함으로써 32kbps에서 가청 주파수를 온전히 커버하는(Fullband, 최대 20kHz) 고음질 음성 코덱이 만들어졌다. 2011년 2월 15일부터 베타 버전이 나오다가 2012년 9월 11일 1.0 버전이 정식 출시되었다. #1 #2

3. 특징

2012년, IETF(Internet Engineering Task Force)에서 표준화되었다.

스펙도 완전히 공개되어 있다. RFC6716

Speex를 계승하는 코덱이며 VoIP 용도로 개발된 코덱이지만 음악의 저장이나 스트리밍에서도 탁월한 성능을 발휘한다.

Xiph 위키에서도 다음과 같이 서술되어 있다. #
Does Opus make all those other lossy codecs obsolete?

Yes.

From a technical point of view (loss, delay, bitrates, ...) Opus renders Speex obsolete and should also replace Vorbis and the common proprietary codecs too (e.g. AAC, MP3, ...).
Opus가 다른 모든 손실 코덱을 구식의 한물간 코덱으로 만들까요?

예.

기술적인 관점에서(손실, 지연, 비트레이트 등) Opus는 Speex를 구식 코덱으로 만들고, Vorbis와 다른 독점 코덱(예: AAC, MP3 등)도 대체할 겁니다.

Opus의 주요 경쟁 코덱은 회사에서 쓰이는 영상회의, 인터넷 전화, 음성 채팅 등에 쓰이는 Speex, G.711, G.729 등의 VoIP용 코덱이다. 예를 들자면 엑스박스 라이브, 팀스피크, 구글 지도, Siri 등이 있다(이상 모두 Speex 코덱 적용). AMR-WBVorbis, AAC, MP3 등과 비교되는 것은 개발하면서 이것저것 넣다 보니 코덱이 뛰어나서 여기저기 쓰임새가 있는 것일 뿐 주요 경쟁 상대는 아니다.
파일:Opus quality.svg
Opus 코덱의 우수성을 자랑하는 이미지[9]
이 그래프에서는 AAC(LC)와 HE-AAC가 구분되어 있지 않음을 감안해야 한다. 또한 48kbps 이하의 경우, 해당 그래프에서는 HE-AAC가 효율이 더 좋지만 2014년 당시 최신 버전인 1.1 기준이며 #1, #2, #3와 같이 2017년에 출시된 1.2 버전 이후로는 HE-AAC 수준으로 음질이 개선되었음을 알 수 있다.

음질이 아닌 실시간 통신에서는 이야기가 조금 다르다. AMR-NB/WB 계열이 레이턴시에서 제일 좋으며, 그 다음이 Opus, 그 밑으로 AAC 같은 일반 코덱 계열이 따라간다. 이는 개발 의도에서부터 갈리는 점인데, AMR 계열 코덱은 SDH라 불리는 유/무선 전화전용망에서 쓰이는 것을 전제하여 만들어진 코덱이고, Opus나 Speex, G.729 같은 VOIP용 코덱은 인터넷망에서 쓰이는 통화용으로 만들어진 코덱이다. 따라서 AMR보다는 레이턴시에 둔감하게 설계되었다.[10] HE-AAC는 레이턴시가 크게 중요하지 않은 스트리밍용 코덱이다. 한마디로, AMR, Opus, HE-AAC는 저 비트레이트에서 레이턴시냐 음질이냐를 취사선택해서 만든 것이라는 이야기다.

4. 사양

4.1. SILK

음성용. 2009년부터 개발이 시작되었으며 Skype에서 사용하고 있다.

4.2. CELT

음악용. 2007년부터 개발이 시작되었다.

21개의 밴드로 나누어져 있다.(0~200, 200~400 ... 15600~20000) #
0 - 200 - 400 - 600 - 800 - 1000 - 1200 - 1400 - 1600 - 2000 - 2400 - 2800 - 3200 - 4000 - 4800 - 5600 - 6800 - 8000 - 9600 - 12000 - 15600 - 20000 (Hz)

통합 이전에는 44.1kHz와 48kHz를 모두 지원했지만 2011년 Opus로 통합된 후로는 48kHz만 지원한다.

5. 장점

파일:external/listening-test.coresv.net/nonblocked_means_all2.png
△ Hydrogenaudio에서 실시한 공개 블라인드 테스트 비교 결과. 여기서 FAAC는 테스트의 유효성을 평가하기 위한 것이다. 기존에 유튜브에서 사용했던 아주 끔찍한 코덱이 FAAC이다. 비트레이트가 낮게 설정되어 있는 점을 감안하고 볼 것.

6. 단점

6.1. 현재 해결된 단점

7. 현황

아직 나온 지 얼마 안 돼서 지원하는 플레이어가 그리 많은 편은 아니지만, 차츰 늘어나는 추세다. 유튜브에서는 동영상 재생 및 실시간 스트림에 쓰이고 있다. 2016년 중후반 동영상 코덱을 VP9로 변경하면서 사운드 코덱도 Opus로 변경되었는데, 예전에 비해 매우 좋은 음질을 들을 수 있게 되었다. 비트레이트는 기본적으로 50·70·160 kbps를 사용하고 있으나 VBR이므로 비트레이트가 일정하지 않다.[16] 특히 160 kbps의 경우 2022년 2월 말부터 4월까지 KBS Kpop 채널에 올라온 영상 1000개를 분석한 글에 따르면 평균 0.12 Mbps, 최대 0.14 Mbps에 불과하다. 참고로 Opus 160 kbps의 음질은 MP3 256 kbps, Vorbis 192 kbps와 비슷한 수준이다.

음성용 중에서도 원래 개발 용도인 VoIP에서는 디스코드스팀에서 음성 코덱으로 쓰이는 등 잘나가고 있다. 하지만 VoIP를 제외하면 사용되는 경우는 많지 않다. 특히 어학용, 오디오북, 라디오 방송 등으로는 24~32 kbps 정도에서 용량 대비 효율이 매우 높지만 여전히 MP3를 사용하고 있다.

2010년대 중반까지는 지원하는 컨테이너가 적었으나[17], 2021년 이후로는 MP4, MKV, Ogg(또는 opus), WebM 이 네 가지의 컨테이너에서 지원되어 호환성도 낮지 않다. 허나 유튜브를 제외하고 영상에서는 opus는 잘 쓰이지 않는데, 고 비트레이트에서 AAC와의 비교에서 성능상(평가 그래프상) 큰 갭이 발생하지 않기에 코덱 선택에 기존 추세인 AAC를 따르는 경향이 있으며, 저 비트레이트에서는 HE-AAC보다 Opus가 다소 우월하나 애초 음악은 영상과 달리 대역폭을 아끼지 않는 경향이 강해서 절실한 경우[18]가 아니면 MP4, MKV 등의 로컬 파일용으로는 Opus, HE-AAC 둘 다 잘 쓰이지 않는다. 영상은 화질이 떨어져도 거부감이 덜한 반면, 음악은 음질이 떨어지면 거부감을 불러 일으키는 경향이 강하기 때문이다.[19] 음성은 저음질에 관대한 편이나 이미 존재하는 파일을 Opus 32kbps와 같은 저용량 고효율 포맷으로 변환하는 경우가 드물다.

DAP를 비롯한 MP3 플레이어에서는 거의 지원하지 않으며, 음원 사이트에서도 이 형식으로 판매하지 않는다.

안드로이드 폰에서도 Opus 코덱 재생은 대략 갤럭시 S6, LG G4 시점부터 지원하고 있지만, 음악파일(컨테이너, 확장자)로서 인식은 그 이후에나 가능하였다. 안드로이드 누가부터 안드로이드 파이까지는 확장자가 *.opus이면 음악 오디오 파일로 인식하지 못하고 *.ogg로 바꾸어 주어야 음악 플레이어들이 음악 파일로 인식한다.[20][21] 안드로이드 10부터는 *.opus와 *.mp4 확장자도 지원한다.

반대로 MP3Tag 등 일부 메타정보 처리 윈도 소프트웨어에서는 Ogg 컨테이너에 Opus 코덱으로 인코딩된 파일은 확장자가 *.ogg이면 메타정보를 인식하지 못하고 확장자를 *.opus로 해야 제대로 태그를 읽는 등 아직 혼란이 있다.

Windows에서는 Windows 10 1607 버전부터 .MKV 확장자를, 1709 버전부터 *.ogg 확장자를, 1809 버전부터 *.webm 확장자를, 1903 버전부터 *.opus 확장자를 영화 및 TV, Groove 음악 앱에서 지원하고 있다. 물론 팟플레이어 등의 서드 파티 프로그램에서는 2010년대 초중반부터 지원하고 있다. 곰오디오도 정확한 시점은 불명이나 최신 버전 기준으로 지원하고 있다. 하지만 알송은 v3.5 기준으로 Opus를 아예 지원하지 않는다. *.opus 확장자는 아예 인식하지 못하며, *.ogg 확장자는 올바르지 않은 파일이라며 재생이 안 된다. 즉 알송에서 *.ogg 확장자는 Vorbis만을 지원한다.
음악 플레이어(윈도우)
foobar2000 2012년 8월 17일 v1.1.14
AIMP 2012년 11월 16일 v3.20
곰오디오 불명 불명
동영상 플레이어(윈도우)
MPC-BE 2012년 9월 26일 v1.0.3.1
팟플레이어 2014년 1월 15일 v1.5.44407
KMPlayer 2014년 10월 7일 v3.9.1.129
VLC 2015년 2월 27일 v2.2.0
곰플레이어 2015년 3월 30일 v2.2.69.5228

애플 기기에서는 2017년 출시된 macOS High SierraiOS 11부터 파일 앱에서 FLAC, Opus 재생을 지원하고 있지만#, Opus의 경우 한동안 CAF(Core Audio Format) 컨테이너만 지원했다. Opus 코덱에 CAF 컨테이너를 사용한 경우는 거의 없다시피 하기에 사실상 지원하지 않는다고 봐도 무방했다. 물론 foobar2000과 같은 서드 파티 앱을 사용하면 *.ogg나 *.opus 확장자여도 재생이 가능하다. 2020년대 들어 기본 지원 범위가 넓어졌는데 macOSmacOS Monterey부터 WebM 컨테이너를, macOS Sonoma부터 MP4 컨테이너를 지원하고 있다. iOS의 경우 iOS 17부터는 확장자가 *.opus나 *.mp4여도 재생할 수 있다.

Opus는 오디오 압축 코덱 표준이지 메타정보를 포함한 파일 컨테이너 표준이 아니기 때문에 현재로서는 다른 컨테이너 표준을 차용해서 써야 하는 데 보통 오디오용 컨테이너로 쓰이는 Ogg 컨테이너를 많이 쓰는 편이다. 메타정보도 Ogg 컨테이너의 표준인 Vorbis comment를 쓰는 경우가 많다. Vorbis와 마찬가지로 Ogg 컨테이너 스펙상 앨범아트를 지원하나#, 대부분의 프로그램에서 앨범 커버 사진 등 앨범 아트를 제대로 지원하지 못하고 있다. 이는 애플의 AAC 코덱을 쓰는 mp4(mp4a) 컨테이너도 비슷하다. MP4 컨테이너는 iTunes를 제외하고는 LameXP 등 대부분의 오디오 인코딩 소프트웨어가 앨범 아트 처리가 안 되고 있다. 그래서 앨범 아트가 포함된 MP3 파일을 AAC, Vorbis, Opus로 인코딩하면 보통 앨범 아트를 포함하고 있지 않다. 가장 대중화된 MP3 포맷의 경우 대부분의 인코더/플레이어 양쪽에서 다 앨범 아트를 원활하게 지원하고 있다. (2019년 시점의 서술)

MP4/M4A 파일 지원이 보편화된 현 시점(2022년)에서는 메타데이터 관리를 고려하는 경우라면[22] 저 비트레이트[23] 음성/음악을 opus코덱으로 인코딩하여 MP4 컨테이너에 넣은 후 M4A로 확장자를 바꿔주는 것이 편하다.[24]

Nintendo Switch 게임들 중 슈퍼 스매시브라더스 얼티밋, 제노블레이드 크로니클스 등이 이 코덱을 사용한다.

PlayStation 5의 게임 플레이 녹화를 WebM으로 선택하면 영상으로 구글 VP9를, 음성으로 이 코덱을 사용한다.

웹 브라우저에서의 호환성은 다음과 같다. #
Firefox 15 이상 2012년 7월 17일
Chrome 33 이상 2014년 2월 21일
Opera 20 이상 2014년 5월 4일
Edge 14 이상 2016년 8월 2일
삼성 인터넷 5 이상 2016년 12월 16일
Safari 11 이상[25] 2017년 9월 19일

8. 음질 평가

같은 단체에서 개발한 VorbisSpeex와 비교하는 경우는 매우 드물다.

8.1. 음성(SILK)

1.3.1 버전 기준, 12kbps부터 시작해서 저비트레이트로 갈수록 효율이 급감하며 비상용에 가까워진다. 12kbps부터는 AMR-WB+EVS보다, 8kbps부터는 VoLTE용으로 사용되는 AMR-WB보다, 6kbps부터는 Speex, WMA Voice, 2G/3G 음성 통화용 코덱으로 사용되는 AMR-NB보다도 음질이 떨어진다.

8kbps에서 대역폭 기본값은 4kHz인데, --set-ctl-int 4004=1102 --set-ctl-int 4008=1102를 입력하여 6kHz로 바꾸어 주면 음질이 살짝 좋아진다. 반면 16~48kbps에서는 효율이 매우 높은데, 개인적으로 용량을 줄인다면 순수 음성 컨텐츠는 24~32kbps, 배경음악이 있다면 32~48kbps 정도가 적당하다.

2024년 3월 출시된 1.5 버전에서 LACE, NoLACE 방식의 머신 러닝이 도입되며 저 비트레이트에서의 음질이 향상되었다. 8kHz(Wideband) 대역폭 기준, 머신 러닝이 적용되지 않은 Baseline 12kbps보다 NoLACE 9kbps가 음질이 더 좋으며, NoLACE 6kbps는 Baseline 9kbps에 근접한다.# 10~12kbps에서 12kHz 대역폭을 사용해도 무방하며 8~13kbps에서 EVS와 음질이 비슷해졌다.

몇 가지 유의 사항이 있다. 1.5 버전이 출시된 지 얼마 되지 않은 데다 기본적으로 비활성화되어 있으며 활성화에 특수한 조건이 필요하다.[26] 때문에 대다수 소프트웨어 및 앱에서는 지원하지 않아 상술한 음질 향상 효과가 없다. 일단 이곳에서 NoLACE가 활성화된 Windows 바이너리를 다운받을 수 있다. 또한 대역폭이 8kHz 이상이어야 머신 러닝이 작동하는데, 비트레이트가 8kbps 이하면 기본 대역폭이 4kHz이므로 작동하지 않는다. 따라서 --set-ctl-int 옵션을 사용하여 대역폭을 바꿔줘야 한다.

5kbps에서는 4kHz 대역폭을 사용해야 하므로 머신 러닝을 사용할 수 없지만[27] --framesize 60을 입력하면 음질이 소폭 좋아진다.

8.2. 음악(CELT)

VBR > CVBR > CBR 순으로 효율이 높으며, 좁게는 64~96kbps, 넓게는 48~160kbps 정도에서 좋은 효율을 보인다.

8.2.1. 고음질 한계

본질적인 Opus 코덱의 목적은 실시간 인터넷 음성 통신과 같은 저비트레이트 상황에서의 극한의 효율성을 추구하며 개발된 포맷이기 때문에, 고비트레이트로 갈수록 음질의 효율성이 대단히 떨어진다. 쉽게 말해 AAC-LC 320 kbps와 Opus 320 kbps의 음질을 기계적인 음원 분석으로 비교했을 때 AAC-LC 320 kbps 쪽이 조금 더 낫다는 것이다. 애초에 비트레이트가 올라가면 압축을 덜 한다는 뜻이므로, 기존 포맷으로도 좋은 음질을 내기 쉽다는 점에서 Opus 같은 최신 코덱의 필요성이 줄어들기 때문에 당연한 일이기도 하다. 320~384 kbps 정도 되면 MP2조차도 음질이 좋다는 평을 받는다.

문서 처음에 언급한 Opus 코덱의 우수성을 보여 주는 이미지에서도 128 kbps에서는 AACVorbis는 물론 MP3조차도 Opus를 거의 따라잡는 듯한 그래프를 보여주기도 한다. 물론 자세히 보면 MP3는 나머지 그래프들과 약간 갭이 있으므로 떨어지는 결과로 볼 수도 있다. 2014년 실시된 hydrogenaud.io의 한 유저의 블라인드 테스트 결과를 보면 여기서도 128 kbps에서는 AAC-LC, Vorbis, Opus의 차이를 보기 힘들다. 링크된 테스트 결과의 요약을 보면 HE-AAC v2는 32 kbps, HE-AAC v1은 64~80 kbps, AAC-LC는 80 kbps 이상, Opus는 56 kbps 이상에서 좋은 효율을 보인다고 한다. 여기서 MP3는 128 kbps에서도 차이 나게 처지는 결과가 나왔다. 참고로 테스트 결과를 잘 보면 USAC(Unified Speech and Audio Coding)라고 Opus보다 더한 괴물이 있는데, MPEG에서 MPEG-D part 3의 일환으로 개발한 가장 최신 코덱이라서 그렇다[28]. 다만 64 kbps 이상에서는 Opus와 음질이 비슷하다.
파일:MP3 128k.png
파일:MP3 128k to Vorbis 96k.png
MP3 128 kbps 음원을 Vorbis 96 kbps로 재인코딩
파일:MP3 128k to Opus 96k.png
파일:MP3 128k to Opus 128k.png
파일:MP3 128k to Opus 160k.png
각각 Opus 96, 128, 160 kbps[29]로 재인코딩

특히, Opus 코덱의 알고리즘상 임의적으로 원본에 없던 얕은 화이트 노이즈를 끼워 넣는 방법으로 압축률을 높이고 음질을 최적화하는 특성이 있어서 음악 감상용으로는 적절하지 않다는 의견이 있으며, 16~20 kHz 구간에서 이러한 특성이 크게 드러난다는 분석이 있다. 위와 같이 대역폭이 16 kHz 정도인 MP3 128 kbps 음원을 재인코딩하는 경우 명확히 드러난다. 이러한 특성은 160 kbps 정도만 되어도 매우 약해지지만 160 kbps는 좀 애매하고 192 kbps부터는 AAC에 밀려서 별로 사용되지 않는다. 384~512 kbps 정도의 아주 높은 비트레이트에서도 매우 약하지만 마찬가지이다.

다만 이 화이트 노이즈가 사람의 귀로 인지 가능한 것인지는 논란이 있을 수 있으므로, ABX 테스트 등으로 간단하게 블라인드 테스트를 해 보고 판단하는 것이 좋다. 여기서는 192 kbps에서 Opus가 가장 고음질이라는 결과가 나왔다.

참고로 FLAC에서도 비슷하게 LossyWAV라는 전처리 프로그램으로 노이즈를 삽입하여 용량을 드라마틱하게 감소시키는 방법이 존재한다. 물론 이 과정을 거친 음원은 파일 포맷만 FLAC이지 진짜 무손실 음원은 아니다.

8.2.2. 대역폭 한계

기존의 MP3AAC 같은 오디오 코덱을 대체하기에는 문제가 될 수 있는 점이 또 하나가 있는데, 아무리 비트레이트를 높게 인코딩해도 20 kHz 이상의 신호는 기록하지 않아 384 kbps에서는 MP2(20.3 kHz)보다도 대역폭이 좁다. 근데 인간의 가청 주파수 이상의 소리를 들을 수 있는 사람이 몇이나 될지는..
파일:롤린 Opus 384k.png
파일:롤린 MP2 384k.png
파일:롤린 AAC 320k.png
Opus 384 kbps MP2 384 kbps AAC 320 kbps
8.2.2.1. 낙관론
다만, 유독 한국에서만 스펙트럼이 음질의 절대적인 척도로 해석되는 경향이 있는데, Hydrogenaudio 같은 외국 커뮤니티에서는 유의미한 블라인드 테스트 결과가 없는 스펙트럼 비교 사진은 무의미한 것으로 간주한다. 실제 블라인드 테스트 시에도 결국 가청 주파수 영역에서 원음과의 차이를 구별하는 것이니... 스펙트럼은 대역폭을 알아내는 데는 정말 좋지만 가청 주파수 내에서의 음질을 비교하는 데는 거의 무의미하다. 애초에 인간의 귀로 20 kHz 이상은 극히 일부의 사람을 제외하면 들을 수 없다. 하이파이니 뭐니 해도 인간은 가청 주파수 이내의 소리만 들을 수 있다. 괜히 20 kHz 이상을 초음파라고 하는 것이 아니다. 20 kHz 이상은 이미 특수목적의 영역이며, 초음파를 전문으로 다루기 위해서가 아니라면 반드시 기록되어야 할 필요는 없다. 그리고 앨범을 출시하는 스튜디오에 따라 20 kHz 이상은 커팅하는 곳이 생각보다 많다. 심지어 진짜 FLAC에서도 20~21 kHz 이상을 잘라먹은 게 심심찮게 있을 정도.

손실 코덱에서는 주파수 대역의 범위도 중요하지만 가청 주파수에서의 왜곡을 줄이는 것도 상당히 중요하다. 64kbps 정도쯤 되면 원본과 비교 시 음질 차이를 어느 정도 느낄 수 있으며, 48kbps부터는 원본을 듣지 않아도 음질 열화를 감지할 수 있다. Opus 24kbps와 512kbps는 똑같이 20 kHz에서 자르지만 실제 비교 청취해 보면 음질 차이를 확실히 느낄 수 있다. 특히 전자의 경우 대역폭이 더 좁은 USAC[30]HE-AAC v2[31]보다도 음질이 낮은 편이다.
8.2.2.2. 비관론
그러나 MP3 80kbps급 이하의 저음질 콘텐츠에 HE-AAC, USAC, Opus 같은 가청 주파수 전체나 대부분을 커버할 수 있는 코덱이 사용되는 경우는 매우 드물다. 저장소 용량의 증가, 네트워크 속도의 향상, 재생 장비의 상향 평준화로 저 비트레이트와 저음질의 수요가 줄었으며, 막귀면서 MP3 이외의 오디오 코덱에 대해 잘 아는 경우는 매우 드물기 때문이다.

그리고 고 비트레이트에서도 무조건 자르는 건 문제가 될 수도 있다. 틴 버즈(Teen Buzz)에 대해 아는 사람은 알겠지만 나이가 어려서 21~22kHz까지 실제로 들을 수 있는 음감 인구는 생각보다 그렇게 드물지는 않다. 실제로 이들이 음감 관련 팁(LAME MP3 인코더 옵션 같은 것)을 올리는 경우 나이 든 성인이 같은 팁을 올리는 경우에 비해 17kHz 이상 고주파 보존에 극히 민감한 성향을 보인다. 위에서는 극히 일부라고 했고, 전체 인구 대비로는 맞는 말이지만, 그럼 그 일부는 무시해도 되느냐는 점에서 왼손잡이 문제와도 맥락이 닿는 측면이 있다. 기술적으로 따져봐도 24kHz까지는 지원이 그렇게 어렵지도 않다는 점[32][33], 스테레오 기준 512kbps라는 고비트레이트도 20 kHz 등을 감안하면, 고비트레이트(192나 256kbps 이상이라던가) 한정으로 22~23kHz 정도까지만 지원했어도 관련 불만의 반의 반도 안 나왔을 거다.

물론 애초에 Opus가 Hi-Fi 음감용 코덱으로 개발된 것이 아니라는 점이 근본적인 원인이므로, 위 문제에 해당되는 사람은 VorbisAAC를 사용하는 것이 낫다. Vorbis 표준 인코더나 애플 AAC 인코더로 VBR 최고음질을 설정하면 스테레오 44.1kHz 기준 400~500kbps로 인코딩해 주는데, 이 정도면 고의로 악질적인 코너 케이스[34]를 던져줘도 웬만해선 무손실 PCM과 구별이 불가능할 것이다.

8.2.3. 모노 다운믹스 문제

libopus 1.0에서는 별문제가 되지 않았지만 업데이트가 진행되면서 정도가 심해졌다. 96kbps 이하의 스테레오로 인코딩된 파일을 모노 스피커에서 재생하면 음질이 저하될 수 있다. 주로 중저가 스마트폰이나 블루투스 스피커에서 발생하며 --no-phase-inv[35] 옵션을 추가하거나 처음부터 모노로 인코딩하면 해결된다.

예시 1
예시 2
(원문)
Decoder Mono Downmix

When the bitrate becomes too low to directly code the stereo image using mid-side (MS) stereo, Opus falls back to a technique called intensity stereo (IS) at higher frequencies. This means that the left and right channels in a certain frequency band are derived from the same signal, but with different energy. To slightly improve the quality of IS, the format has a way to optionally make the two channels the inverse of each other. This slightly improves quality when the two channels are very different (inversely correlated). The only drawback of that feature is that when one downmixes a file that uses IS to mono, the left and right channels can sometimes partially cancel each other, which can be annoying. The Opus encoder now has an option[A] to disable this feature during the encoding process, at the cost of a slight degradation in quality at low bitrate. A better option is for the decoder to optionally ignore the inversion flags when it knows that the signal will be downmixed to mono. That way those using stereo still get the benefits of the feature and those downmixing don't get penalized. Since a decoder ignoring these flags is not technically compatible with the current state of RFC 6716, the feature is only enabled with --enable-update-draft until the the IETF update to Opus becomes an RFC.
(한국어 번역)
디코더 모노 다운믹스

비트 전송률이 너무 낮아 중간-주위(MS) 스테레오[37]를 사용하여 스테레오 이미지를 직접 코딩할 수 없을 때 Opus는 더 높은 주파수에서 강도 스테레오(IS)라는 기술로 후퇴합니다. 이 방식에서는 특정 주파수 대역의 왼쪽 및 오른쪽 채널은 동일한 신호에서 파생되지만[38] 에너지[39]는 다릅니다. IS의 품질을 약간 향상시키기 위해 이 형식에는 선택적으로 두 채널을 서로 역 위상으로 만드는 방법이 있습니다. 이렇게 하면 두 채널이 매우 다를 때(역의 상관 관계) 품질이 약간 향상됩니다. 이 기능의 유일한 단점은 IS를 사용하는 파일을 모노로 다운믹스할 때 왼쪽 및 오른쪽 채널이 때때로 부분적으로 서로를 상쇄할 수 있다는 것입니다. 이제 Opus 인코더에는 낮은 비트 전송률에서 품질이 약간 저하되는 대신 인코딩 프로세스 중에 이 기능을 비활성화 할 수 있는 옵션[A]이 있습니다. 더 나은 옵션은 디코더가 신호가 모노로 다운 믹스 된다는 것을 알고 있을 때 선택적으로 반전 플래그를 무시하는 것입니다. 이렇게 하면 스테레오를 사용하는 사람들은 여전히 기능의 이점을 얻을 수 있고 다운믹싱은 불이익을 받지 않습니다. 이러한 플래그를 무시하는 디코더는 RFC 6716의 현재 상태와 기술적으로 호환되지 않으므로 Opus에 대한 IETF 업데이트가 RFC가 될 때까지 --enable-update-draft로만 기능이 활성화됩니다.
- Xiph.Org의 Opus 1.2 데모 페이지

8.2.4. 저비트레이트 한계

스테레오 기준, 앞서 언급된 블라인드 테스트 결과에서도 알 수 있듯 56kbps 미만에서는 HE-AAC보다 음질이 낮았다. 2017년 libopus 1.2에서 많이 개선되었지만, 24kbps에서는 음원, 음향 기기 등에 따라 다르지만 여전히 USAC물론이고 Winamp FhG 인코더로 인코딩한 HE-AAC v2보다도 음질이 약간 낮은 편이다.

하지만 24kbps 스테레오 인코딩은 2018년 libopus 1.3 버전에서 뒤늦게 추가되었으며 저장용량 증가 및 네트워크 속도 향상으로 케이블 인터넷이 아니면 해당 비트레이트를 고려할 필요가 없기 때문에 거의 언급되지 않고 있다.

8.3. 5.1/7.1채널

5.1채널 기준 96~1536kbps(압축률 1/48~1/3)까지 설정할 수 있는데, 192kbps 미만에서는 음질이 낮다고 여기기 쉽다.

7.1채널 기준 128~2048kbps(압축률 1/48~1/3)까지 설정할 수 있는데, 256kbps 미만에서는 음질이 낮다고 여기기 쉽다.


[1] 참조, RFC6716[2] 최신 안정화(stable) 버전 기준[3] 안드로이드 누가~파이 버전에서 Opus 코덱으로 된 파일을 재생하려면 ogg로 확장자를 바꿔줘야 한다.[4] 애플 기기 전용[5] 참조[6] 대표적으로 디스코드, 플레이스테이션 4, 플레이스테이션 5 음성채팅[7] 유튜브[8] Vorbis, Speex, FLAC을 만든 비영리 재단이다.[9] 이 중 MP3의 경우 과거에는 라이선스 비용을 지불해야 했기 때문에 빨간색 그래프로 표기되어 있었으나, 2017년에 특허권이 만료되면서 현재는 제약 없이 사용이 가능해졌고, 이에 따라 초록색 그래프로 변경되었다. 2016년 1월 22일자 아카이브[10] 통신망항목을 보면, 과거에는 음성망을 단독으로 처리했지만 2010년대 들어와서는 MSPP나 PTN이라는 장비를 통하여 인터넷이나 음성망이나 같은 라인을 타기 때문에 의문을 가질 수 있지만 유무선 전화망에서 음성 전화 패킷은 통상 여타 패킷들 보다 더 높은 우선순위로 셋팅되어 있어 각 라우터에서 음성 전화 패킷을 우선적으로 처리한다. 때문에 상대적으로 인터넷은 음성 전화 보다 높은 레이턴시를 가진다.[11] 파일:Opus 48kHz.png[12] 4/5.1/7.1채널 기준 각각 64/96/128kbps 미만인 경우[예시 1] Vorbis는 음악용, Speex는 음성용[예시 2] WMA. Voice는 음성용, Standard, Pro는 음악용[15] 8kbps에서 HE-AAC, Speex, Opus 순으로 나았다. 잡소리 없는 음성만 깔끔하게 들으려면 AMR-WB 계열이 가장 나았다.[16] AAC의 경우 128 kbps CBR을 사용하고 있다.[17] MP4를 지원하지 않았으며 MKV는 여러 문제가 있었다. #1, #2[18] 사실 유튜브는 통신 비용을 아껴야 할 절실한 이유가 있으므로 AV1과 Opus를 적극적으로 쓰고자 노력하는 모습을 볼 수 있다.[19] 몇몇 예외가 있는데 드라마, 영화 인코딩 분야에서는 화질을 중요시하며 교가, 군가, 사가, 로고송, 민중가요, 프로파간다성 곡 등 정치, 사회, 단체 목적의 곡이거나 중파, 단파방송 수신을 취미로 하는 경우는 음질이 중요시되지 않는다.[20] 안드로이드 킷캣까지는 아예 지원하지 않으며, 안드로이드 롤리팝안드로이드 마시멜로WebM(*.webm)과 MKV(*.mkv, *.mka) 컨테이너만 지원한다.[21] 다만 파일 탐색기상에서만 인식이 안 될 뿐이지 알송, 삼성 뮤직 같은 앱상에서는 멀쩡히 인식된다.[22] 메타데이터를 고려하지 않는다면 ogg를 써도 무방하다. 2023년이 되었어도 (메타데이터는 본업이 아니니 그렇다쳐도) ogg 재생을 지원하지 않았다면 지원하지 않는 쪽이 옛날 것/버려질 것이라고 판단될 확률이 높다.[23] 고 비트레이트 음악은 널리 보편화된 포맷인 아이튠즈 AAC코덱을 추천하는 경향이 있다.[24] 어째선지 FFmpeg에서 opus를 m4a로 직접 넣는 것을 지원해주지 못하고 있다.[25] macOS High Sierra/iOS 11 이상이어야 하며, CAF 컨테이너만 지원한다. 그러나 Opus 코덱에 CAF 컨테이너를 사용한 경우는 거의 없다시피 하기에 사실상 지원하지 않는다고 봐도 무방하다.[26] 빌드할 때 --enable-osce 플래그를 추가하고 디코더 복잡도를 6 이상(6: LACE, 7 이상: NoLACE)으로 설정한다.[27] 대역폭이 8kHz이면 최소 비트레이트가 6kbps이기 때문.[28] 이 녀석에다 최신 기술을 더 끼얹어서 3D 오디오 규격(USAC-3D)으로 만든 게 바로 MPEG-H 3D Audio(또는 MPEG-H part 3)다.# 참고 링크 1, 2[29] 대부분의 유튜브 영상에서 사용된다. 다만 VBR 방식을 사용하므로 실제 비트레이트는 160 kbps보다 낮게 측정된다.[30] 17~18.5 kHz[31] 15~16 kHz[32] 물론 48kHz 구조인데 나이퀴스트 정리에 딱 맞게 24kHz에서 자르면 LPF를 잘 짜야하는 단점이 생긴다[33] 참고로 Opus의 최적화 자체가 구조를 단순화한 측면이 크기 때문에 24kHz 초과는 구조적으로 지원 불가능할 가능성이 높다. 설령 가능하다 하더라도, 이제 와서 하면 320kbps 초과 MP3처럼 디코더 호환이 안 돼서 의미 없을 가능성이 거의 100%다.[34] MP3 + 박수 음원처럼 손실 압축의 약점을 극단적으로 드러내는 최악의 경우[35] FFmpeg 기준으로는 -apply_phase_inv false[A] --no-phase-inv[37] 스테레오 음원의 왼쪽(L)와 오른쪽(R) 채널을 중앙(L+R: mid) 채널과 주위(L-R: side) 채널로 변환한 후 인코딩하는 방식. 일반적인 스테레오 음원은 양쪽 채널의 내용에 어느 정도 공통성이 있으므로 왼쪽과 오른쪽 채널을 별도로 인코딩하는 것에 비해 압축 효율이 좋다.[38] 즉 양쪽 채널의 내용은 같다는 뜻.[39] 여기서는 소리의 세기를 뜻한다.[A]


파일:CC-white.svg 이 문서의 내용 중 전체 또는 일부는
문서의 r162
, 번 문단
에서 가져왔습니다. 이전 역사 보러 가기
파일:CC-white.svg 이 문서의 내용 중 전체 또는 일부는 다른 문서에서 가져왔습니다.
[ 펼치기 · 접기 ]
문서의 r162 (이전 역사)
문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)