Golden Ears Event
Announcements
추천제품목록이동

참고:이 글은 http://ko.goldenears.net/board/index.php?mid=ST_KnowledgeBase&document_srl=5477750를 읽었다는 가정하에서 이야기 합니다.고로 작성시간을 줄이기 위해 움짤첨부는 하지 않습니다.

자,움짤들을 유심히 보셨는지요?그러면 이제 이 자료들을 저는 어떻게 해석했는지 알려드리겠습니다.

1.MP3의 경우 예상에서 크게 벗어나지 않은 결과를 보였습니다.또한 MP3 192를 넘어가는 음원은 일반인이 비교하기 어렵다는게 사실이지만,실제 음원과는 차이가 조금 있음이 드러났습니다.하지만 MP3 320=(거의)FLAC인 것도 시원하게 증명되었습니다.

2.측정편에서 우리는 엄청난 압축력을 가진 두개의 압축포멧을 보실수 있습니다.HE-AAC와 Opus이죠.둘다 사실은 64Kbps가 AAC (apple)192~(Nero)256(근사치입니다.) (개인적으로 네로에게 크게 실망했습니다.apple보다 더 좋은 인코더로 인식되고 있다고 2012년에서는 누가 말했었는데 지금은 왜 이리 안습한 결과가 나왔을까요?)를 이기는 (비기는 것이 아니고!) 결과를 보여주었습니다.

그리고 후속 테스트를 했는데,움짤 촬영을 안해서 공개할수는 없지만 MP3 320Kbps를 HE-AAC 80Kbps로 변환한 테스트에서도 별다른 추가적 손실이 보이지 않고 똑같은 모양을 보여주며 잘 따라가서 변환이 가능하다면 용량아끼기에 큰 공헌을 할 수 있을 것이라고 생각합니다.

그리고 호환성을 확인한 결과 안드로이드에서는 Opus재생이 불가능함을(저는 안드로이드로는 제트오디오를 씁니다.) 확인했습니다.그러므로 되도록이면 환경이 조성될 때까지는 HE-AAC를 실사로 쓰시는 것을 권장합니다.

3.전체적으로 일반 AAC는 Opus와 HE-AAC,128이후로는 Vorbis에게도 밀리며 안습한 모양새를 보였습니다.Nero는 사실 정말 심각했다고 생각합니다.Nero의 계측치를 잘 보면 알겠지만,MP3계측치와 큰 차이가 없거나 되려 밀립니다.128은 네로에게 2Kbps의 비트레이트가 더 갔는데도 차이가 거의 없고,(VBR설정 특성상 128,192로 맞출수 없습니다.),192는 네로에게 2가 덜 갔지만 고작 2가 덜 가서 밀렸다고 하기에는 너무 무리한 주장이 아닌가 싶습니다.무엇보다도 MP3 vs AAC입니다.AAC가 밀려서 되겠습니까?

하지만 압축률 그 자체는 AAC(apple)가 MP3보다 분명 우월합니다.

4.Vorbis는 아웃 오브 안중이 될 처지에 몰렸는데,여기서 약간이나마 챙겨줘야 겠습니다.

Vorbis는 확실히 어중간한 비트레이트(160,192) 급에서는 AAC를 이기는 모습을 보입니다.하지만 그에 정비례해서 연산량이 많은 약점을 가지고 있습니다.

무엇보다도 AAC는 현재 사용이 점차 늘어나고 있지만,OGG사용은 별로 없습니다.그게 제일 큰 약점으로 꼽히지요.그리고 그 가장 큰 이유중에 하나가 연산량 과다 문제가 아닐까 생각해봅니다.

무엇보다도 이번 테스트에서 가장 애매한 입장에 처한 포맷이 아닌가 하는 생각이 듭니다.압축률 순위는 사실상 두번째지만 연산량 과다가 발목을 잡을 것 같습니다.HE-AAC와 비슷한 연산량인데,압축률은 Vorbis가 확실히 발리니까요.

이제 결론을 내리겠습니다.

제가 이번 테스트를 보고 매긴 압축률 순위는 이러합니다.

Opus=HE-AAC>OGG Vorbis>AAC(apple)>AAC(Nero)=MP3

그리고 또 한가지 이야기를 할 수 있습니다.

다음은 사실상 음질이 똑같은 순서입니다.

FLAC=MP3 320=AAC(Nero) 320=AAC(apple) 256(또는 224일 가능성도 있습니다.)=OGG Vorise 224=Opus 또는 HE-AAC 64Kbps

이렇게 이해하시면 되겠습니다.

이게 제 실험에 대한 제가 내린 결론입니다.

추가로,저는 추후 HE-AAC와 Opus를 위한 테스트를 하나 할 생각이 있습니다.

극 저 비트레이트에 대한 보존율이 주제가 될텐데,많은 기대 바랍니다.^^

profile

현재 스피커/이어폰:쿼드비트(삼성 번들이 아닌 다른 실리콘 팁),모니터 번들 스피커

현재 소리를 재생할수 있는 기기:지금 사양이 좋은 이 컴퓨터(그러나 꽃게칩),그리고 갤럭시 플레이어 70.

꽃게칩에서는 WASAPI외에 (그나마도  Razer 서라운드 프로그렘에 물려서 듣는 거라 Bit-Perfact와는 거리가 있음.foobar에서 재생시키기가 의외로 까탈스러운 지라 팟플레이어에서 LAVFilters를 이용해 재생시키고 있음.그럼에도 48KHz와 16bit만을 재생하는(44.1KHz재생도 못한다.)서라운드 프로그렘의 까탈스러움때문에 리샘플링을 하게 되어 Bit-Perfact와는 더더욱 멀어지게 되었다.)별다른 짓을 하진 않음.

갤럭시 플레이어 70에서는 바이퍼의 DDC기능을 이용해서 플랫하게 듣기+소리가 전체적으로 줄어드는 것을 없애기 위해 +2.3dB를 넣음.

profile

초월체

2015.02.12 00:24

잘 봤습니다.. 


참고로.. 동영상 인코딩 할때 사용하는 방법으로..


VORBIS처럼 OPUS 코덱을 OGG 콘테이너 안에 넣는 방식으로 인코딩하면 안드로이드에서 MX플레이어로 구동 가능하더군요~ 그렇게 되면 확장자는 OGG이지만 코덱은 OPUS이고요~ OPUS가 OGG 개발사에서 만든 포맷이라 서로 호환이 되는거려나요?ㅎㅎ 


이렇게 해도 아직 대부분의 안드로이드 소프트웨어들에서 코덱을 인식 못하지만.. 안드로이드 5.0 롤리팝부터 OPUS 지원한다고 본것 같은데.. 빨리 이 좋은 코덱이 자리좀 잡아갔으면 좋겠내요

profile

잡금귀

2015.02.12 08:03

저도 OGG로 확장자 밑장빼기 바꿔치기를 시전했는데 제트오디오는 재생을 못하더군요.foobar에서는 OGG로 바로 인코딩하는 것은 지원하지 않습니다.하지만 확장자 바꿔치기를 해도 지원하는 쪽에서는 인식을 잘 합니다.

MX플레이어로 재생하는 방법은 어째 좀 께림직한 면이 없잖아 있고요.(마치 음악파일을 곰,팟플레이어로 재생하는 이질적인 느낌?디코더는 어차피 상향평준화 되어서 똑같은 소리가 난다는 것을 알고 있어도 영...)

여러모로 Opus가 많이 많이 지원되기를 바라고 있습니다...

그나저나 초월체사진 진짜 정겹군요 ㅎㅎ 스타1할때 참 많이도 본 사진인데...

profile

Acoustic Gom

2015.02.12 11:45
음.. 궁금한것이 있는데
플렉과 손실음원 이큐차이는 많이 차이 나나요? 원본소스는 저런데 이큐는 어떨지 궁금합니다
profile

fireloaf

2015.02.12 13:43

EQ차이는 없습니다.


코덱에서는 EQ가 적용되지 않습니다.

신호에 따라 불필요한 부분은 버리고

필요한 부분은 자세히 표현함으로써

낮은 비트에도 원음과 비슷하게 들리게 하는 것입니다.


특정 대역을 증폭하거나 감쇄시키지 않습니다.

profile

잡금귀

2015.02.12 23:07
약간의 상관은 있습니다.
이퀄라이징을 강하게 먹였을때,MP3에서 192에 못미치는 비트레이트들인 경우 음이 깨지는 것을 들을수 있습니다.단,192는 아주 극단적으로 먹여야 들릴겁니다.
하지만 저 비트레이트에서의 압축효율이 높아진 차세대 포맷들은 왠만큼 낮게 주는게 아닌 이상 그럴 일은 별로 없습니다.
profile

fireloaf

2015.02.12 13:40
추천
3
비추천
0

정성이 담긴 장문의 글 잘 보았습니다.


다소 김을 빼는 게 아닌가 싶지만

외국에서도 비슷한 실험들이 많이 있었습니다.


코덱들에 대해 시기순으로 나열하면

1992년에 mp3 (MPEG-1 layer 3)가 표준화되었고

1997년에 MPEG-2 AAC가 표준화되었습니다.

MPEG-4 HE-AAC의 경우 버전1과 버전2가 있는데

각각 2003년, 2004년에 표준화되었습니다.


이 중에는 HE-AAC가 10년 밖에 안된(?) 가장 최신 코덱입니다.


MPEG 진영에서 나온 코덱에는 2007년에 나온 MPEG Surround와

2012년에 나온 USAC이 있습니다.

MPEG Surround는 멀티채널용 코덱이고

USAC은 음성코덱과 융합된 코덱입니다.



Vorbis의 경우는 mp3의 비싼 로열티에 자극받은 Christopher Montgomery에 의해

2002년에 첫버전이 만들어졌습니다.

OPUS는 2010년에 만들어진 코덱인데 MPEG의 USAC과 유사하게 음성코덱과 융합된 구조를 가집니다.

주목할 만한 점은 포함된 음성코덱이 SKYPE의 코덱인 SILK라는 점입니다.



이외의 대표적인 코덱으로는 Dolby의 AC-3를 논하지 않을 수 없겠죠.

1991년에 세상에 나온 AC-3는 돌비 디지털이라고 불리기도 합니다.

성능은 비슷한 시기에 나온 mp3와 비슷하다고 보시면 됩니다.

수많은 영화 미디어와 DTV의 오디오 코덱으로 채택되면서 이름을 날리게 됩니다.

들어보시진 못했겠지만 AC-3 이전에 AC-1, AC-2도 있었고,

AC-3의 개선판인 E-AC-3 (또는 돌비 디지털 플러스)도 있었습니다.

AC-4가 작년에 유럽에서 표준화되었고 미국의 UHD TV 표준인 ATSC 3.0에도 채택될 것으로 보입니다.


대부분의 오디오 코덱들은 인코더에 따라 성능이 달라집니다.

이를 forward adaptive 방식이라 부릅니다.

AC-3의 경우는 backward adaptive 방식을 사용하는데 이는 인코더 구조가 결정되어 있고

따라서 비트레이트가 같으면 음질도 같게 되는 방식입니다.


mp3의 경우 forward adaptive 방식이고

유료인코더에 대항해 만들어진 것이 LAME입니다.

(LAME: LAME ain't mp3 encoder, GNU와 같이 재귀적인 정의를 사용했죠.)


AAC의 경우도 다양한 인코더가 존재하는데

사실상 AAC의 대부분을 만들어낸 Fraunhofer보다

애플의 인코더가 더 나은 성능을 보여주고 있습니다.

링크참조: 96 kbps에 대한 결과

http://listening-tests.hydrogenaud.io/igorc/aac-96-a/results.html



스펙트럼 분석 결과로부터 HE-AAC와 OPUS에 대해 좋게 평가하시는 듯 합니다.

그런데 이는 좀 다르게 바라볼 필요가 있습니다.


HE-AAC에도 내부적으로는 AAC가 돌아가고 있습니다.

다만 추가적인 방법이 들어간 것인데

HE-AACv1에서는 SBR(spectral band replication)

HE-AACv2에서는 PS(parametric stereo) 기술이 추가되어 있습니다.

링크를 참조하시면 이해가 용이하실 겁니다. http://minimonk.net/5311


SBR은 상대적으로 정보가 많지 않고 귀가 덜 민감한 고주파 대역을

저주파 대역에서 복사해서 붙이는 기법입니다.

따라서 대략적인 형태만을 보면 거의 전대역을 잘 표현하는 것으로 보입니다.

하지만 윤곽선만 비슷할 뿐 하모닉 등은 잘 표현하지 못하는 한계가 있습니다.

OPUS의 경우에도 이러한 SBR이 적용되었는지의 여부는 나타나 있지 않네요.



참고로 이러한 다양한 코덱들에 대해 주관적인 음질평가를 한 결과가 있습니다.

좀 지난 자료지만 유럽 방송 연합에서 5.1ch에 대해 내놓은 결과가 있습니다.

https://tech.ebu.ch/docs/tech/tech3324.pdf


22페이지 결과를 보시면 HE-AAC 160 kbps가 AAC 320 kbps에 근접하기는 하지만

음질이 상대적으로 일정하지 못하고 평균에서도 쳐지는 것을 볼 수 있습니다.

스테레오로 환산하면 HE-AAC 64와 AAC 128 kbps의 비교치라고 추정할 수 있습니다.


최근의 결과로는 아래 링크를 참조하시기 바랍니다.

http://soundexpert.org/encoders-256-kbp


여기서 보면 AAC 256 이상, mp3 320 이상이면 원본과 구분하지 못한다는 것을 알 수 있습니다.


http://soundexpert.org/news/-/blogs/opus-aac-vorbis-mp3-mpc-at-128-kbit-s?p_p_auth=4qHksfXT

이 링크를 보면 128 kbps에서 다양한 코덱을 비교하고 있고 조만간 결과가 나올 것 같습니다.

저기서 OPUS 128 kbps가 어떤 성능을 보여줄 지가 기대됩니다.


96 kbps에 대한 결과는 링크 참조하세요.

http://listening-test.coresv.net/results.htm

개인적으로 OPUS가 많이 사용되고 퍼졌으면 하는 바람입니다.



살짝 다른 이야기지만 (별도의 글로 따로 써야 할 것 같지만)

블루투스용 오디오 코덱이 난립하고 있습니다.

무료 코덱이지만 음질이 나쁘다고 생각되는 SBC (하지만 SoundExpert 결과를 보면 충분히 괜찮습니다.)

유료 코덱이고 음질이 엄청 좋다고 알려진 aptX (하지만 비트레이트에 따른 성능이 알려진 바가 없습니다.)

aptX의 경우 압축률이 1/4에 불과합니다. 스테레오를 352 kbps로 압축합니다.

저 정도에서는 음질을 나쁘게 만드는 게 더 어려울 지경입니다.

aptX 자체는 좋고 나쁘고를 논할 비트레이트가 아니고

aptX를 소유하고 있는 CSR이 블루투스 칩셋을 잘 만든 게

음질적인 면에서 개선을 이루었다고 보는 게 맞을 듯 합니다.

어쨌든 aptX가 좋은 거 아니냐고 할 수도 있지만

SBC로도 충분한 걸 돈을 더 주고 쓰게 된다라는 겁니다. (배터리도 aptX가 더 먹습니다;;;)

물론 aptX가 더 좋은 점도 있습니다.

딜레이가 적기 때문에 비디오 게임을 할 때, 영상과 싱크 틀어짐이 별로 없습니다.

그 밖에는 굳이 aptX를 써야 할 필요가 없어보입니다.

(잠깐 곁다리로 새면 aptX와 DTS가 뿌리가 같습니다. DTS도 압축율이 1/3 정도로 낮습니다.)



댓글이 너무 길었네요.

나중에 시간날 때 다시 정리해야겠네요. ^^;;;;;

profile

잡금귀

2015.02.12 23:00
추천
1
비추천
0
주장을 요약해서 정리+제 견해
1.HE-AAC는 AAC에 기술을 추가한 것이며,버전이 2개가 있다.(저도 알고 있지만 굳이 설명하기 귀찮아서 설명을 생략했습니다.)그리고 이 포맷은 복사하기 신공이라 겉모양은 잘 따라가나 하모닉같은 곳에 문제가 있다.
그러나 저도 실사를 하기 이전에 제가 테스트에 사용한 음원으로 ABX테스트를 하였는데(FLAC VS HE-AAC 64) 통계적으로 의미없는 정답률을 보였습니다.저도 찍기임을 직감했으나 어쨌든 잘 찍고(?) 나왔습니다.그래서 저는 압축률을 믿고 FLAC를 HE AAC 80kbps로 바꿨습니다.참고로 스펙트럼을 계속 들여다보는 일을 하고 있는데,(그러나 꿀캠은 지웠습니다.)MP3 320에서 바꿔보는 실험도 거뜬하게 잘 통과했습니다.즉,기계적인 계측치 레벨에서는 분명히 출렁거리는 면이 있지만 귀가 느낄만큼의 차이가 잘 나지는 않는다는 겁니다.
2.비교글이 많다는 소린데...이미 비교글이 많긴 합니다.근데 그것들은 죄다 영어입니다.그리고 저는 개인적으로 영어를 읽는 것을 그리 좋아하지 않습니다만,국내에서는 나서주는 사람이 별로 없습니다.더구나 외국의 측정치는 제가 사용한 실제 음원이 아닌 정적인 음원을 쓰는 경우도 있어서,실제 음원의 모습에 대입하기에는 무리가 있는 경우도 있습니다.그래서 한계가 사실 명확할 수 있는 실험임에도 해보았습니다.그래서 저는 한계를 최대한 줄이기위해 현실의 음원을 써먹었고,CBR이 많으나 foobar에서 CBR을 지원치 않는 MP3를 제외하고는 실제로 사용되거나 사용가능한 비트레이트로 인코딩을 했습니다.또한 실질적인 비교 대상은 대역폭이 아닌 FLAC를 얼마나 잘 따라가느냐라는 말도 미리 일러두는 곳에서 했습니다.
3.AAC에서 구분못하는 임계점은 인코더에 따라 다를 수 있습니다.Nero에게 데이는 모습 보셨잖습니까.사실 진짜 문제는 내부 인코더만 쓰는 대부분의 음악 파일 변환 프로그렘이 무슨 인코더를 쓰는지 알 수 없다는 겁니다.(foobar는 외부 인코더를 쓰기 때문에 이런 문제가 없습니다.)대부분의 생 인코더는 CLI인데,저로서는 정말 현기증이 납니다.일반적인 사용자들이 다루기에는 왠지 너무 어려워보인다는 의미입니디.
4.aptX...저도 들어본 적이 있는 코덱이긴 합니다.하지만 곧 완전 무료에 레이턴시도 짧은 Opus가 자리를 꿰찰수 있지 않을까 생각합니다.애초에 그거 개발 방향이 블루투스 코덱이니까요.또한 비트레이트를 되게 많이 늘리는 이유는,손실음원을 돌릴때 음 손실을 줄이기 위한게 아닐까 생각하고 있습니다.아직까진 무손실 코덱을 블투에 적용하기엔 무리고요.
이정도입니다.HE AAC에 대해서는 여려 환경을 만들어서 ABX테스트를 실시해봐야 겠습니다.
profile

fireloaf

2015.02.13 11:19
추천
1
비추천
0

EBU 테스트에서 음원별 점수를 참조하면 HE-AAC의 성능도 상당히 괜찮습니다.

다만 applause (박수) 음원에 대해 특히 음질이 떨어지는 것을 볼 수 있습니다.

콘서트 실황 등을 듣게 된다면 음질 저하가 두드러질 것으로 예측됩니다.


오디오 부호화는 어떤 인코더를 썼느냐도 중요하지만 어떤 성질의 음원인지도 영향을 끼칩니다.

사인파라면 64 kbps mp3로도 충분히 좋은 소리를 만들 수 있는 반면,

박수나 헤비메탈과 같은 복잡한 소리는 훨씬 높은 비트레이트를 요구하기도 합니다.

애플에서 아이튠즈를 통해 제공되는 음악들은 애플의 인코더로 AAC 256 kbps로 인코딩됩니다.

SoundExpert의 실험 결과를 보면 가장 인코딩하기 어려운 신호의 경우에도

청각적으로 구분을 하지 못한다는 결과를 보여주고 있습니다.


저장매체 기술의 발전으로 상대적으로 압축율에 대한 요구가 줄었습니다.

20년전만 해도 mp3 하나 받으려면 나우누리에서 걸어놓고 다음 날 확인하던 시절이었고

256MB mp3p에 환호하기도 했습니다. (앨범을 무려? 4개나 넣을 수 있었죠.)

하지만 이제는 아이팟 클래식이 아니어도 수천곡씩 넣을 수 있는 수준이 되었습니다.

그런 상황이라면 음질이 나빠질 수도 있는 최신의(?) 저비트레이트용 코덱보다는 AAC를 사용하는 게 낫겠죠.

애플도 이러한 점들을 깊이 고민하고 mp3도 아니고 HE-AAC도 아닌 AAC를

그리고 128 kbps나 192 kbps도 아닌 256 kbps를 사실상의 표준 코덱으로 사용한 것으로 보입니다.

개인적으론 애플을 좋아하지 않지만 적어도 오디오 코덱의 경우

소비자에게 다양한 선택을 제공하기보다는 최선의 선택 만을 제공하는 건 잘한 점이라고 생각됩니다.


mp3 인코더는 고민하지 마시고 LAME, AAC 인코더는 애플 아이튠즈 쓰시면 됩니다.

CLI는 뭔지 잘 모르겠네요 @.@;


저도 개인적으로 OPUS가 성공적으로 퍼트려져서 많은 사람들에게 사용되길 바랍니다.

그러나 부정적인 전망으로 바라볼 수 밖에 없는 게 무료라는 장점이 다른 한편으로는 단점이기도 하기 때문입니다.

OPUS를 통해 돈을 벌 수 없기 때문에 칩셋 제조사에서 OPUS 코덱을 적극적으로 사용하지 않을 것입니다.

aptX를 가지고 있는 CSR의 경우는 당연하거니와 Broadcom의 경우도 배타적 사용이 불가하기 때문에

경쟁력을 가지기 어렵기 때문에 적극적으로 사용할 지 의문입니다.

그나마 기대할 수 있을만한 건 구글에 의해 유투브에서 사용되는 것입니다.


그리고 블루투스에 있어서도 다소 부정적인 점은 SBC나 aptX에 비해 딜레이가 크다는 점입니다.

mp3나 AAC에 비해서는 (>50 msec) algorithmic delay가 적지만

SBC (5 msec)나 aptX (2 msec) 보다는 delay가 크기 때문입니다. (OPUS: 20 msec)

참고로 HE-AAC는 딜레이가 100 msec가 넘어갑니다.


또한 배터리 소모 또한 심합니다.

SBC나 aptX의 압축율이 떨어지는 건 딜레이를 줄이기 위해서도 있지만

복잡도를 줄여서 배터리 소모를 줄이기 위한 목적도 있습니다.

블루투스 헤드폰에서 재생시간이 얼마나 중요한 이슈인지는 잘 아실 겁니다.

aptX를 소유하고 있는 CSR 측의 문서를 참조하면

SBC는 12 MIPS, aptX는 32 MIPS라고 합니다.

OPUS의 경우는 수치적으로는 나와 있지 않지만

상대적으로 연산량이 높은 mp3와 유사한 수준이라고 합니다.


대역폭 만을 보면 블루투스에 무손실 코덱 적용이 가능하긴 합니다.

무손실 코덱이 아니라 Linear PCM (무압축 원본)도 가능합니다.

블루투스 2.0 이후로의 대역폭이 스펙상 3 Mbps (2.1 Mbps 실효)이기 때문에

16 bit / 44.1 kHz Linear PCM이 요구하는 1.411 Mbps을 충분히 만족합니다.

무손실 코덱의 압축율이 60% 정도라고 하면 850 kbps면 충분합니다.

소니의 블루투스용 최신 코덱인 LDAC는 990 kbps로 제공된다고 하니

어느 정도는 검증이 되었다고 볼 수 있겠죠.


다만 무손실 코덱이 사용되지 않는 이유는 다양한 환경에 대한 안정성 때문일 겁니다.

스마트폰에 오디오만 연결되면 모르겠지만 다양한 장비들이 맞물리면

대역폭을 나누게 될 것이고 결과적으로 음이 끊기는 상황이 생길 수 있기 때문에

실제 가용한 대역폭보다 훨씬 적은 대역폭을 오디오에 할당하는 거겠죠.

소니도 990 kbps를 사용할 때는 블루투스를 오디오 전용으로 쓰라고 할 것 같습니다.



정리해 주신 자료들을 통해 저도 몰랐던 내용들을 알 수 있었고

(비트레이트에 따라 대역이 어느 정도까지 존재하는지, HE-AAC가 고대역을 얼마나 잘 살려주는지 등)

그래서 잡금귀 님께 감사한 마음입니다. ^^

다만 대역폭 만으로 오디오 코덱의 성능을 판단하는 것은

무리가 있을 수 있다는 말씀을 드리고 싶었습니다.

profile

잡금귀

2015.02.13 19:47
CLI를 컴덕이 아닌 사람을 위해 간단히 설명하자면,명령 프롬프트를 통해 구동되는 프로그렘이라고 생각하면 되겠습니다.
엄밀한 설명으로 하면 제 말은 너무 협소한 범위로 이야기를 한 거지만,이해하기에 제일 빠르고,CLI환경이 왜 다루기 어려운지도 답이 나옵니다.그래서 그런 환경인 생 인코더를 직접 쓰기란 매우 어렵습니다.
지적하려던 바가 무엇인지는 잘 알았습니다.요약하자면 압축하기 까다로운 신호에 HE AAC가 취약하다는 건데,이것은 추후 ABX테스트와 보강된 스팩트럼 검사로 밝혀낼 영역이라고 보입니다.한계가 있는 것은 확실한 것 같고요.
Opus의 경우 레이턴시는 해결 가능하지만(레이턴시는 최적화시 8msec까지 떨어집니다.발전가능성을 생각해보면 더 떨어질 가능성도 충분합니다.) 배터리 런타임은 해결이 힘들 것으로 보입니디.다만 mp3수준이라면 vorbis와 달리 휴대기기에서 문제가 되는 일은 피할 수 있겠군요.
사실 압축률이 왜 문제가 되냐는 물음의 답은 블루투스의 대역폭이 되는데 왜 무손실을 쓰지 못하냐의 답과 같습니다.
휴대기기에는 용량이 넘사벽인 동영상을 때려박는 경우도 많고,그중에 하나가 저입니다.고로 저의 경우에는 16기가라고 안심할수만은 없습니다.그래서 용량아끼기에 비교적 용이한 편인 음악 파일을 최대한 압축시켜서 조금이라도 빈 용량을 늘려주는게 안심이 되지요.그런 이유입니다.
저도 왜 그런 이야기를 하시는지는 충분히 이해가 갑니다.
다음에는 평균적인 음원 하나와 압축하기 까다로운(콘서트 실황이나 대규모 클래식,또는 헤비메탈) 음원 하나를 들고 가서 테스트하는 방식으로 신뢰도를 높여주어야 할 것 같습니다.지적주셔서 감사합니다^^
profile

fireloaf

2015.02.16 11:08

CLI를 찾아보니 command line interface의 약자네요. 간단히 생각하면 GUI의 반대(?)되는 개념이네요.


OPUS의 경우는 SILK(음성용)와 CELT(음악용)가 잘 버무려진 코덱이라고 보시면 되는데

음성이 아닌 음악으로 구분되어서 부호화되면

48 kHz 샘플링된 신호를 960 샘플을 한 블록으로 처리하기 때문에

20 msec algorithmic delay는 확정적이고 개선의 여지가 없어 보입니다.


압축이 잘 되면 당연히 좋겠지만 비디오에 비하면 압축율을 높일 필요성이 크지 않기도 하죠.

지상파 HDTV의 경우 비디오는 MPEG-4 AVC로 거의 20 Mbps로 압축해서 날립니다.

비디오에 비교해서 보면 1/100도 안되는 용량이기 때문에 상대적으로 덜 중요하게 여겨집니다.


'데이터=돈' 이 되는 모바일 환경에서는 HE-AAC나 OPUS가 매우 유용한 코덱이 되리라 보입니다.

다만 HE-AAC의 경우 딜레이가 크기 때문에 오디오 스트리밍 전용으로 쓰이게 되는 한계가 있고요.

상호 주고 받는 양방향 통신용으로는 적합하지 않습니다.

때문에 애플의 페이스타임 경우도 HE-AAC의 지연을 줄인 코덱인 AAC-ELD를 사용하고 있습니다.
(참고로, AAC의 지연을 줄인 코덱이 AAC-LD, HE-AAC의 지연을 줄인 코덱은 AAC-ELD입니다.

LD: low delay, ELD: enhanced low delay)


OPUS가 만들어진 목적 자체도 스트리밍용이기 때문에 딱 맞아떨어집니다.

딜레이도 적어서 상호통신용으로도 괜찮을 것 같습니다.

개인적으로 디지털 라디오에 OPUS가 사용되었으면 하는 바람입니다.


DMB의 오디오 채널에서 아직도 BSAC이 사용되는지 모르겠지만

압축율도 떨어지고 딜레이도 커서 부적절한 코덱인데 추후에는 변경되길 바랍니다.



덕분에 의견을 나눌 수 있어 즐거웠습니다. 감사합니다. ^^

profile

발짐

2015.02.12 23:30

좋은 내용 감사합니다.

따로 정리하실 글도 기대하겠습니다.

profile

수퍼링

2015.03.28 09:48

스마트폰으로 음악재생시에 코덱별로 배터리 소모량도 다른건가요?

전 아무지식이 없는 상태긴한데 용량이 클수록 배터리소모량이 높을거라고 생각하고 있는데

댓글을보니 코덱연산량에 따라 다른것 같기도하고

아니면 스마트폰 배터리 소모랑 코덱이랑은 무관한가요?

profile

fireloaf

2015.03.30 15:22

코덱별로 배터리 소모량이 다릅니다.

용량이 큰 경우도 물론 많은 메모리를 컨트롤해야 하기 때문에

적은 메모리보다는 배터리 소모량이 늘기는 할 겁니다.

보통은 메모리 용량보다는 코덱복잡도에 대한

배터리 소모량 변화가 큰 걸로 알고 있습니다.


코덱이 복잡한 경우는 훨씬 많은 연산을 해야 하기 때문에

배터리를 더 많이 사용하게 됩니다.

스마트폰을 가만히 둘 때와 인터넷을 많이 할 때의 배터리 소모량이 다르듯이 말입니다.


SBC나 aptX의 경우 코덱의 구조가 매우 단순합니다.

덕분에 압축율은 매우 낮습니다.

SBC 328 kbps와 AAC 195 kbps의 음질이 대략 비슷한 수준입니다.

(참조: http://soundexpert.org/encoders-320-kbps)


성능이 좋은 AAC가 블루투스 코덱으로 사용되지 않은 이유는

로열티 문제도 있지만, 딜레이 문제도 있고,

특히 배터리 측면이 큰 걸로 알고 있습니다.

당장 aptX만 해도 SBC의 연산량 (12 MIPS)보다 훨씬 큰

32 MIPS의 연산량을 요구합니다.

profile

HMX-12

2015.03.30 15:38

그리고 잘 알려져있지 않은데 APT-X는 ADPCM 기반의 코덱이라 mp3 같은 스타일의 열화와는 좀 다른 성향의 열화가 나타납니다. 사인파 재생능력이 떨어져서 고음역대가 거칠어진다고 해야될까요? 살짝 덜 매끄러운 소리가 나옵니다. 본인이 가지고 계신 곡들 중에 일렉기타(오버드라이브) 곡을 IMA ADPCM 44khz로 변환하면 비슷하게 체험해보실 수 있습니다. 경우에 따라 더 선명하게 느낄 수 도 있고요. 무손실 파일을 APT-X로 재생해서 들어봐도 비슷합니다.

List of Articles

12088

VIEWS

14

COMMENTED

13954

VIEWS

13

COMMENTED

7347

VIEWS

9

COMMENTED

10108

VIEWS

23

COMMENTED

중급 약간 단순한 DSD와 DAC이야기 -4부- file

  • 등록일: 2014-12-02

9858

VIEWS

8

COMMENTED

9458

VIEWS

20

COMMENTED

37560

VIEWS

5352

VIEWS

초급 블루투스 코덱에 관하여

  • 등록일: 2014-10-14

5951

VIEWS

12

COMMENTED