gaudio

뒤로가기back

가사 싱크? AI가 직접 합니다: GTS PO가 직접 소개하는 GTS

2023.07.07 by John Jo

가사 싱크? AI가 직접 합니다: GTS PO가 직접 소개하는 GTS

(Writer: John Jo)

 

 

들어가며 : GTS 소개에 앞서 제 소개를 먼저 할게요.

 

안녕하세요! 가우디오랩에서 GTS의 PO를 담당하는 존이라고 합니다. 가우디오랩에서는 GTS(Gaudio Text Sync)라는 제품의 PO로, 퇴근 후에는 재즈 보컬리스트로 활동하고 있답니다. 뉴올리언스 마칭밴드인 SoWhat NOLA의 리더이자 보컬을 담당하고 있어요. (막간 홍보

 

 

여러분은 ‘음악을 눈으로도 듣는다 👀’라는 말에 공감하시나요?

 

바로 노래 가사 이야기인데요. GTS는 요즘 스트리밍 서비스에서 빼놓을 수 없는 ‘실시간 가사 보기’ 기능에 직접 적용되는 제품으로, AI가 자동으로 가사와 음악의 싱크를 맞추는 기능을 제공합니다.

 

오늘 저는 여러분께 GTS에 대해 소개해 드리고, 저와 가우디오랩이 함께 낳고 기르는(?) 이 AI 제품이 세상을 어떻게 변화시키고 있는지 말씀드리고자 합니다.

 

 

 

‘실시간 가사 보기’의 알려지지 않은 뒷 이야기

 

오늘 날 대부분의 뮤직스트리밍 서비스가 실시간 가사 서비스를 제공하고 있는데요.

 

<실시간 가사 서비스의 예시 화면 - 이렇게 말이죠!>

 

최근까지 뮤직 스트리밍에 인입되는 곡들의 가사와 멜로디의 싱크를 사람이 일일이 들어가며 손수 맞추고 있었다는 사실, 알고 계셨나요? (보통 ‘찍는다’고들 하죠)

 

사람이 직접 싱크 가사를 만들다 보니 필연적인 단점들이 생기는데요, 아마 우리가 흔히 겪어봤던 일일 겁니다.

 

  1. 일단 느립니다. 한 곡 싱크를 위해서는 한 곡 전체를 다 들어야하고 랩처럼 가사가 정말 빠르게 지나가거나 한국어가 아닌 다른 언어가 주 언어가 된다면, 처리 시간은 기하급수적으로 늘어날 수밖에 없죠.

  2. 퀄리티가 일정하지 않습니다. 위에서 말씀드린 속도와도 연관되는 이야기일텐데요, 싱크가 어려운 음원일수록 시간이 더 오래 걸리기 때문에 하루에 여러 곡을 처리해야하는 담당자들이 모든 곡을 완벽하게 처리하는 것은 불가능에 가깝겠죠.

  3. 음악 시장에는 하루에도 수 만곡 씩 곡들이 쏟아져 나옵니다. 음악 스트리밍 서비스들이 가사를 싱크하기 위해 인건비를 더 많이 지출해야하는 것은 당연한 일이죠. 게다가 관리 비용까지 생각한다면… 만만한 비용으로 할 수 있는 작업이 아닙니다.

  4. 아티스트의 문제도 해결합니다. 저도 앨범을 발매할 때 가사 싱크의 문제로 어려움을 겪은 적이 있어요. 재작년에 제 첫 앨범을 발매 했었는데, 해외 스트리밍 서비스(애플뮤직?)에서 실시간 가사 서비스를 제공해주지 않아 제가 직접 한땀 한땀 싱크 작업 서비스를 이용했던 것이 생각나네요. 반면, GTS가 도입되어 있는 국내 스트리밍 서비스에서는 싱크가 잘 맞아 흐뭇해했던 기억이 납니다.

 

 

이 문제를 한 큐에 해결하는 AI, GTS에 대해 조금 더 알려드릴게요.

 

 

 
<GTS 개념도>

 

GTS는 Gaudio Text Sync의 약어인데요, 쉽게 말하자면 [AI가 가사와 음원을 자동으로 동기화 해주는 솔루션] 입니다. 예를 들어, BTS의 신곡 “Take Two”의 mp3 파일과 “Take Two”의 가사가 적힌 txt 파일만 있으면 가사들의 타임라인을 자동으로 생성해주죠.

 

에이 그래도 시간이나 비용이 얼마나 단축되겠어? 라고 물으신다면!

 

  1. GTS는 1곡에 5초면 충분하고 영어, 한국어, 중국어, 일본어까지도 커버합니다. 어떤 곡을 프로세싱하든, 사람보다 월등한 성능으로 정확하게, 그리고 훨씬 빠르게 타임라인을 만들어냅니다. 에미넴이나 아웃사이더처럼 빠른 곡들도 문제 없죠. 이와 유사한 문제를 겪고 있는 스트리밍 서비스라면, 바로 채택할 수밖에 없습니다. (그리고 그게 여러분의 비즈니스에 좋아요!)

  2. 싱크 결과물 뿐만 아니라 싱크가 얼마나 잘 되었는지, 각 가사의 라인마다 싱크가 잘못 생성이 되지는 않았는지를 담은 곡마다의 ‘싱크 결과 리포트’를 제공합니다. 서비스를 제공 받으시는 분들은 해당 리포트를 가지고 잘못된 가사나 싱크를 손쉽게 검토하고 수정할 수 있죠. (퇴근시간이 빨라져요!)

  3. 이제 한국 뮤직 스트리밍 서비스 대부분은 GTS를 통해 만들어 낸 실시간 가사를 고객들에게 제공하고 있습니다. 해외의 스트리밍 서비스들도 눈독을 들이고 있고, 계속 긴밀한 미팅을 진행 중에 있습니다. 한국은 잡았고, 해외로 갑니다! 부릉!

  4. 하지만 아직 놀라긴 일러요. 가사의 줄 별 타임라인을 만들어내는 것부터 시작한 GTS는 이제 어절 별 타임라인까지 찍어내기 때문이죠. 기술의 고도화를 통해 이제 어절 별을 넘어 노래방에서 볼 수 있는 글자 별 타임라인까지 생성하는 것을 로드맵으로 리서치팀, 개발팀과 함께 움직이고 있습니다.

 

 

백문이 불여일견, 한 번 비교 해봅시다.

 

한국의 음악 스트리밍 플랫폼인 G사와 NAVER VIBE의 가사 싱크를 함께 볼까요?

제가 좋아하는 Incognito라는 그룹의 Still a friend of mine 이라는 곡을 골라봤어요.

 

 

먼저 G사의 실시간 가사보기 화면인데요, 싱크가 거의 1줄 이나 차이나는 걸 보실 수 있죠.

다들 이런 경험 있으실거예요. 참 답답하고 불편하죠. 해당 가사를 눌렀을 때 딱 그 구간으로 이동해서 듣는 데도 어려움이 있고요.

 

 

그리고 아래는 GTS를 적용한 VIBE입니다.

싱크가 잘 맞아 음악을 즐기기에 훨씬 좋네요. (바이브의 전매특허, 원어민 급 자연스러운 번역 가사를 볼 수 있는 것은 덤!)

 

 

 

GTS는 세상을 이렇게도 바꾸고 있어요

 

이은교육: 청각 장애인들도 음악을 들을 수 있어요.

 

GTS는 청각 장애인용 음악 교육 서비스에도 쓰입니다. 어절 별 진동을 통해 청각 장애인에게도 음악을 향유할 수 있도록 하는 건데요. 이 어플리케이션의 런칭을 준비하고 있는 한국의 이은교육에서도 GTS가 활약하고 있습니다. GTS가 어절별 시작 점과 끝 점 타임라인을 도출하는 과정에 쓰여 청각 장애인들이 가사의 마디 마디를 구분할 수 있도록 돕습니다. 훌륭한 AI 기술을 통해 세상을 더 좋게 만든다는 가우디오랩의 미션을 실천 중이지요.

 

 

<이은교육과의 미팅>

 

콘샐러드: 인디 뮤지션도 쉽게 리릭 비디오(가사 비디오)를 만들 수 있어요!

콘샐러드에서는 인디 아티스트들의 신곡 홍보를 위해 리릭 비디오(Lyric Video, 아래 그림 참조)를 만들어 배포를 하고 있는데요. 이 리릭 비디오의 가사 싱크를 위해 GTS가 이용되고 있기도 합니다. 가우디오랩의 기술로 인디 뮤지션들의 홍보를 돕는 것이죠.

 

 

다시 한 번 가우디오랩의 미션인 ‘혁신적인 기술로 사람들에게 훌륭한 소리경험을 제공한다'를 실천 중인 사례라고 볼 수 있겠죠?

 

여기서 멈추지 않습니다. 무궁무진한 GTS의 세계…

 

  1. 텍스트와 음성의 싱크가 필요한 곳이면 전부 가능합니다.

    1. OTT나 영상의 폐쇄자막과 음성의 싱크가 필요할 때

    2. 오디오북에서 오디오와 텍스트의 싱크가 필요할 때

    3. 어학학습을 위해 오디오와 텍스트의 싱크가 필요할 때

  2. 그 외에도 GTS가 적용될 수 있는 곳은 생각보다 세상 곳곳에 많이 있으니, 언제든 저를 찾아주세요 🙂

 

 

끝 맺으며

 

제가 가우디오랩에 합류해서 제일 먼저 한 일은 바로 GTS의 상용화였습니다. 이제는 GTS가 한국 대부분의 뮤직스트리밍에서 쓰이는 제품이 되어 많은 유저들이 더욱 풍성하게 음악을 들을 수 있도록 기여하고 있으니 정말 뿌듯한 마음입니다.

 

제 다음 타겟은 한국 외의 모든 시장들입니다. 전 세계의 수많은 음악/OTT 등 스트리밍 서비스에 GTS가 적용될 수 있게 박차를 가할 예정입니다.

 

한국을 넘어 전 세계 유저들의 청취 경험을 개선하고 싶으신 분들, 어서 가우디오랩의 문을 두드리세요! 🙂

 

 

 

 

 

pre-image
WebRTC에 Audio AI SDK 통합하기 (2) : 효과적인 통합 개발을 위한 테스트 환경 구축 방법

WebRTC에 Audio AI SDK 통합하기 (2) : 효과적인 통합 개발을 위한 테스트 환경 구축 방법 (Writer: Jack Noh)     지난 포스트를 통해 WebRTC와 그 오디오 파이프라인에 대해 간단히 설명드렸던 것처럼, WebRTC는 매우 거대한 멀티미디어(오디오, 비디오, 데이터 전송 등) 기술이며, 오디오 부분만 보더라도 여러 모듈들(APM, ACM, ADM, …)이 존재합니다. 그만큼 활용 범위가 높은 기술이기도 한데요, 이번 포스팅에서는 WebRTC에 오디오AI SDK를 통합하는 과정 중 매우 중요한, ‘견고한 테스트 환경’을 구축하는 방법에 대해 이야기 해보려고 합니다.     WebRTC Audio Processing Module   WebRTC의 오디오 모듈들 중에 노이즈 제거 필터를 통합하기 가장 적합한 모듈은 무엇일까요? 사실 앞선 포스트를 읽어보셔서 눈치채셨겠지만, 이런 다른 SDK를 통합하기에 적합한(사실상 통합을 위해 만들어놓은) 모듈은 바로 APM(Audio Processing Module)입니다. 애초에 APM 자체가 통화 품질을 높이기 위한 신호 처리 기반의 오디오 신호 필터들을 모아놓은 모듈이기 때문입니다.   Audio Processing Module은 주로 단말(Client-side)에서 오디오에 효과를 주는 핵심 모듈입니다. 이 모듈은 오디오 신호를 통화(call)에 적합한 좋은 품질로 향상 효과를 주는 목적으로 필터들을 모듈화해놓은 것입니다. APM 모듈의 필터들은 Sub-module로 불리며 다양한 역할을 수행합니다.   WebRTC의 대표적인 Submodule들을 간략히 소개하자면 아래와 같습니다. High Pass Filter(HPF): 저주파수 신호를 제거하여 목소리 같은 고주파 신호만을 추출하는 필터 Automatic Gain Controller(AGC): 오디오 신호의 크기를 자동으로 조절하여 일정한 수준으로 유지하는 필터 Acoustic Echo Cancellation(AEC): 스피커에서 나오는 신호(Far-end)가 다시 마이크로 들어가는 에코를 제거해주는 필터 Noise Suppression(NS): 주변 환경음(노이즈)를 제거해주는 신호처리 기반의 필터   이러한 Submodule들은 Near-end Stream(마이크 입력 신호를 상대방에게 전송)과 Far-end Stream(상대방으로 부터 수신 받은 오디오 데이터를 스피커로 출력)에서 각각 알맞게 활용되는데요. 화상회의 하는 시나리오를 예를 들어서 설명드려볼게요. 먼저 마이크에 입력된 오디오 신호는 저주파수 잡음을 제거하기 위해 High Pass Filter(HPF)를 거치게 됩니다. 다음에 갑자기 큰 소리로 인해 청감적인 불편함을 없애기 위해서 자동으로 신호 크기를 제어하는 Automatic Gain Controller(AGC)를 거치게 되죠. 그 이후에 에코(스피커에서 나오는 신호가 다시 마이크로 들어가는 것)를 방지하고자 Acoustic Echo Cancellation(AEC)를 통하게 됩니다. 그 이후에 주변 환경 노이즈를 제거하는 Noise Suppressor(NS)를 거치는 것이죠. 글 보다는 그림으로 표현하는게 훨씬 간단합니다. 아래 그림에서 ProcessStream()이란 마이크에서 입력받은(Capture) 신호 Stream의 프로세싱을 나타냅니다. 정방향이란 표현을 쓰기도 합니다. 동시에 ProcessReverseStream()은 원격의 상대(Peer)로 부터 온 오디오 데이터를 SPK로 출력(Render)하기 위한 역박향 Stream을 프로세싱하기 위해 존재합니다. 각 프로세싱은 Near-end Stream과 Far-end Stream의 APM에서의 효과 처리 과정이라고 이해해 주시면 됩니다. 위에서 설명한 흐름에 대해 아래 그림으로 한번 더 확인해보시죠.   WebRTC APM의 대표적인 Submodules(WebRTC Branch: branch-heads/5736)     참고로 두 Stream의 프로세싱은 독립적이지 않습니다. 왜냐하면 상대방이 말하는 목소리가 다시 마이크로 들어가는 에코를 지워주기 위해서는 ProcessReverseStream()에서 신호를 분석 한 후에 ProcessStream()가 넘겨 받아 이 에코를 지워줘야 하기 때문입니다. (위에서 설명한 AEC의 역할!)   자, WebRTC의 APM은 이러한 구조로 이루어져있다는 것을 파악하였고, 여기에 저는 가우디오랩의 뛰어난 음원분리 기술인 GSEP-LD를 통합하고자 했는데요. 직관적으로 보면 NS 자리에 GSEP-LD를 대체하는 것이 좋을 것 같습니다만, 과연 그럴까요?   신호 처리의 관점에서는 그렇게 보일 수 있지만, 우리가 통합하고자하는 SDK는 인공지능 기반이기에 아직 확단할 수는 없습니다. AEC 전에 통합하는 것이 효과를 높일 수도 있고요, 혹은 반대로 아예 끝단에 통합을 하는것이 효과가 좋을 수도 있습니다.   ‘최적의 통합 위치는 기존 노이즈 제거 필터의 위치와 같을까요?’의 질문에 이어 숱한 의문들이 생겨납니다.   ‘다른 Submodule과의 Side-Effect는 없을까요?’ ‘NS와 GSEP-LD를 동시에 사용해보는건 어떨까요?’ ‘저주파 노이즈를 제거하기 위한 HPF 필터까지 굳이 사용해야 할까요?’ ‘AEC 동작 여부에 따라 GSEP-LD 성능은 어떻게 달라질까요?’     WebRTC의 APM을 분석해보니 테스트로 챙겨야할 것들이 생각보다 많았습니다. 이제 이러한 경우들을 견고하게 테스트하기 위한 방법을 알아보도록 합시다.   참고로 WebRTC에 다른 SDK를 Submodule로 통합하는 방법은 어렵지 않습니다. 본 글은 WebRTC Audio 파이프라인의 테스트 환경 구축에 대한 이야기에 한정하기에 자세히 다루지는 않습니다만, 짧게 설명드리자면 이렇습니다. WebRTC APM은 C++ 언어로 작성되어 있는데, 먼저 APM의 다른 Submodules과 동일하게 인스터스 및 상태를 관리하기 위해 Wrapper Class를 작성합니다. 그 이후에 실제 APM Class에 통합하고자하는 Wrapper Class 다른 Submodules을 참고해서 같은 방식으로 관리해주면 됩니다.     효과적인 통합을 위한 APM CLI 활용하기   이제 APM 모듈에 대한 이해를 바탕으로 견고한 테스트 환경을 구축하여 GSEP-LD의 결과를 얻어보도록 하겠습니다. 이를 위해서는 APM만 독립적으로 실행이 가능한 CLI(Command Line Interface)를 만들어 파일 출력 결과를 얻어보는게 효과적입니다. (실제로 들어보기도 해야하기 때문 입니다!)   저희가 파악한 효과적인 통합을 위해 APM CLI를 사용하는 방법은 2가지 입니다.   첫 번째 방법은 1)WebRTC 오픈 소스에서 바로 사용이 가능한 방법이며, 두 번째 방법은 2)WebRTC APM만 단독으로 있는 오픈소스 프로젝트를 활용하는 방법 입니다.     1) WebRTC 오픈 소스에서 바로 사용이 가능한 방법   WebRTC 오픈 소스는 링크에서 바로 확인이 가능합니다. WebRTC 프로젝트에는 플랫폼 별 빌드 방법에 대한 가이드가 자세히 나와있습니다. 소스 코드를 받고 가이드를 따라 필요한 소프트웨어들을 설치하고 빌드가 성공했다면, APM CLI를 사용할 수 있는 준비 끝입니다!   빌드 경로를 확인하면 산출물로 APM의 파일 모드 테스트 툴인 audioproc_f을 확인할 수 있습니다. audioproc_f를 활용한다면, APM에 WAV 파일을 입력하여 APM의 오디오 필터 효과가 적용된 결과를 얻을 수 있습니다. Default 옵션으로 APM 수행 결과 확인하기 위해서는 아래와 같이하면 됩니다.   $ ./audioproc_f -i INPUT.wav --all_default -o OUTPUT.wav   세부 옵션을 사용하면, 구체적인 테스트 환경을 시험하는 것도 가능합니다. 이번에는 Near-, Far-End 간의 Stream Delay를 30ms로 설정하고, Noise Suppressor를 켜보도록 하겠습니다. 여기서 Stream Delay란 하드웨어 및 시스템에 의한 지연을 의미합니다. 참고로 AEC의 성능을 높이기 위해서는 Near-, Far-End 간의 Stream Delay를 정확히 기술해야 하는 것이 중요하기 때문에 때문에 테스트 시에 유의해야할 파라미터 입니다.   ./audioproc_f -i INPUT.wav --use_stream_delay 1 --stream_delay 30 --ns 1 -o OUTPUT.wav     2) WebRTC APM만 단독으로 있는 오픈소스 프로젝트를 활용하는 방법   첫 번째 방법으로도 충분한 테스트를 해볼 수 있을 겁니다. audioproc_f 소스 코드를 수정한다면 견고한 테스트 환경 구축할 수도 있겠죠. 하지만 WebRTC 프로젝트에는 오디오 이외의 불필요한 다른 멀티 미디어 소스 코드들(비디오, 데이터 네트워크 소스 코드, 오디오만 하더라도 ADM, ACM 등 다른 모듈 등..)도 함께 있어 불편한 단점이 있습니다. 그래서 필요한 부분(APM)만 눈에 보이고 좀 더 경량화된 테스트 환경을 구축할 수는 없을까 고민을 하게 되었는데요. 우리는 WebRTC의 APM 모듈만 떼어서 테스트를 구성하는 건 어떨까 고민하던 중 괜찮은 오픈 소스 프로젝트를 발견했습니다. 이 것이 바로 두 번째 방법입니다.   두 번째 방법에서 사용한 오픈 소스의 링크 입니다. 해당 프로젝트는 WebRTC의 APM만 분리해내어 Meson 빌드 시스템을 활용해서 빌드할 수 있는 프로젝트 입니다.   여기서 잠깐! Meson은 CMake 같은 다른 빌드 시스템 보다 빠르게 코드를 빌드할 수 있고, 직관적인 문법 덕분에 다루기 쉽다는 장점이 있는 차세대 C++ 빌드 시스템 입니다. 게다가 테스트 케이스를 다루는 방법도 정말 편리하고 테스트 구조를 쉽게 관리 할 수 있습니다. Meson에서 유닛 테스트를 작성하려면, 테스트 코드를 포함하는 테스트 실행 파일을 생성하고, 해당 파일에서 테스트 코드를 작성합니다. 그런 다음 test() 함수를 사용하여 테스트를 정의하고 Meson에 테스트를 실행하도록 지시합니다. 예를 들어, 다음과 같은 코드를 작성할 수 있습니다.   test('test_name', executable('test_executable', 'test_source.cpp'), timeout: 10)   이 코드는 test_name이라는 이름의 테스트를 정의합니다. 그리고 test_source.cpp 파일에서 빌드된 테스트 실행 파일 test_executable를 실행하여 테스트를 수행합니다. timeout 매개 변수는 테스트가 수행되는 시간을 초 단위로 지정합니다. 만약 지정된 시간 이내에 테스트가 완료되지 않으면 실패로 처리됩니다. 참고로 테스트 실행 파일에는 Arguments도 받을 수 있으니 테스트 마다 다른 값을 적용해서 다양한 케이스를 커버할 수 있습니다.   Meson 빌드 시스템의 쉬운 테스트 코드 작성 방법을 알아 보았습니다. 다음으로 GSEP-LD를 통합하기 위한 테스트를 구성해볼 차례 입니다. 아래 그림이 저희가 구성했던 테스트(실제로 테스트 해본 것보다는 간략화되어 있지만) 설계를 잘 보여줍니다.       GSEP-LD 통합 테스트 구성     먼저 테스트를 크게 2가지 그룹으로 나누었습니다. WebRTC에는 2가지 Stream Near-, Far-end Stream 2가지 존재하는 것, 알고 계시죠? 이를 각각 그룹(A)과 그룹(B)로 나누었습니다.   두 그룹의 큰 차이는 에코를 지워주는 AEC의 동작 유무입니다. (Near-end만 켜지는 그룹은 AEC가 off 상태, Near-, Far-end Stream 모두 사용할 때에는 AEC on 상태입니다.)   각 그룹에 입력되는 파일 구성도 차이가 있습니다. 그룹(A)의 경우에는 마이크를 통해 말하는 소리에 노이즈가 더해진 신호만 입력하면 됩니다. 하지만 그룹(B)에는 스피커에서 나오는 신호(=상대방이 말하는 신호)와 이 스피커에서 나오는 신호가 에코로 다시 들어가는 환경을 모사해주어 합니다. 이 역할을 하는 것이 echo_generator입니다. echo_generator로부터 나온 에코와 마이크를 통해 말하는 신호를 더해주면 그룹(B)의 입력 신호가 완성됩니다.   다음으로 GSEP-LD를 제어하기 위해서 통합 자리와 동작 여부를 제어했습니다. 통합 자리는 프로세싱의 맨 앞쪽(Pre-processing), 기존 노이즈 제거 필터의 자리, 그리고 맨 끝쪽(Post-processing)으로 제어하였습니다.   다른 Submodule과 사이드 이펙트도 볼 필요가 있겠죠? NS와의 사이드 이펙트를 살펴보도록 합시다. NS와의 Side-effect 검증을 위해서 끄거나 켜보고 얼마나 노이즈를 제거할지 Parameter 값을 설정하였습니다. 참고로 NS에서 얼마나 노이즈를 제거할지 Parameter 값은 Low ~ VeryHigh까지 설정이 가능한데, 너무 큰 값을 사용하면 음질에 왜곡이 심해지는 것을 확인할 수 있습니다.   끝으로 입력 파일의 소음을 타입별로 나누었습니다. 카페에서의 소음, 자동차 소음, 빗소리 등 다양한 소음의 종류를 테스트로 분류하였습니다. 자, 이 정도로만 해도 테스트의 가지수가 꽤 많습니다. (각 독립적인 가지수가 곱해지기 때문에…) 하지만 Meson 빌드 시스템의 테스트 기능을 활용한다면 for-loop 몇번으로 쉽게 만들 수 있습니다. 아래는 Meson 빌드 파일을pseudo code로 적어보았습니다.       이렇게 작성하면 테스트 코드의 완성입니다. 이제 Meson 명령어를 통해서 작성된 테스트 코드를 실행하면 우리가 구분한 테스트 가지 수 모두를 커버하며 출력 결과를 얻을 수 있습니다.     테스트가 잘 수행되어 출력 결과를 만드는 중     테스트가 잘 수행되었는지 지표로 체크     결론   WebRTC처럼 여러가지 기술들이 포함된 프로젝트에 제 3의 기술을 통합해보는 꽤 신경 써야 할 일이 많습니다. 통합 자리 선정을 위해서 전체적인 흐름을 이해해야 하고, 다양한 환경에서의 통합을 고려해야 합니다. 통합 위치, 사용 환경, 기존의 다른 기술들과의 Side-Effects등 말이죠. 위에서 언급된 내용은 당장 간단한 경우만 고려한 것입니다. 그럼에도, 노이즈 타입(5가지) x AEC On/Off(2가지) x NS 설정(5가지) x GSEP On/Off(2가지) = 100가지의 케이스!   이렇게 100가지의 케이스를 고민해야 합니다. 하지만 실제로는 노이즈 타입도 더 다양하게 테스트해봐야할 필요가 있으며, NS 이외의 Submodules 까지 고려를 하고, 플랫폼 별(Windows, MacOS, …) 까지 고려하면 테스트 가지수가 곱으로 많아지죠. 그리고 테스트를 위해서 GSEP 위치를 더 다양한 위치에 제어해보게 된다면 머리가 복잡해집니다. 😇   이번 글에서는 이러한 복잡한 가지수를 좀 더 쉽게, 그리고 경량화된 CLI 환경으로 테스트 해 본 경험을 소개해보았습니다. WebRTC의 APM만 분리해놓은 오픈 소스 프로젝트, Meson 빌드 시스템의 Test 기능 등을 활용하면 비교적 쉽게 환경을 구축할 수 있다는 것을 경험하였습니다. 앞으로 WebRTC에 여러분들이 붙여보고 싶은 오디오 필터가 있다면, 이 글이 조금이라도 테스트하는데 있어 도움이 되길 바라며 마치도록 하겠습니다. 읽어주셔서 감사합니다.   아참, WebRTC에 가우디오랩 만의 오디오 SDK를 통합하여 서비스를 만들고 싶으신 분! 언제든 환영합니다. 그리고 WebRTC의 오디오 파이프 라인에 대해 알려주셨으며, 그리고 WebRTC APM만 단독으로 있는 오픈소스 프로젝트를 활용하는 아이디어를 주신 쎄오에게도 땡큐!    

2023.06.23
after-image
Spatial Audio의 성능 평가 Part 1: 평가 설계

Spatial Audio의 성능 평가 Part 1: 평가 설계 (Writer: James Seo)   오랜만에 돌아온 GSA* 연구/개발 담당 James 입니다. 지난 글에서는 GSA가 사용자의 움직임에 얼마나 민첩하게 반응하는지를 나타내는 M2S (Motion-to-Sound) Latency 를 어떻게 측정할 수 있는지에 대해서 설명드렸습니다. 이번 글에서는 ‘그래서 실제 우리가 듣는 그 소리는 진짜 좋아?’에 대한 답을 찾아보려고 합니다. GSA는 TWS나 HMD와 같은 Wearable 기기를 타겟으로 한 제품인 만큼 그 소리가 좋지 않으면 움직임에 아무리 빨리 반응한다고 해도 좋은 제품이라고 할 수 없기 때문이죠. Sound Matters! *GSA: Gaudio Spatial Audio Methods of Audio Quality Evaluation   GSA의 성능 평가에 대해 설명하기 전에 우선은 음질 평가 방법에 대해 간단히 알아보겠습니다.   어떤 음향 기기 또는 음향 시스템의 성능을 평가하는 방법에는 여러가지가 있습니다. 그 중 하나가 재생하는 소리로부터 추출한 파라미터 값을 기반으로 성능을 평가하는 방법입니다. 지난 번의 M2S latency 측정이 그 대표적인 예가 되겠네요. 그 외에 오디오 / 음성 코덱의 성능을 평가할 때 자주 사용되는 PEAQ (Perceptual Evaluation of Audio Quality) / PESQ (Perceptual Evaluation of Speech Quality) 와 같이 표준으로 공인된 방법도 있습니다.   보통 이 방법들에서는 개별 소리를 분석하여 인지적 품질에 영향을 미치는 요소인 MOVs (Model Output Variables)를 계산하고, 이 값들의 가중합을 이용하여 최종 품질 점수를 도출합니다. 이러한 평가 방법을 객관 평가 기법(Objective Quality Evaluation)이라고 합니다. 이러한 객관 평가 기법은 기본적으로 음향 신호를 소프트웨어나 기기에 입력 신호로 주고, 최종적으로 품질 점수를 계산하는 방식이기 때문에 소요 시간이 비교적 짧아 효율적이라는 장점이 있습니다.   다만, 표준으로 제정되어 있는 객관 평가 기법들은 기준 신호(Reference Signal)가 있고, 평가하고자 하는 신호(Signal Under Test, SUT)가 기준 신호와 비교하였을 때 얼마나 그 품질이 떨어졌는지를 평가하는 방식이기 때문에 기준 신호가 없으면 평가 자체가 불가능하다는 단점을 가지고 있습니다. 이러한 표준 기법들이 코덱의 성능을 평가하고자 만들어진 기법이기 때문에 갖고 있는 한계이기도 합니다.   또 다른 평가 방법으로는 주관 평가 기법(Subjective Quality Evaluation)이 있습니다. 평가자가 평가 대상 음원을 비교하여 듣고 평가자의 기준으로 음원의 품질을 평가하는 방법입니다. 대표적인 평가 방법으로는 MUSHRA( Multiple Stimuli with Hidden Reference and Anchor)가 있습니다. 다만, 평가자마다 기준이 다를 수 있기 때문에, 신뢰도 있는 결과를 얻기 위해서는 평가자의 모수가 커야 한다는 단점이 있습니다. 평가자도 많아야 하지만 평가자가 직접 듣고 평가하는 방법이기 때문에 시간과 비용이 많이 든다는 것도 단점입니다. 마지막으로 그 명칭(Hidden Reference and Anchor)에서도 알 수 있듯이, 기준 신호가 있을 때에만 사용할 수 있다는 한계도 동일하게 갖고 있습니다.   이제 우리는 어떤 방법으로 GSA를 평가할지 선택해야 합니다. 우선 공간 음향이 적용된 오디오 신호에는 마땅한 기준 신호가 존재하지 않기 때문에 PEAQ와 같은 객관 평가 기법은 사용할 수 없습니다. 동일한 이유로 주관 평가 기법 중 하나인 MUSHRA도 사용할 수 없습니다. 또한 GSA의 출력 신호만을 가지고 주관 평가를 진행하는 것이 평가자들에게는 굉장히 어려운 일이기도 하고, 신뢰성 있는 결과를 얻기도 힘들다는 한계도 있습니다. 이러한 고민 끝에 선택한 방법이 시중에 있는 솔루션 중, 많이 사용되어 익숙하고 그 품질도 우수하다고 널리 알려진 솔루션과 비교하는 방법입니다. 후보가 되었던 공간 음향 솔루션이 몇 가지 있긴 하지만, 비교 대상 시스템이 늘어날 수록 비교해야 하는 신호가 늘어나고, 이러한 부담이 평가자들에게 큰 부담이 되어 평가 결과의 신뢰도를 낮출 수 있기 때문에 비교 대상 시스템을 Apple의 Spatial Audio(이후, 표현의 편의를 위해 ASA로 표기하겠습니다) 하나로 한정하여 1:1 비교하는 방법을 선택하였습니다.    새로운 주관 평가 설계(Design of Subjective Quality Evaluation)   (1) Paired Comparison (쌍비교)를 통한 Preference Test   기본적인 비교 방법은 Paired Comparison(쌍비교) 를 통한 Preference Test(선호도 테스트)입니다. 두 개의 신호를 랜덤한 순서로 들려주고, 어느 쪽을 선호하는지 조사하는 방법인데요, ‘선호’로 선택된 시스템에는 +1점, 선택되지 않은 시스템에는 0점을 부여하는 식으로 점수를 카운트 합니다. 엄마가 좋아? 아빠가 좋아? 와 같은 질문이라고 보시면 되겠습니다. 본 평가는 이중 맹검 강제 선택(Double-Blind Forced Choice) 방법을 사용하므로, 평가자는 지금 내가 듣고 있는 소리가 ASA로 렌더링 된 소리인지, GSA로 렌더링 된 소리인지는 알 수 없습니다. 평가자는 그저 신호를 듣고 랜덤하게 재생되는 A,B 두 개 중 더 선호하는 쪽 하나를 고르는 것이므로 평가자의 의도된 편향은 없다고 봐도 될 것입니다.   (2) Selection of Sound Excerpts   다음으로는 평가 음원을 골라야 합니다. 솔루션에 따라서는 음원의 특성 및 포맷(채널 수)에 따라 그 성능의 편차를 보이는 경우도 있기 때문에 어떤 음원으로 평가하느냐에 따라 그 결과가 달라질 수 있습니다. 우선 2채널 스테레오 음원과 5.1 채널 멀티 채널 음원을 구분하여 선정했습니다. 일반 사용자들이 보통의 환경에서 가장 많이 접할 수 있는 음원은 2채널 스테레오 음원이나, 영화나 일부 음악 소스의 경우 공간감을 더 잘 느낄 수 있도록 5.1채널 음원으로 믹싱되기도 하기 때문에 5.1 채널 음원까지 포함시키기로 하였습니다.   스테레오 음원의 경우 음악에서는 여러 장르별로 한 곡씩을 선택하였고, 여기에 스테레오 버전의 영화 클립 일부를 추가하여 총 7개의 음원을 선정했습니다. 멀티 채널 음원 역시 영화, 음악, 박수 소리 등 여러 특성을 가지고 있는 7개의 음원들을 선정했습니다. 선정된 음원은 주관 평가 시 가장 적절한 길이인 10~15초 사이로 잘라서 사용하였습니다.   (3) 평가 대상 신호의 생성 Generation of Signals Under Test   이번 평가의 목적이 사용자의 움직임에 맞게 변하는 Spatial Audio의 품질을 측정하는 것이기 때문에, 실제 사용자의 움직임을 반영하여 각 평가 대상 음원을 렌더링 하는 것이 이상적일 것입니다. 하지만 ASA의 폐쇄성 때문에  이상적인 실험 환경을 구축하는데 한계가 있었습니다. ASA는 Apple 제품군 내에서만 동작하기 때문에, 다른 Spatial Audio 렌더러를 Airpods Pro 나 iPhone에 구현하고, 이를 평가 대상자들이 모르게 재생하는 것이 불가능한 구조입니다. 이러한 이유로 고정된 Head-orientation에 대해 렌더링된 신호를 별도로 생성해서 비교할 수 밖에 없었는데요, 이 때 선정된 Head-orientation은 사용자가 가장 많이 경험하게 될 정면을 선정하였습니다.   여기서 또 하나의 어려움이 발생합니다. Apple 제품 내에서만 동작하는 ASA의 소리를 어떻게 획득할 수 있느냐의 문제입니다. 하지만 다행히도 가우디오랩에서는 ASA에서 동작하는 필터들을 획득할 수 있었는데요, 현재는 iOS버전이 업데이트 되면서 그 획득 경로가 막혀있지만, 한 때는 Spatial Audio 기능을 켜고 음원을 재생하면 Airpods Pro와 같은 TWS로 전송되는 신호를 획득할 수 있어 이를 활용하였습니다.   이렇게 재생하고자 하는 음원을 iPhone에서 재생하고 실제 렌더링된 신호를 획득하는 것도 방법이겠지만, swept sine 과 같은 신호를 이용하면 ASA의 필터 계수 자체를 획득할 수도 있습니다. 이렇게 획득한 필터와 음원을 합성한 후 Airpods Pro 로 재생하면 실제 iPhone/AirPods Pro에서 Spatial Audio가 적용되어 렌더링 된 소리와 동일하게 재생됩니다. 이런 방법 외에 약간의 오차가 존재하지만 ear simulator에 Airpods Pro를 장착하고, ASA 를 on/off 한 상태의 응답을 획득해서 TWS의 응답을 배제한 상태의 ASA 필터를 획득하는 방법도 있습니다만, 이렇게 필터 계수를 획득하는 방법은 이 글의 내용과 거리가 있기도 하고 다소 기술적인 내용이기에 건너뛰도록 하겠습니다.   청취 평가에서는 ASA와 GSA를 공정하게 비교하기 위해 음질 평가용 시료로는 AirPods Pro를 사용하였습니다. 이렇게 비교하면 최종 재생 Device의 차이로 발생하는 품질에 대한 영향은 최소화 하고, 공간 음향을 구현하기 위한 렌더러의 성능에 보다 집중해서 평가를 진행할 수 있게 됩니다.   이와 더불어 비교 대상에는 ASA나 GSA를 거치지 않은 원본 신호도 포함하였습니다. ASA와 GSA 사이의 우열만을 가리다가 둘 다 원본보다 못한 결과였다면 의미가 없을테니까요. 이 결과를 보면 공간 음향에 대한 평가자의 전반적인 원본 대비 선호도를 함께 비교해 볼 수 있겠네요. 5.1채널 음원은 5.1 ch-to-2 ch 로 다운믹스한 것을 원본 신호로 가정했습니다. 최종적으로 하나의 평가 음원(Audio Excerpt)에 대한 비교 음원은 아래와 같이 구성됩니다.   GSA (Gaudio Spatial Audio) vs. ASA (Apple Spatial Audio) GSA vs. Original ASA vs. Original   (4) 주관 평가 진행 환경 Environment of Subjective Quality Evaluation   실제 평가자가 주관 평가를 진행하는 환경은 아래와 같습니다. 그림에서 확인하실 수 있듯이 평가 음원(Audio Excerpt)의 이름만 알 수 있을 뿐, 평가자는 A와 B 에 ASA와 GSA, 그리고 원본 중 어떤 신호가 할당되어 있는지는 알 수 없습니다. 평가를 설계한 사람도 A와 B가 어떻게 할당되는지 알 수 없고, 어떤 음원이 먼저 평가 항목으로 나올지 역시 평가 설계자나 평가자가 선택할 수 없습니다. 음원의 순서도 시스템에서 임의의 제시 되기 때문에 음원의 순서 또한 결과에 영향을 미치지 않습니다.    위 화면에서 평가자는 두 개 중 더 좋다고 생각되는 하나를 선택하게 되고, Next Test 버튼을 누르면 다음 평가를 진행할 수 있습니다. 이것이 앞서 언급했던 이중 맹검 강제 선택 방법이죠. 한 음원을 평가하는 중에 특정 구간을 반복해서 들을 수도 있고, 반복 횟수의 제한은 없습니다. 해당 평가 시스템은 GAUDIO 서버에 설치되어 있어서 웹 기반으로 동작하기 때문에 여러 명이 동시에 평가를 진행할 수도 있습니다. 각 평가 세션이 끝나면, 결과 파일은 서버에 저장됩니다.    (5) 평가자 집단   이번 평가에는 20대~40대의 총 20명의 성인 남,여가 참가했습니다. 20명 가운데, 11명은 이와 같은 청취 평가 경험이 풍부한 훈련된 평가자이고, 일반인 관점의 평가를 반영하기 위해 9명은 관련 기술 및 음질 평가에 문외한이나 평소 음악 청취 등에 관심이 많은 일반인을 포함하였습니다.    평가 결과는 Part 2에서 이어집니다.  

2023.07.13