최근 수정 시각 : 2021-12-19 10:36:58

Opus(오디오 코덱)

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

오디오 코덱
{{{#!wiki style="margin:0 -10px -5px"
{{{#!folding [ 펼치기 · 접기 ]
{{{#!wiki style="margin:-6px -1px -11px; word-break: keep-all"
<colbgcolor=#a0e6c3,#286f4f> 손실 압축 <colbgcolor=#cbeddc,#2b4f42> 일반 MP1, MP2, MP3, mp3PRO, AAC, Musepack, WMA, Vorbis, Opus, USAC
음성 특화 AMR-NB, AMR-WB, AMR-WB+, WMA Voice, Speex, Opus, EVS, Codec 2
다중채널 특화 AC-3, SDDS, DTS, AC-4
블루투스 SBC, aptX, AAC, LDAC, Samsung Scalable Codec, LC3
무손실 압축 FLAC, ALAC, APE, TAK, WMA Lossless, TTA, Wavpack
무손실 무압축 PCM( WAV, AIFF)
관련 문서: MIDI, DSD
}}}}}}}}} ||
그래픽 | 오디오 | 비디오

파일:Opus-Logo.svg

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채널

1. 개요

홈페이지

오픈소스, 로열티 없는 무료 손실 압축 포맷 오디오 코덱이다.

2. 개발 과정

참고 글

2007년부터 Xiph.Org[1]에서 개발한 지연 시간이 아주 낮으면서도 고음질을 목표로 한 코덱인 CELT와 2009년부터 Skype에서 개발한 고효율 음성용 코덱인 SILK를 Xiph.Org에서 통합해서 탄생했다. 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-WB Vorbis, AAC, MP3 등과 비교되는 것은 개발하면서 이것저것 넣다 보니 코덱이 뛰어나서 여기저기 쓰임새가 있는 것일 뿐 주요 경쟁 상대는 아니다.

Opus 코덱의 우수성은 이 이미지 하나로 끝난다. 단, 이 그래프에서는 HE-AAC가 빠져있음을 감안해야 하고, 56kbps 이하에서는 HE-AAC가 효율이 더 좋다.
단 음질이 아닌 실시간 통신에서는 이야기가 조금 다르다. AMR-WB/NB계열이 레이턴시에서 제일 좋으며, 그 다음이 OPUS, 그 밑으로 AAC같은 일반 코덱 계열이 따라간다.이는 개발의도에서 부터 갈리는 점인데, AMR계열은 에서 쓰이는 코덱은 SDH라 불리우는 유/무선 전화전용망에서 쓰이는 것을 전제하여 만들어진 코덱이고, OPUS나 SPEEX, G.729같은 VOIP용 코덱은 인터넷망에서 쓰이는 통화용으로 만들어진 코덱이다. 따라서 AMR보다는 레이턴시에 둔감하게 설계되었다.[2] HE-AAC같은 음성용 코덱은 레이턴시가 크게 중요하지 않은 스트리밍용 코덱이다. 한마디로, AMR, OPUS, HE-AAC는 저 비트레이트에서 레이턴시냐 음질이냐를 취사선택 해서 만든 것이라는 이야기다.
파일:external/www.opus-codec.org/quality.png

4. 사양

  • 지원 샘플링 레이트: 48 kHz
    • 8, 12, 16, 24 kHz 음원도 48 kHz로 변환된다.[3]
    • 특이하게 CD의 주파수인 44.1 kHz가 없다. 개발자의 주장에 의하면 44.1 kHz 음원을 48 kHz로 변환하는 과정에서 음질의 손실은 거의 없고, CDP 같은 경우가 아닌 대부분의 범용 플레이어가 스피커 등으로 소리를 출력하는 과정에서 44.1 kHz를 48 kHz나 그 이상으로 변환하여 출력하기 때문에 큰 의미가 없다고. 또한 44.1 kHz를 제외함으로써 코덱이 단순해지는 장점이 더 크다고 하였다. 윈도우도 사운드카드 설정을 특별히 바꾸지 않으면 기본이 48 kHz이고 안드로이드 폰도 최근에는 대부분 48 kHz를 기본 샘플링 주파수로 사용한다. 즉 44.1 kHz 음원은 디코딩 후 48 kHz로 리샘플링이 이루어지게 되는데 킷캣까지 기본 내장된 리샘플러의 성능은 그리 좋지 않다고 한다. #
  • 지원 주파수
    약칭 기록 주파수 샘플링 주파수

    NB(narrowband) 4 kHz 8 kHz

    MB(medium-band) 6 kHz 12 kHz

    WB(wideband) 8 kHz 16 kHz

    SWB(super-wideband) 12 kHz 24 kHz

    FB(fullband) 20 kHz 48 kHz
    • 기본적으로 20 kHz 이상의 신호는 기록하지 않는다. FB의 기록 주파수가 24 kHz가 아닌 20 kHz인 것이 그 이유. 또한 96 kHz나 24비트 같은 고음질 오디오도 지원하지 않는다. 이것도 개발자 주장으로는 '제대로 제작된' 48 kHz/16비트 음원이면 충분하다고. 사실 96/192 kHz 음원의 경우 재생능력이 안 되는 기기가 재생하면 가청주파수를 넘어선 초음파가 가청주파수 내의 음으로 바뀌어서 내용이 왜곡되는 문제가 있다. 이런 주파수를 유령주파수라고 부르기도 한다. 또한 이러한 떡밥은 골든이어스에서도 논의가 되었는데, 결론적으로 48kHz에 16bit면 인간의 능력에 비해 차고 넘친다고 이야기되고 있다.
    • 비트레이트에 따른 기본 기록 주파수(libopus 1.3.1 기준)

      • 2 ~ 8 kbps 4 kHz

        9 ~ 12 kbps 8 kHz

        13 ~ 2048 kbps 20 kHz
      • set-ctl-int 옵션을 사용하면 기록 주파수를 강제 지정할 수 있다. set-ctl-int 4004=1001, \set-ctl-int 4008=1001 옵션을 추가하면 NB(narrowband)로 인코딩되며, 1001 대신 1002, 1003, 1004, 1005를 입력하면 각각 MB, WB, SWB, FB로 인코딩된다.
  • 지원 채널 수: 1~255개
  • 지원 비트레이트: 2 ~ 2048 kbps. CBR(고정 비트레이트), CVBR(고정 비트레이트에 가깝지만 비트를 가변 할당하며, AAC의 CBR과 비슷하다.)와 VBR(가변 비트레이트)을 모두 지원한다.
    모노(1채널) 2 ~ 256 kbps(CBR)
    5 ~ 256 kbps(CVBR, VBR)

    스테레오(2채널) 28 ~ 512 kbps(음성)
    18 ~ 512 kbps(음악)

    4채널 64 ~ 1024 kbps

    5.1채널 96 ~ 1536 kbps

    7.1채널 128 ~ 2048 kbps
    • 비트레이트에 따라 최적 기록 주파수 및 채널 수가 변경되며 실시간 변경도 가능하다. 또한 변경이 될 때 별도의 잡음이나 지연(공백)이 들리지 않는다.
      • 비트레이트가 6 kbps 정도인데 괜히 20 kHz 대역폭의 음악을 다 기록하려고 용을 쓰다가 소리를 모조리 깨먹지는 않는다. 실제로 6 kbps로 인코딩하면 가장 낮은 기록 주파수인 4 kHz 이상은 처음부터 컷오프해서 인코딩한다.
      • 채널도 마찬가지로 4채널 이상에서 채널당 16kbps 미만이면[4] 스테레오로, 스테레오 음원은 18kbps 미만의 낮은 비트레이트에서 모노로 다운믹스되어 인코딩된다.

4.1. SILK

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

4.2. CELT

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

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. 장점

  • 대부분의 비트레이트에서 기존의 오디오 코덱보다 전반적으로 우수한 성능을 보여 준다. 물론 코덱에 따라 유리/불리한 부분은 따로 있지만, 일반적으로 매우 높은 압축률을 가졌다.
    • 비슷한 음질일 때 음악 콘텐츠인 경우 Vorbis보다 20~30% 정도, 음성 콘텐츠인 경우 Speex보다 최대 60% 정도 용량이 작다.
파일:external/listening-test.coresv.net/nonblocked_means_all2.png
△ Hydrogenaudio에서 실시한 공개 블라인드 테스트 비교 결과. 여기서 FAAC는 테스트의 유효성을 평가하기 위한 것이다. 기존에 유튜브에서 사용했던 아주 끔찍한 코덱이 FAAC이다. 비트레이트가 낮게 설정되어 있는 점을 감안하고 볼 것.
  • 기존 대부분의 오디오 코덱이 음악용과 음성용이 아예 별도로 있거나[예시 1] 인코딩 시 옵션 선택을 해야 하는 반면[예시 2] Opus는 자동으로 최적화된 데이터를 뽑아낸다.
    이 과정에서 Xiph.Org의 CELT 기술과 스카이프의 SILK 기술을 기반으로 하여 통합하였다.
  • 레이턴시가 매우 짧아(기본 26.5 ms, 최적화 시 최저 5 ms 정도) 실시간 통화 등에 이용하기 적합하다.

6. 단점

  • 샘플 레이트가 48kHz로 제한되어 있다.
  • 극저 또는 극고비트레이트에서는 불리하다.
    • 비트레이트를 아무리 높여도 20kHz 이상은 기록하지 않으며 화이트 노이즈가 아주 미세하게 들어간다.
    • 음성 기준 12kbps 미만에서는 다른 코덱보다 효율이 떨어진다.[7]

6.1. 해결됨

  • 낮은 호환성. 지원하는 컨테이너가 Ogg, MKV, WebM 정도밖에 안 되며, 사용률이 높은 상용 컨테이너인 MP4에는 못 넣었다. 그러나 2020년 7월 FFmpeg 4.2.4 기준, MP4 컨테이너도 Opus 스트림을 탑재할 수 있다.

7. 현황

아직 나온 지 얼마 안 돼서 지원하는 플레이어가 그리 많은 편은 아니지만, 차츰 늘어나는 추세다. 유튜브에서는 이미 스트리밍에 쓰이고 있다. 2016년 중후반 동영상 코덱을 VP9로 변경하면서 사운드 코덱도 Opus로 변경되었는데, 예전에 비해 매우 좋은 음질을 들을 수 있게 되었다. 비트레이트는 초기에는 160kbps였는데 2021년 3월 기준 128kbps로 낮아졌다.

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

2010년대 중반까지는 지원하는 컨테이너가 적었으나[8], 2021년 현재 MP4, MKV, Ogg(또는 opus), WebM 이 네 가지의 컨테이너에서 지원되어 호환성도 낮지 않다. 허나 유튜브를 제외하고 영상에서는 잘 쓰이지 않는다. 기존 추세인 AAC(고비트레이트에서)나 HE-AAC(저비트레이트에서)도 충분히 나쁘지 않은 성능을 자랑하고. 실제로 Opus와 각종 코덱을 비교한 그래프상으로도 AAC와 그렇게 큰 갭이 발생하진 않는다.

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

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

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

윈도우에서는 10 RS1(1607)부터 . mkv 확장자를, RS3(1709)부터 . ogg 확장자를, RS5(1809)부터 . webm 확장자를, 19H1부터 .opus 확장자를 영화 및 TV, Groove 음악 앱에서 지원하고 있다. 물론 팟플레이어 등의 서드 파티 프로그램에서는 2010년대 초중반부터 지원하고 있다.
음악 플레이어(윈도우)
foobar2000 2012년 8월 17일 v1.1.14
AIMP 2012년 11월 16일 v3.20
곰오디오 ? ?
알송 ? ?
동영상 플레이어(윈도우)
팟플레이어 2014년 1월 15일 v1.5.44407
KM플레이어 2014년 10월 7일 v3.9.1.129
VLC 2015년 2월 27일 v2.2.0
곰플레이어 2015년 3월 30일 v2.2.69.5228
MPC-BE 2016년 6월 13일 v1.4.6

애플 기기에서는 2017년 출시된 macOS High Sierra와 iOS 11부터 파일 앱에서 FLAC, Opus 재생을 지원하고 있지만 #, Opus의 경우 CAF(Core Audio Format) 컨테이너만 지원한다. 물론 서드 파티 앱을 사용하면 .ogg나 .opus 확장자여도 재생이 가능하다.

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

Nintendo Switch는 사용 프로세서인 NVIDIA Tegra에 Opus 하드웨어 코덱이 내장되어 있으며, 이를 사용하는 대표적인 게임으로 슈퍼 스매시브라더스 얼티밋이 있다.

웹 브라우저에서의 호환성은 다음과 같다. #
파이어폭스 15 이상 2012년 7월 17일
크롬 33 이상 2014년 2월 21일
오페라 20 이상 2014년 5월 4일
엣지 14 이상 2016년 8월 2일
삼성 인터넷 5 이상 2016년 12월 16일
사파리 11 이상[11] 2017년 9월 19일

8. 음질 평가

같은 단체에서 개발한 Vorbis Speex와는 거의 비교되지 않고 있다.

8.1. 음성(SILK)

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 정도가 적당하다.

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~384kbps 정도 되면 MP2조차도 음질이 좋다는 평을 받는다.

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

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

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

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

8.2.2. 대역폭 한계

기존의 MP3 AAC 같은 오디오 코덱을 대체하기에는 문제가 될 수 있는 점이 또 하나가 있는데, 아무리 비트레이트를 높게 인코딩해도 20kHz 이상의 신호는 기록하지 않아 384kbps에서는 MP2(20.3kHz)보다도 대역폭이 좁다. 근데 인간의 가청 주파수 이상의 소리를 들을 수 있는 사람이 몇이나 될지는..
파일:롤린 Opus 384k.png 파일:롤린 MP2 384k.png 파일:롤린 AAC 320k.png
Opus 384k MP2 384k AAC 320k
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[13] HE-AAC v2[14]보다도 음질이 낮은 편이다.
8.2.2.2. 비관론
그러나 MP3 80kbps급 이하의 저음질 콘텐츠에 HE-AAC, USAC, Opus 같은 가청 주파수 전체나 대부분을 커버할 수 있는 코덱이 사용되는 경우는 매우 드물다. 저장소 용량의 증가, 네트워크 속도의 향상, 재생 장비의 상향 평준화로 저 비트레이트와 저음질의 수요가 줄었으며, 막귀면서 MP3 이외의 오디오 코덱에 대해 잘 아는 경우는 매우 드물기 때문이다.

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

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

8.2.3. 모노 다운믹스 문제

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

예시 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) 스테레오를 사용하여 스테레오 이미지를 직접 코딩할 수 없을 때 Opus는 더 높은 주파수에서 강도 스테레오(IS)라는 기술로 되돌아갑니다. 즉, 특정 주파수 대역의 왼쪽 및 오른쪽 채널은 동일한 신호에서 파생되지만 에너지는 다릅니다. 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보다도 음질이 약간 낮은 편이다.

하지만 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] Vorbis, Speex, FLAC을 만든 비영리 재단이다. [2] 통신망항목을 보면, 과거에는 음성망을 단독으로 처리했지만 2010년대 들어와서는 MSPP나 PTN이라는 장비를 통하여 인터넷이나 음성망이나 같은 라인을 타기 때문에 의문을 가질 수 있지만, 같은 라인을 탄다고 하더라도 목적지 까지 가는 경로가 서로 다르다. 지속적으로 라우터를 타야하는 인터넷라인은 음성회선에 비해 레이턴시가 길 수 밖에 없다. [3] 파일:Opus 48kHz.png [4] 4/ 5.1/7.1채널 기준 각각 64/96/128kbps 미만인 경우 [예시 1] Vorbis는 음악용, Speex는 음성용 [예시 2] WMA. Voice는 음성용, Standard, Pro는 음악용 [7] 8kbps에서 Speex가 opus보다 나으나, HE-AAC 계열이 더 낫다. 그런데 잡소리 없는 음성만 깔끔하게 들으려면 AMR-WB 계열이 더 낫다. [8] MP4를 지원하지 않았으며 MKV는 여러 문제가 있었다. #1, #2 [9] 4.4 킷캣까지는 아예 지원하지 않으며, 5.0 롤리팝 6.0 마시멜로 WebM(.webm)과 MKV(.mkv, .mka) 컨테이너만 지원한다. [10] 다만 파일 탐색기상에서만 인식이 안 될 뿐이지 알송, 삼성 뮤직 같은 앱상에서는 멀쩡히 인식된다. [11] macOS High Sierra/iOS 11 이상이어야 하며, CAF 컨테이너만 지원한다. [12] 2021년 3월 기준 유튜브에서 사용하고 있다. [13] 17~18.5 kHz [14] 15~16 kHz [15] MP3 + 박수 음원처럼 손실 압축의 약점을 극단적으로 드러내는 최악의 경우 [16] FFmpeg 기준으로는 -apply_phase_inv false [A] --no-phase-inv [A]



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