이 글에서 먼저 한 이야기지만 최근에 인터넷을 돌아다니다가 LC3plus 코덱을 주웠다. LC3은 기본적으로 블루투스 5.2 LE Audio에 들어가기 위해서 개발된 코덱인데 LC3 코덱만 따로 생각하지 말고 블루투스 5.2 LE Audio와 같이 생각해야 한다.
블루투스 LE Audio
블루투스 버전이 2.1이건, 3이건, 4이건 4.2이건 5이건 간에 지금까지 오디오 전송에 대해서는 큰 변화가 없었다. 대충 블루투스 4.2쯤 되면 장치의 배터리 정보와 같은 간단한 정보를 호스트에 보내는 기능 정도가 추가되었을 뿐이다. 근데 블루투스 5.2부터는 좀 달라진다. 이전까지는 블루투스에서 오디오 전송에는 BT Classic을 사용했지만 5.2에서는 BT LE에서도 오디오 전송을 위한 모드가 추가된 것이다.
원래는 블루투스 클래식으로도 맥시멈 1Mbps까지 뽑아낼 수 있으므로 (무손실로 전송하고 싶은 오디오파일들은 슬퍼할 이야기지만) 오디오 전송에는 큰 문제가 없었다. 대체적으로 블루투스 헤드폰에 들어가는 배터리 용량으로는 충전 없이도 10시간 이상 연속재생이 가능했기 때문에 굳이 저전력을 추가로 고려할 만한 유인으로는 부족했지만 TWS란게 나오면서 모든 게 바뀌어버렸다. TWS 유닛 안에 들어가는 배터리는 100mAh도 안 되기 때문에 잘 해야 5시간 연속 재생이 한계였고, 크래들에 넣어서 충전하고 다시 뽑는 방식으로 재생시간을 연장해야 했다.
또 다른 문제는 블루투스가 전통적으로 스테레오 신호를 전송하는데 TWS에서는 왼쪽과 오른쪽이 받아야 할 신호가 다르기 때문에 신호 전송에서의 문제도 같이 생겼다. 에어팟에서는 한쪽의 유닛이 통신할 때 다른쪽의 유닛이 신호를 가져와서 뽑아먹는 식으로 해결했고, 초창기 TWS들은 우측 유닛이 왼쪽 유닛에 따로 신호를 보내는 방식으로 해결했기 때문에 여러 가지 문제가 발생했다. (퀄컴의 TWS plus는 그냥 망해버린 독점기술이니 언급하지 않도록 하자)
그래서 블루투스 LE Audio에서는 브로드캐스트 기능으로 여러 디바이스에 오디오 신호를 보낼 수 있게 하고 동기화와 같은 여러 기능들을 준비해놨다. TWS로서는 꽤나 쓸모있는 기능인 것이다.
하지만 유념해야 할 점은 LE audio 자체는 블루투스 Classic에 비해 가용 비트레이트가 적다. (저전력을 사용해야 하므로 당연하다.) 블루투스 classic이 500Kbps까지 바라보고 출력할 수 있다면 LE audio는 잘해야 300Kbps (보통은 160kbps)에서 놀게 될 것이란 의미이다. 그래서 높은 비트레이트를 고려하는 (통상 고음질임을 광고하는) 제품들은 꼭 LE audio를 채택하리라고 장담할 수 없다.
LC3 이야기
블루투스의 표준 코덱이 SBC인 것처럼 LC3은 블루투스 LE 오디오의 표준 코덱이다. 그리고 LC3 자체는 로얄티를 받지 않는 코덱이다. 그래서 LC3코덱은 우선적으로 AAC나 aptX와 같은 옵션 코덱들보다는 SBC와 (특허권이 만료되어 공짜가 된) MP3과 비교해야 한다.
LC3 코덱은 우선적으로 Low Complexity, 즉 저복잡도를 목표로 한 코덱이다. 저전력과 저지연을 달성하기 위해서는 코덱의 연산량이 많아서는 안 되기 때문에 적은 연산량으로 최적의 효율을 얻기 위한 코덱이다. 따라서 LC3 코덱 자체가 고음질을 위해 개발되었다는 것 자체는 완벽하게 맞는 말은 아니다.
하지만 8~90년대에 개발된 SBC나 aptX와 같은 코덱보다는 2010년대에 개발된 LC3은 그 사이에 개발된 기술들이 적용되어 있기 때문에 이것들보다는 적은 비트레이트에서도 고음질을 낼 수 있을 것이라고 추정해 볼 수는 있다.
대충 기술적인 이야기
LC3코덱과 LC3Plus 코덱은 기본적으로 거의 같은 코덱이다. LC3Plus에는 고해상도 모드나 저지연 모드 등 다용도로 써먹을 만한 기능이 추가되었고 기본적인 설계는 LC3과 동일하다. 마치 aptX와 aptX-HD의 관계와 비슷하다고 보면 될 것이다.
![](https://blog.zlzleking.name/wp-content/webpc-passthru.php?src=https://blog.zlzleking.tk/wp-content/uploads/2020/11/20ee383532a3664f1b7e7befad2dec80.png&nocache=1)
LC3 코덱은 MDCT와 여러 가지 노이즈 셰이핑 기술을 사용해서 인코딩된다. MDCT 자체는 소니의 LDAC나 ATRAC에서도 사용되는 기술이고, 노이즈 셰이핑 자체도 여러 분야에서 사용되는 기술이다. 사용된 기술 자체는 여기서 기술 자료를 받아볼 수 있으니 읽어보면 될 것이다.
많은 사람들이 기대할 LC3Plus의 “고해상도 모드”는 자료에 설명한 그대로 표현하면 MDCT 과정을 수행하기 전에 LPF에서 컷오프 주파수를 높이는 것이다. 그래서 16Khz 쯤에서 잘라버리는 기본 모드와는 달리 상당한 영역에서 주파수를 온존하기 때문에 고해상도 음원에 대응한다는 느낌이지만, 이렇게 되면 다른 주파수 영역에서의 전체적인 품질 자체는 나빠진다는 점을 고려해야 할 것이다.
고해상도 모드 자체는 아무 때나 킬 수는 없고 48khz나 96khz 소스에서 선택적으로 킬 수 있다. (그렇다. 이 코덱은 24/96까지 받는다.)
그래서 테스트한 이야기
![](https://blog.zlzleking.name/wp-content/webpc-passthru.php?src=https://blog.zlzleking.tk/wp-content/uploads/2020/11/e9673255d8cb1184069aabc88b21c385.png&nocache=1)
인코더와 디코더 자체는 소스코드로 주어지고 사용하기 위해서는 직접 컴파일을 해야 한다. 그리고 아직 완성된 인코더는 아니기 때문에 약간의 문제가 발생하는데, Readme에 따르면
The fixed-point source code currently has limited support for the
following functions:
– High resolution mode
The floating-point source code currently has limited support for the
following functions:
– Packet loss concealment
– Error protection (LC3plus channel coder)
– Partial concealment
대충 이렇다고 한다. 나는 고해상도 모드를 테스트하기 위해서 Floating-point로 컴파일했다. 인코더 자체는 여러 옵션이 있지만 우선 샘플링 레이트를 적절하게 입력하지 않으면 모든 부분이 0으로 인코딩된 쓰레기 데이터가 나오는 것과 스테레오가 적절하게 동작하지 않는 것을 테스트할 다른 사람들에게 참고로 알린다.
스펙트로그램 테스트
스펙트로그램을 그려보는 것은 간단하게 코덱의 특징을 알 수 있는 방법인데, 우선 300kbps 남짓으로 인코딩한 결과를 보자.
간단하게 0부터 20khz까지 sweep한 결과인데, 고주파수 쪽에 노이즈가 집중되는 것을 알 수 있다.
![](https://blog.zlzleking.name/wp-content/webpc-passthru.php?src=https://blog.zlzleking.tk/wp-content/uploads/2020/11/3.png&nocache=1)
좀 더 깔끔한 LAME코덱과 비교하면 조금 실망스러운 결과임을 알 수 있는데, 이것은 서로 고 비트레이트를 사용했음을 감안해야 할 것이다.
![](https://blog.zlzleking.name/wp-content/webpc-passthru.php?src=https://blog.zlzleking.tk/wp-content/uploads/2020/11/image-3-1024x314.png&nocache=1)
화이트 노이즈의 경우에는 고주파수가 잘리는 것을 볼 수 있다.
![](https://blog.zlzleking.name/wp-content/webpc-passthru.php?src=https://blog.zlzleking.tk/wp-content/uploads/2020/11/image-4.png&nocache=1)
mp3 코덱에 비해 같은 비트레이트에서 컷오프 주파수가 낮게 걸리는 것을 확인할 수 있다.
다음엔 실제 음악을 사용해서 테스트를 해 보자. 우선 lc3plus의 고해상도 모드를 테스트하기 위해서 Snow halation을 틀어봤는데
![](https://blog.zlzleking.name/wp-content/webpc-passthru.php?src=https://blog.zlzleking.tk/wp-content/uploads/2020/11/image-6-1024x314.png&nocache=1)
고해상도 모드를 키면 높은 주파수 영역대가 잘 보존된다. (500kbps일 때)
![](https://blog.zlzleking.name/wp-content/webpc-passthru.php?src=https://blog.zlzleking.tk/wp-content/uploads/2020/11/image-7.png&nocache=1)
하지만 96khz의 경우에는 고해상도 모드를 키지 않으면 인코딩 자체를 거부한다.
![](https://blog.zlzleking.name/wp-content/webpc-passthru.php?src=https://blog.zlzleking.tk/wp-content/uploads/2020/11/image-10.png&nocache=1)
하지만 300kbps정도로 비트레이트를 낮춘 경우에는 고해상도 모드임에도 불구하고 고주파 노이즈가 생기는 것을 볼 수 있다. 하지만 고주파 영역이기 때문에 최종 출력에는 잘릴 가능성이 높다는 점을 감안해야 한다.
이번엔 여러 코덱 간 비교를 해보겠는데 키타카미 레이카의 Find your wind!를 사용해 보겠다.
![](https://blog.zlzleking.name/wp-content/webpc-passthru.php?src=https://blog.zlzleking.tk/wp-content/uploads/2020/11/image-8-1024x307.png&nocache=1)
![](https://blog.zlzleking.name/wp-content/webpc-passthru.php?src=https://blog.zlzleking.tk/wp-content/uploads/2020/11/image-9-1024x312.png&nocache=1)
300kbps 정도로 인코딩했을 때는 대충 이런 느낌인데 오른쪽의 SBC보다는 확실히 낫고 mp3과 비교하면 스펙트로그램 상 특별한 차이점을 찾기는 힘들다. (컷오프 주파수의 차이가 아니라면)
다만 140kbps 정도의 낮은 주파수로 인코딩하면 좀 달라지는데
![](https://blog.zlzleking.name/wp-content/webpc-passthru.php?src=https://blog.zlzleking.tk/wp-content/uploads/2020/11/image-11-1024x307.png&nocache=1)
![](https://blog.zlzleking.name/wp-content/webpc-passthru.php?src=https://blog.zlzleking.tk/wp-content/uploads/2020/11/image-12.png&nocache=1)
mp3이나 완전히 뭉개지는 SBC에 비해 원본을 잘 보존하고 있는 것을 볼 수 있다. 실제 음악을 인코딩했을 때 저 비트레이트에서 mp3에 비해 이점이 있는 것을 볼 수 있다.
![](https://blog.zlzleking.name/wp-content/webpc-passthru.php?src=https://blog.zlzleking.tk/wp-content/uploads/2020/11/image-13.png&nocache=1)
다만 좀 더 복잡한 코덱인 AAC와 비교해 보면 큰 차이가 없는 것을 볼 수 있다.
![](https://blog.zlzleking.name/wp-content/webpc-passthru.php?src=https://blog.zlzleking.tk/wp-content/uploads/2020/11/image-14.png&nocache=1)
번외로 aptx랑 비교해 보면 높은 주파수까지 열심히 노이즈로 채운 모습을 볼 수 있다. (왜 48khz가 되었는지는 ffmpeg의 aptx인코더에게 따지자)
결론적으로 스펙트로그램 비교만 하게 되면 LC3 코덱은 높은 비트레이트에서는 컷오프 주파수가 16khz 남짓인 것을 감안하면 SBC보다는 우위를 보이고, 낮은 비트레이트에서는 AAC의 충분한 경쟁자가 될 수 있음을 고려할 수 있다.
번외편 : 간단한 RMAA
대충 RMAA를 돌려 봤으니 참고용으로 보길 바란다. 순서대로 주파수 응답, 노이즈 레벨, THD이다.
![](https://blog.zlzleking.name/wp-content/webpc-passthru.php?src=https://blog.zlzleking.tk/wp-content/uploads/2020/11/image-15.png&nocache=1)
![](https://blog.zlzleking.name/wp-content/webpc-passthru.php?src=https://blog.zlzleking.tk/wp-content/uploads/2020/11/image-16.png&nocache=1)
![](https://blog.zlzleking.name/wp-content/webpc-passthru.php?src=https://blog.zlzleking.tk/wp-content/uploads/2020/11/image-17.png&nocache=1)
간단한 결론
프라운호퍼는 LC3은 SBC의 대체를, LC3Plus는 AAC나 LDAC와 경쟁하는 것을 바라고 있는 것 같다. LC3은 기존 코덱들보다는 꽤나 우수한 코덱임은 맞는 것 같지만(LDAC까지는 경쟁이 잘 될 것 같다.) AAC와 비교했을 때 우수한지는 생각을 좀 해 봐야 한다. 다만 LC3은 무료로 제공되기 때문에 AAC에 비해서는 일정한 장단을 가진다는 점을 생각하면 향후 제품들이 나오는 것을 지켜봐야 할 것 같다.
한 가지 특징적인 점은 LC3 코덱은 블루투스의 통화 코덱으로도 사용되기 때문에 기존에 사용되던 mSBC 코덱에 비해서 비약적인 통화품질의 상승을 가져올 것이다.
또한 LC3코덱은 다른 코덱들보다 처리량이 적기 때문에 레이턴시가 적은데, 이 글에서 오디오 코덱들의 인코딩 레이턴시는 아래와 같이 나타난다.
- SBC: 150-250 ms
- aptX: 130-180 ms
- AAC: 190-240 ms
- LDAC: 160-210 ms
하지만 LC3 코덱은 자료에 나와 있는 대로라면 5ms에서 최대 12ms까지의 인코딩 레이턴시를 가지기 때문에 블루투스 오디오에서의 레이턴시를 비약적으로 줄일 수 있을 것이다. (하지만 결국은 제품이 나와서 테스트를 해봐야 알 수 있다. 레이턴시가 줄어든다는 것은 연결 안정성도 줄어든다는 것을 의미하기 때문에 버퍼를 늘리는 식으로 만들면 레이턴시 이득은 줄어든다.)
LC3 코덱을 사용한 제품은 빠르면 2021년이나 2022년쯤부터 나올 전망이다. 반면 차세대 코덱에서 경쟁자가 될만한 화웨이(와 친구들의) LHDC는 아직까지 공개된 인코더 같은 것이 없어서 평가를 하기 힘들다.