기술 레퍼런스

BW64와 ADM: 국악 이머시브 마스터를 위한 기술 레퍼런스

검토일 2026-09-07

풍물패가 도는 원(圓)에서 chna 청크의 40바이트까지. 객체 기반·장면 기반 마스터를 준비하는 엔지니어, 그리고 "Atmos 딜리버러블"을 받아 들고 QC를 통과시키라는 말을 들은 연주자·프로듀서를 위한 실무 문서.

짧은 답

ADM(Audio Definition Model, 오디오 정의 모델)은 ITU-R 권고 BS.2076으로 규정된 공개 메타데이터 표준이며, 파일 안의 각 오디오 트랙이 무엇인지 — 고정된 스피커 채널인지, 움직이는 객체인지, 앰비소닉 성분인지 — 그리고 그 트랙들이 어떻게 하나의 프로그램으로 결합되는지를 기술한다. 이 메타데이터는 XML 형태로 BW64 컨테이너(ITU-R 권고 BS.2088) 안에 담긴다. BW64는 RIFF/WAVE의 64비트 확장이며, 고전 WAV의 4 GB 천장을 벗어나기 위해 존재한다. 이머시브 납품이 반복적으로 QC에서 반려되는 이유는 단순하다. 오디오와 메타데이터는 서로 다른 두 개의 물건인데, 파일 포맷 자체는 둘이 일치하도록 강제하지 않는다. fmt 청크의 채널 수와 chna 테이블의 트랙 수가 어긋나 있는 파일, 어떤 객체도 참조하지 않는 audioTrackUID, 시간이 거꾸로 흐르는 블록 포맷, XML에는 선언되었지만 디스크에는 프린트된 적 없는 bed — 이 모두는 파형 편집기에서는 아무 소리도 내지 않고, 렌더러에서는 치명적이다. ADM QC는 듣는 작업이 아니라 참조 무결성(reference integrity)을 검사하는 작업이다.

1. 풍물: 세계에서 가장 정직한 객체 기반 오디오

객체 기반 오디오가 왜 필요한지 설명할 때, 한국어 사용자에게는 굳이 비유를 만들 필요가 없다. 풍물이 이미 그 자체로 정답이다.

풍물은 야외에서, 원을 그리며, 걸어 다니면서 연주된다. 상쇠가 앞장서고 부쇠·징·장구·북·소고가 따라 돌며, 청중은 원 바깥에 서 있기도 하고 원 안에 들어와 있기도 하다. 진(陣)이 바뀌면 대형 전체가 회전하거나 나선으로 감겼다 풀린다. 즉, 모든 음원의 위치가 시간의 함수다. 장구잡이의 방위각은 30초 뒤에 90도 달라져 있고, 그것은 믹싱의 선택이 아니라 연주의 사실이다.

ADM의 audioBlockFormat은 정확히 이것을 기술하려고 만들어진 구조물이다. 하나의 객체에 대해 방위각(azimuth), 고도(elevation), 거리(distance) — 또는 직교 좌표 X/Y/Z — 와 게인, 크기(size), 확산도(diffuseness)를 담은 블록을 시간 순으로 나열한다. 정지한 객체는 블록 하나로 끝난다. 움직이는 객체는 블록의 수열이 된다. 풍물의 상쇠는 정의상 블록의 수열이다.

여기서 중요한 것은 채널 기반 표현으로는 이것을 표현할 방법이 아예 없다는 점이다. 7.1.4 bed에 풍물을 담으면, 상쇠가 오른쪽 뒤에서 왼쪽 앞으로 이동하는 사건은 여러 스피커 채널에 걸친 게인 자동화의 흔적으로만 남는다. 그 흔적은 되돌릴 수 없고, 재생 시스템이 다르면 궤적도 달라진다. 객체로 담으면 궤적은 숫자로 남고, 렌더러가 방에 실제로 있는 스피커에 맞춰 다시 계산한다.

1.1 사물놀이: 같은 음악의 정지된 형태

사물놀이는 풍물을 실내 무대에 앉혀 놓은 형태다. 꽹과리·징·장구·북 네 사람이 자리를 잡고 앉아 끝까지 움직이지 않는다. 음악적 어휘는 같고, 공간적 성격은 정반대다.

그래서 이 한 쌍은 ADM을 가르치기에 거의 실험실 조건에 가깝다.

  • 사물놀이 = 네 개의 정적 객체. 각 audioChannelFormat이 audioBlockFormat 하나만 가진다. rtime과 duration은 생략해도 된다(BS.2076은 블록이 둘 이상일 때만 두 값이 모두 있어야 한다고 규정한다).
  • 풍물 = 같은 네 종류의 악기, 그러나 각 객체가 수백 개의 블록을 가지며, 모든 블록에 rtime과 duration이 반드시 있어야 하고, 그 값들이 빈틈없이 이어져야 한다.

납품에서 반려되는 파일의 상당수는 "사물놀이처럼 만들다가 풍물이 된" 파일이다. 즉 정적 객체로 시작해 나중에 오토메이션을 그려 넣었는데, 익스포터가 첫 블록에는 rtime을 쓰지 않고 두 번째 블록부터 쓰기 시작한 경우다. 결과는 첫 블록이 시간축에서 정의되지 않은 파일이고, 렌더러에 따라 파싱을 거부하거나, 조용히 첫 구간을 통째로 무시한다.

1.2 원 안의 청중이라는 문제

풍물의 청중은 원 바깥에만 있지 않다. 판굿이 벌어지면 사람들이 원 안으로 들어가고, 연주자는 그 사람들 주위를 돈다. 이머시브 포맷의 관점에서 이것은 청취자가 음원 배치의 내부에 있다는 뜻이고, 이머시브가 스테레오보다 나은 이유가 바로 이 상황에서 드러난다. 스테레오는 청취자 앞쪽 60도 남짓의 부채꼴 안에만 사건을 놓을 수 있다. 풍물의 사건 절반은 그 부채꼴 바깥에서 일어난다.

동시에, 여기에는 함정이 있다. 객체를 청취자 뒤 가까운 거리에 놓으면 BS.2051 배치에 따라 재생 결과가 크게 갈린다. 뒤쪽 스피커가 두 개뿐인 배치(예: 시스템 B, 0+5+0)와 뒤쪽에 스피커가 넉넉한 배치(시스템 J, 4+7+0)에서 같은 궤적은 결코 같게 들리지 않는다. 그래서 궤적을 그릴 때는 어떤 배치에서 확인했는지를 납품 노트에 반드시 적어야 한다. 이 문서 뒤쪽에서 다시 다룬다.

1.3 움직이는 연주자를 어떻게 수음하는가 — 그리고 궤적은 어디서 오는가

풍물을 객체로 담자는 말은 쉽지만, 실제로 하려면 두 가지가 필요하다. 분리된 신호와 위치 데이터다.

분리된 신호는 무선 마이크로 얻는다. 상쇠와 장구잡이의 몸에 붙인 소형 마이크가 각각 하나의 모노 트랙이 되고, 그 트랙이 하나의 audioObject가 된다. 문제는 야외라는 점이다. 무선 대역이 붐비고, 바람이 있고, 연주자가 크게 움직이므로 케이블 마이크는 애초에 선택지가 아니다. 무선 채널 수가 곧 객체 수의 상한이 되며, 그래서 실제 현장의 풍물 이머시브 녹음은 대개 핵심 몇 사람만 객체로 잡고 나머지는 bed로 처리하는 절충으로 간다. 이것은 타협이지 실패가 아니다. 중요한 것은 그 절충의 결과가 ADM에 정직하게 반영되는 것이다. 객체로 잡지 않은 연주자를 XML에서 객체인 척 선언하면 안 된다. 그렇게 하면 참조 그래프는 멀쩡한데 궤적이 허구인 파일이 되고, 이런 종류의 거짓말은 어떤 검증기도 잡아내지 못한다.

위치 데이터는 더 까다롭다. 이상적으로는 연주자의 실제 이동을 추적해 좌표로 기록하지만, 그런 장비가 현장에 있는 경우는 드물다. 현실적인 방법은 영상과 함께 녹음하고, 나중에 영상을 보면서 궤적을 그리는 것이다. 진(陣)의 변화는 대개 몇 십 초 단위로 일어나므로 샘플 단위 정밀도가 필요하지 않다. 몇 초 간격의 블록으로도 충분히 설득력 있는 궤적이 만들어지며, 블록 수가 적을수록 검증도 쉬워진다.

여기서 앞서 말한 규칙이 곧바로 현실이 된다. 손으로 그린 궤적은 블록이 수백 개가 되고, 그중 하나라도 rtime이 빠지거나 순서가 어긋나면 파일 전체가 반려된다. 그러므로 궤적을 그리는 도구가 무엇을 내보내는지 반드시 확인해야 한다. 도구가 화면에 예쁜 곡선을 보여 준다는 것과, 도구가 규격에 맞는 블록 수열을 파일에 쓴다는 것은 서로 다른 이야기다. 익스포트한 파일의 axml을 열어 블록 몇 개를 눈으로 확인하는 것이 이 단계에서 할 수 있는 가장 값싼 검증이다.

2. 판소리: 객체 두 개와 방 하나, 그 이상은 아무것도 없다

판소리는 반대편 극단이다. 사람이 둘이다. 소리꾼과 고수. 작은 공연장에서 몇 미터 떨어져 있고, 그게 전부다.

이머시브를 "채널이 많이 필요한 것"으로 이해하는 사람에게 판소리는 반례가 된다. 여기서 필요한 것은 객체 두 개와 방 하나다. 소리꾼 하나, 고수 하나, 그리고 공간을 담는 bed. 128개의 객체가 아니라 두 개다. 이머시브 포맷의 가치는 트랙 수가 아니라 위치가 보존된다는 사실에 있다.

2.1 추임새는 위치가 있는 말이다

판소리에서 고수는 북만 치지 않는다. "얼쑤", "좋다", "그렇지" — 추임새를 넣는다. 추임새는 반주가 아니라 대화의 절반이다. 그리고 그것은 특정한 지점에서 나온다. 소리꾼의 왼쪽 혹은 오른쪽, 조금 낮은 높이, 몇 미터 거리.

이 위치를 잃으면 형식 자체가 작동을 멈춘다. 추임새를 소리와 함께 센터로 패닝해 버리면, 두 사람이 주고받는 구조가 한 사람이 혼잣말하는 구조로 바뀐다. 스테레오 믹스에서 이것이 흔히 벌어지는 이유는 단순하다. 소리꾼과 고수를 같은 방향에서 근접 수음하고, 마스터링 단계에서 둘 다 가운데로 모으면 라우드니스와 모노 호환성이 좋아지기 때문이다. 좋아지는 것은 계측값이고, 사라지는 것은 판소리다.

ADM으로 납품할 때 이 문제는 기술적으로 아주 간단하게 해결된다. 두 개의 Objects 타입 audioChannelFormat, 각각 블록 하나, 서로 다른 azimuth 값. 확인해야 할 것은 두 객체의 방위각이 실제로 다른가, 그리고 그 차이가 최종 스테레오 컨폼(conform)에서도 살아남는가 뿐이다. 후자가 자주 실패한다. 이머시브 마스터에서는 두 사람이 떨어져 있는데, 자동 생성된 스테레오 폴드다운에서는 다시 붙어 버리는 파일을 흔히 본다.

2.2 완창의 파일 크기 — 그리고 4 GB 벽

판소리 완창은 짧지 않다. 다섯 바탕 중 어느 것이든 완창은 몇 시간 단위로 간다. 여기서 BW64가 왜 필요한지가 산술로 드러난다.

5.1.4 bed(10채널) + 객체 4개 = 14트랙, 96 kHz / 24비트로 녹음했다고 하자.

  • 초당 바이트 = 14 × 3바이트 × 96 000 = 4 032 000 B/s
  • 4시간(14 400초) = 4 032 000 × 14 400 = 58 060 800 000바이트 ≈ 58.06 GB
  • 고전 RIFF의 한계는 2³² = 4 294 967 296바이트다.
  • 58 060 800 000 ÷ 4 294 967 296 ≈ 13.5배

즉 이 파일은 WAV로 존재할 수 없다. 존재하려면 BW64여야 한다.

2.3 시나위: 정적과 가변 사이

판소리와 풍물 사이에 시나위가 있다. 즉흥 합주이고, 연주자는 무대 위에서 크게 이동하지는 않지만 서로를 향해 몸을 돌리고, 솔로를 주고받으며 앞으로 나왔다 물러난다. ADM 관점에서 이것은 거의 정적이지만 완전히 정적이지는 않은 객체 집합이며, 실무적으로 가장 판단이 어려운 경우다.

두 가지 접근이 모두 방어 가능하다. 하나는 각 연주자를 정적 객체로 두고 이동을 무시하는 것 — 블록 하나, 타이밍 없음, 검증이 단순하다. 다른 하나는 몇 개의 큰 블록으로 구간을 나누는 것 — 예컨대 솔로가 바뀔 때마다 새 블록을 열어 그 연주자를 살짝 앞으로 당기는 것이다. 후자를 택했다면 모든 블록에 rtime과 duration이 있어야 하고 연속성이 지켜져야 한다는 규칙이 즉시 적용된다. 블록을 두 개 이상 만드는 순간 파일의 검증 요구사항이 달라진다는 점을 기억하는 것이 중요하다.

3. 국악관현악단: 좌석표가 곧 채널 기반 bed다

국악관현악단은 정반대 방향의 교과서 사례다. 여기서는 배치가 이미 정해져 있다.

가야금·거문고·해금·아쟁이 어느 열에 앉고, 대금·소금·피리가 어디에 서고, 타악이 뒤쪽 어디에 놓이는지는 지휘자와 악단이 리허설 전에 확정한다. 연주 중에 자리를 바꾸는 사람은 없다. 이것은 정확히 채널 기반(channel-based) 표현이 기술하는 상황이다. 각 트랙이 고정된 스피커 위치에 대응하고, 그 위치는 재생 시스템이 바뀌어도 변하지 않는다. ADM에서는 DirectSpeakers typeDefinition, typeLabel 0001을 쓴다.

국악관현악단 녹음의 현실적인 형태는 대개 이렇다. bed 하나에 홀 전체를 담고, 협연자만 객체로 뺀다. 협주곡에서 가야금 독주자 한 명, 혹은 대금 독주자 한 명. 그 사람은 무대 앞쪽 특정 지점에 있고 그 지점이 음악적으로 의미가 있으므로 객체가 될 자격이 있다. 나머지 60명은 bed다. 60명을 각각 객체로 만드는 것은 기술적으로 가능하지만 음악적으로 아무 의미가 없고, 파일만 거대해지며, chna 테이블에서 틀릴 기회만 60배로 늘어난다.

3.1 대비: 산조 듀오

산조는 연주자가 둘이다. 가야금(또는 거문고, 해금, 대금) 하나와 장구 하나. 국악관현악단과 같은 논리를 적용하면 답이 반대로 나온다. 여기서는 bed가 거의 필요 없고, 객체 두 개와 방의 잔향이면 충분하다. 산조에서 두 연주자의 상호작용 — 장단을 밀고 당기는 관계 — 은 둘이 공간적으로 분리되어 있을 때 훨씬 명료하게 들린다.

정리하면 판단 기준은 트랙 수도 예산도 아니고 이것 하나다.

음원의 위치가 미리 정해져 있고 변하지 않으면 채널 기반이 옳다. 위치가 음악적으로 의미가 있거나 시간에 따라 변하면 객체가 옳다. 공간 그 자체가 대상이면 장면 기반이 옳다.

3.2 결정표: bed인가 객체인가

현장에서 매번 다시 논쟁하지 않으려면 기준을 문서로 고정해 두는 편이 낫다.

소재권장 표현이유
국악관현악단 총주채널 기반 bed (7.1.4 또는 5.1.4)좌석 배치가 리허설에 확정되고 변하지 않는다
협주곡의 독주자객체 1개 + bed위치가 음악적으로 유의미하며 bed와 분리되어야 한다
사물놀이정적 객체 4개 (+ 방을 위한 bed)위치가 고정이지만 개별 정위가 형식의 일부다
풍물시간 가변 객체 다수연주자가 실제로 이동한다
판소리객체 2개 + bed두 사람, 대화 구조, 그 이상 없음
산조 듀오객체 2개, bed 최소상호작용이 공간 분리에서 드러난다
대웅전 독송·범패장면 기반 (HOA)개별 음원 분리가 무의미하고 공간이 대상이다
범종객체 1개, 시간 가변 diffuseness/size점 음원에서 확산 음장으로 변해 간다

표의 오른쪽 열이 핵심이다. 선택의 근거는 언제나 소리가 어디서 나는가에 대한 사실이지, 채널이 몇 개 남았는가가 아니다.

4. 범종과 범패: 실제 높이, 실제 거리

한국 불교 사찰의 음향 환경은 이머시브 포맷이 실제로 무엇을 담는지 보여 주는 드문 예다.

범종은 종각에 걸려 있다. 즉 음원이 청취자보다 실제로 높은 곳에 있고, 실제로 멀리 있다. 이것은 믹싱에서 만들어 낸 고도가 아니라 물리적 사실이다. ADM 객체의 elevation과 distance 파라미터는 바로 이런 것을 위해 존재한다. 그리고 범종은 친 뒤에 소리가 사라지기까지 매우 긴 시간이 걸린다. 그 긴 감쇠 구간 동안 소리는 종에서만 나오는 것이 아니라 종각과 산자락, 마당 전체에서 되돌아온다. 즉 처음에는 명확한 점 음원이었던 것이 시간이 지나면서 공간 전체로 번진다.

ADM은 이 변화를 기술할 수단을 가지고 있다. audioBlockFormat의 diffuseness(확산도)와 size(크기)를 시간에 따라 변화시키면, 초기 타격 구간에서는 좁고 확정적인 객체였다가 감쇠 구간에서는 넓고 확산된 객체가 되는 궤적을 만들 수 있다. 이것은 리버브 플러그인으로 흉내 내는 것과 근본적으로 다르다. 리버브는 렌더링 이전에 신호에 구워지지만, diffuseness는 메타데이터로 남아 재생 시스템이 무엇이든 그 시스템에 맞게 다시 계산된다.

범패와 사찰의 염불은 또 다른 문제를 던진다. 스님들의 독송은 대웅전 안에서 여러 사람이 함께 하며, 개별 음원을 분리하는 것이 음악적으로 무의미하다. 소리는 개인이 아니라 무리에서 나오고, 무리와 공간은 분리되지 않는다. 이것은 장면 기반(scene-based), 실무적으로는 고차 앰비소닉(HOA)이 옳은 경우다. ADM에서는 typeDefinition HOA, typeLabel 0004. 앰비소닉의 어느 성분도 그 자체로 특정 방향을 뜻하지 않고, 방향은 성분들의 선형 결합에서 나타난다. 대웅전 안에서 사방으로 울리는 독송을 담기에 이보다 나은 표현은 없다.

5. 세 가지 오디오 유형, 형식적으로

앞의 사례들을 규격 용어로 정리한다.

채널 기반(Channel-based). 각 트랙이 고정된 확성기 위치에 대응한다. 스테레오가 그렇고, 5.1이 그렇고, 7.1.4 "bed"가 그렇다. 위치는 채널 정체성 자체에 박혀 있다. 3번 트랙은 센터 스피커이고, 그것을 재생하는 모든 시스템에서 센터 스피커다. ITU-R BS.2051은 이를 형식화하여 확성기 배치를 상단 + 중간 + 하단 층별 개수로 정의한다. 시스템 A는 0+2+0(스테레오), 시스템 B는 0+5+0(5.1), 시스템 D는 4+5+0, 시스템 J는 4+7+0, 시스템 H는 9+10+3 — 즉 22.2다. ADM에서는 DirectSpeakers, typeLabel 0001.

객체 기반(Object-based). 모노(또는 다채널 팩) 신호에 시간에 따라 변하는 위치 메타데이터가 붙는다. 실제 방에 존재하는 배치를 보고 어떤 스피커로 어떻게 재생할지는 렌더러가 결정한다. 트랙 자체는 스피커를 전제하지 않는다. typeDefinition Objects, typeLabel 0003.

장면 기반(Scene-based). 실무적으로 고차 앰비소닉. 음장(音場) 전체를 구면조화 성분의 집합으로 부호화한다. typeDefinition HOA, typeLabel 0004.

ADM은 이 밖에 M/S나 Lt/Rt 같은 매트릭스 신호를 위한 Matrix(0002), 헤드폰용 쌍을 위한 Binaural(0005)도 정의한다.

Matrix와 Binaural은 국악 납품에서 자주 쓰이지는 않지만 알아 둘 필요는 있다. Matrix는 M/S 수음처럼 행렬 연산으로 다른 신호를 만들어 내는 경우를 기술한다. 국악 실황에서 M/S 페어를 메인으로 쓰는 경우가 드물지 않으므로, 그 페어를 디코드하지 않은 채로 납품한다면 Matrix가 정확한 표현이다. Binaural은 이미 헤드폰용으로 완성된 쌍을 뜻하며, 렌더러가 다시 처리해서는 안 되는 신호라는 뜻이기도 하다. 바이노럴 컨폼을 DirectSpeakers 스테레오로 잘못 선언하면 재생 체인에서 두 번 처리될 수 있다.

이것이 분류학을 위한 분류학이 아닌 이유는 다음 한 문장에 있다.

채널 기반 딜리버러블은 메타데이터가 없어도 어느 정도 스스로를 설명한다. 채널 순서만 맞으면 재생된다. 객체 기반·장면 기반 딜리버러블은 메타데이터가 없으면 의미가 없다. 오디오는 구별되지 않는 모노 스트림 더미이고, 그것이 아니라고 말해 주는 것은 ADM뿐이다.

BW64와 ADM이 존재하는 이유가 이 비대칭이며, 이머시브 QC가 스테레오 QC보다 어려운 이유도 이 비대칭이다.

6. BW64는 왜 존재하는가 — 4 GB 벽의 산술

고전 WAV는 RIFF 파일이다. 1991년의 RIFF는 모든 청크 앞에 32비트 크기 필드를 둔다. 32비트가 주소 지정할 수 있는 범위는 2³² = 4 294 967 296바이트, 곧 4 GB이며, 이것이 파일 전체와 data 청크 양쪽에 걸리는 단단한 상한이다.

숫자를 실제로 계산해 보면 왜 이 한계가 스테레오에서는 문제가 아니고 이머시브에서는 즉시 문제가 되는지 분명해진다.

스테레오, 48 kHz / 24비트

  • 초당 바이트 = 2채널 × 3바이트 × 48 000 = 288 000 B/s
  • 4 294 967 296 ÷ 288 000 ≈ 14 913초 = 약 4시간 8분. 실질적으로 무관하다.

128트랙 객체 기반 마스터, 96 kHz / 24비트

  • 초당 바이트 = 128 × 3 × 96 000 = 36 864 000 B/s
  • 4 294 967 296 ÷ 36 864 000 ≈ 116.5초. 2분이 안 된다.

현실적인 국악 이머시브 세션: 7.1.4 bed(12채널) + 객체 16개 = 28트랙, 48 kHz / 24비트

  • 초당 바이트 = 28 × 3 × 48 000 = 4 032 000 B/s
  • 4 294 967 296 ÷ 4 032 000 ≈ 1 065초 = 약 17분 45초

산조 한 바탕이면 이미 넘는다. 판소리 완창이면 앞서 계산했듯 13.5배를 넘는다. 그리고 한계에 부딪힌 WAV 라이터가 만들어 내는 결과물은 잘린 파일이거나, 선언된 크기 값이 조용히 오버플로한 파일이다. 둘 다 열리기는 열린다.

샘플레이트 선택에 관한 실무적 조언 하나. 위 계산이 보여 주듯 96 kHz는 트랙 수가 많아지면 파일 크기를 곧바로 두 배로 만든다. 국악 녹음에서 96 kHz를 택할 만한 이유 — 예컨대 대금이나 태평소의 고역 성분, 편경·편종의 배음 구조 — 는 분명히 있지만, 트랙이 28개 이상인 이머시브 세션에서는 그 선택이 저장장치, 전송, 그리고 백업 시간 전체에 곱해진다. 48 kHz / 24비트로 충분한지를 먼저 판단하고, 96 kHz가 필요하다면 그 이유를 납품 노트에 적어 두는 편이 낫다. 그리고 무엇을 택하든, ADM을 작성한 뒤에는 절대로 바꾸지 않는다.

EBU가 이 문제를 먼저 RF64(EBU Tech 3306)로 해결했고, ITU가 그 작업을 이어받아 ITU-R 권고 BS.2088, Long-form file format for the international exchange of audio programme materials with metadata — 곧 BW64로 만들었다. BS.2088은 메커니즘을 명시한다.

"The ID 'BW64' is used instead of 'RIFF' in the first four bytes of the file." — ITU-R BS.2088

그리고 기존 32비트 필드는 탈출 신호로 바뀐다.

"If the 32-bit value in the field is 0xFFFFFFFF the 64-bit value in the 'ds64' chunk is used instead." — ITU-R BS.2088

트릭은 이것이 전부이며, 분명히 말해 둘 가치가 있다.

BW64는 RIFF의 크기 필드를 넓히지 않는다. 그 자리에 0xFFFFFFFF라는 보초값(sentinel)을 채워 넣고, 진짜 64비트 크기는 파일 맨 앞에 와야 하는 ds64 청크에 적는다.

BW64는 하나의 계보의 3세대로 이해하는 것이 정확하다. RIFF/WAVE가 청크 컨테이너를 주었고, Broadcast Wave(BWF, EBU Tech 3285)가 bext 청크 — 제작자, 타임코드 기준, 코딩 이력 — 를 더해 WAV를 방송 교환 포맷으로 만들었으며, BW64는 그 모두를 유지한 채 64비트 주소 지정과 ADM을 실어 나르는 청크들을 추가했다. 4 GB 미만인 BW64 파일은 파일 시그니처 네 글자를 빼면 WAV 리더와 바이트 단위로 호환된다. 많은 도구가 그냥 열어 주고, 일부는 완강히 거부한다. 국내 스튜디오에서 쓰는 도구 체인이 후자에 속하는지 여부는 납품 전에 반드시 확인해야 할 항목이다.

7. 청크 배치, 바이트 단위로

BS.2088에 따르면 BW64 파일은 최소한 <ds64-ck>, <fmt-ck>, <chna-ck>, <axml-ck>(대안 메타데이터 운반자로 <bxml-ck>, <sxml-ck>), 그리고 <wave-data>를 포함할 것으로 기대된다.

7.1 ds64 — 64비트 크기 테이블

BW64 시그니처 다음에 반드시 첫 번째로 와야 한다. 리더가 다른 무엇을 순회하기 전에 진짜 크기를 알아야 하기 때문이다. 필드는 64비트 값을 32비트씩 상·하위로 나눠 담는다.

필드바이트담는 것
ckID4'ds64'
ckSize4이 청크의 크기
bw64SizeLow / bw64SizeHigh4 + 4파일 전체의 64비트 크기
dataSizeLow / dataSizeHigh4 + 4data 청크의 64비트 크기
dummyLow / dummyHigh4 + 4예약 / 호환용
tableLength4뒤따르는 ChunkSize64 항목의 개수
table[]가변data 이외의 초과 청크를 위한 64비트 크기

산술을 확인해 두자. 헤더 8바이트(ckID + ckSize) 뒤에 오는 고정 본문은 8 + 8 + 8 + 4 = 28바이트이고, 테이블 항목이 하나도 없으면 ckSize는 28이며 청크 전체는 36바이트를 차지한다. 테이블 항목은 각각 4바이트 청크 ID + 8바이트 크기 = 12바이트이므로, 항목이 n개면 ckSize = 28 + 12n이다.

table[]은 보기보다 중요하다. 수천 개의 객체를 샘플 단위 오토메이션과 함께 기술하는 axml 청크는 그 자체로 4 GB에 근접하거나 이를 넘을 수 있다. data 이외의 청크가 64비트 크기를 선언할 수 있는 유일한 통로가 이 테이블이다.

7.2 fmt — 에센스(essence)의 기술

표준 WAVE 포맷 청크다. 샘플 포맷, 샘플레이트, 채널 수, 비트 심도, 블록 얼라인. data 안에 실제로 몇 개의 채널이 인터리브되어 있는지를 말해 주는 유일한 권위 있는 진술이 여기다. 그 아래의 모든 것은 그 채널들에 관한 메타데이터이며, 메타데이터는 거짓말을 할 수 있다.

7.3 chna — 채널 할당 테이블과 40바이트

chna는 물리 트랙과 ADM 사이를 잇는 다리다. 청크는 이렇게 시작한다.

  • ckID — 4바이트, 'chna'
  • ckSize — 4바이트
  • numTracks — 2바이트, 파일 안의 트랙 수
  • numUIDs — 2바이트, 뒤따르는 audioTrackUID 항목 수

그다음 고정폭 audioID 항목이 평평한 배열로 이어진다. 각 항목은 정확히 40바이트다.

필드바이트내용
trackIndex21부터 시작하는 물리 트랙 번호
UID12audioTrackUID 값, 예: ATU_00000001
trackRef14audioTrackFormatID 참조, 예: AT_00031001_01
packRef11audioPackFormatID 참조, 예: AP_00031001
pad1짝수 정렬용 패딩

2 + 12 + 14 + 11 + 1 = 40.

각 필드가 왜 그 폭인지 세어 보면 규격이 임의적이지 않다는 것을 알 수 있다. ATU_00000001은 접두사 4자(ATU_) + 16진 8자 = 12자. AT_00031001_01은 AT_ 3자 + 8자 + _ 1자 + 2자 = 14자. AP_00031001은 AP_ 3자 + 8자 = 11자. 필드 폭은 권고 사항이 아니라 고정폭 ASCII이며, 13자짜리 UID를 쓰는 라이터는 "조금 특이한" 테이블이 아니라 깨진 테이블을 만든 것이다.

실무적으로 유용한 산술 하나. 앞서의 28트랙 세션에서 트랙마다 UID가 하나씩이라면 chna 항목 배열은 28 × 40 = 1 120바이트이고, 여기에 numTracks·numUIDs 4바이트와 청크 헤더 8바이트를 더해 청크 전체가 1 132바이트다. chna 청크 크기를 40으로 나눈 나머지가 4가 아니면(헤더 제외 기준) 뭔가 잘못된 것이다. 파일을 열지 않고 크기만 봐도 걸러낼 수 있는 오류가 있다.

7.3.1 실제 chna 하나를 바이트로 세어 보기

말로만 두면 40바이트가 추상적이므로, 구체적인 세션 하나로 끝까지 계산해 보자. 7.1.4 bed(12채널) + 사물놀이 객체 4개 = 16트랙, 트랙마다 UID 하나.

  • numTracks = 16, numUIDs = 16
  • 항목 배열 = 16 × 40 = 640바이트
  • numTracks(2) + numUIDs(2) = 4바이트
  • 따라서 ckSize = 4 + 640 = 644바이트
  • 청크 전체(헤더 8바이트 포함) = 652바이트

파일 안에서의 오프셋도 항목 번호로부터 바로 나온다. 항목 배열의 시작을 오프셋 0이라 하면, k번째 항목(1부터)의 시작은 40 × (k − 1)이다. 13번 트랙 — 즉 12채널 bed 다음의 첫 객체, 꽹과리 — 의 항목은 오프셋 40 × 12 = 480에서 시작하고, 그 안에서 trackIndex는 480, UID는 482, trackRef는 494, packRef는 508, 패딩은 519에 놓인다. 다음 항목은 520에서 시작한다.

여기에 bed 채널의 packRef는 공통 정의를 가리키므로 0x0FFF 이하의 값을 갖고 XML이 필요 없지만, 객체 4개의 packRef는 0x1000 이상의 커스텀 값이어야 하고 axml에 대응하는 정의가 반드시 있어야 한다. 이 두 종류가 한 테이블 안에 섞여 있는 것이 정상이다. 테이블 전체가 커스텀 ID로만 채워져 있다면 bed를 객체로 잘못 선언했을 가능성이 높고, 전부 공통 ID라면 객체가 하나도 없는 순수 채널 기반 파일이다. 사물놀이를 객체로 담았다고 믿고 있는데 후자라면, 익스포터가 요청과 다르게 동작한 것이다.

ID 규약도 함께 봐야 한다. 0x0FFF 이하의 값은 ADM 공통 정의(common definitions) — 미리 정의된 표준 채널·팩 포맷 — 을 가리키고, 0x1000 이상은 axml 청크 안에 반드시 존재해야 하는 커스텀 정의를 뜻한다. AP_00010003은 공통 정의상 5.1이므로 XML이 필요 없다. AP_00031001은 커스텀 객체 팩이므로 XML이 없으면 참조가 끊긴다.

트랙 UID는 하나의 물리 트랙이 가진 정체성에 대한 파일 내부의 일련번호이며, 하나의 트랙이 프로그램 도중에 담는 내용을 정당하게 바꿀 수 있게 하려고 존재한다.

이 마지막 문장이 numUIDs가 numTracks보다 클 수 있는 이유다. EBU의 안내는 트랙의 오디오 요소가 파일 진행 중에 다르게 정의될 수 있으며 그 경우 정의마다 다른 UID가 생긴다고 설명한다. 따라서 같은 trackIndex가 여러 항목에 나타날 수 있다. 트랙당 UID가 하나라고 가정하는 QC 도구는 정상 파일을 오류로 표시한다. 풍물 실황에서 1부와 2부의 편성이 달라 같은 트랙이 앞에서는 장구, 뒤에서는 소고를 담는 경우가 정확히 이 상황이다.

7.4 axml — ADM 그 자체

UTF-8 XML 문서이며 <audioFormatExtended> 트리를 담는다. 이것이 ADM이다. 텍스트이고, 열어 볼 수 있고, 흥미로운 실패는 사실상 전부 여기 산다.

한글과 관련한 실무 주의사항이 하나 있다. audioProgramme, audioContent, audioObject에는 사람이 읽는 audioProgrammeName 같은 이름 속성이 붙는다. 여기에 "사물놀이 – 삼도설장고가락"처럼 한글을 쓰는 것은 규격상 아무 문제가 없다. UTF-8이므로 그대로 담긴다. 문제는 정규화 형식이다. macOS 계열의 파일 시스템은 한글을 자모 단위로 분해된 형태(NFD)로 다루는 경향이 있어서, macOS에서 만든 이름을 그대로 XML에 흘려 넣으면 "사물놀이"가 ㅅ+ㅏ+ㅁ+ㅜ+ㄹ… 형태로 저장될 수 있다. 겉보기에는 같지만 바이트열이 다르고, 문자열 비교로 참조를 검증하는 도구에서는 일치하지 않는다. 납품 전에 XML을 NFC로 정규화하고, 가능하면 ID 참조에는 한글을 쓰지 않는 것이 안전하다. ID는 AO_1001 같은 ASCII로 두고, 한글은 사람이 읽는 이름 속성에만 쓴다.

7.5 data — 인터리브된 PCM

WAV와 똑같은 평범한 인터리브 샘플이다. data 안의 그 무엇도 객체에 대해 아무것도 알지 못한다.

7.6 순서 — 그리고 모두가 빠지는 함정

ds64가 언제나 첫 번째. fmt 는 data보다 앞. 그런데 axml은 data 뒤에 놓여도 정당하며, 실제로 자주 그렇다. BS.2088이 지적하듯 녹음 중에는 XML 메타데이터의 길이를 알 수 없기 때문이다.

axml이 파일 꼬리에 있는 파일은 잘못된 파일이 아니다. 그러나 파일 앞부분 몇 메가바이트만 훑는 리더는 "ADM이 없다"고 보고한다. "내 파일에 메타데이터가 없다"는 신고의 상당수가 이 한 가지 사실로 설명된다. 58 GB짜리 판소리 완창 파일에서 axml을 찾으려면 끝까지 가야 한다.

8. ADM 객체 모델: 참조의 그래프

ITU-R BS.2076은 모델을 두 부분으로 나눈다. 포맷(format) 부분은 오디오가 올바르게 디코드·렌더될 수 있도록 그 기술적 성격을 기술하며, 오디오가 존재하기 전에도 작성할 수 있다. 콘텐츠(content) 부분은 대사의 언어, 라우드니스 등을 기술하며 신호가 존재해야만 완성된다. 어떤 오류가 어느 쪽에 속하는지를 알면 그 오류가 제작의 어느 단계에서 들어왔는지를 알 수 있다.

위에서 아래로:

  • audioProgramme — 완결된 하나의 프레젠테이션. 하나 이상의 audioContent를 참조한다.
  • audioContent — 편집상 의미를 갖는 구성 요소. 대사 스템, 음악 스템, 언어 버전. 하나 이상의 audioObject를 참조한다.
  • audioObject — 편집 의도와 기술 포맷이 만나는 지점. 시작 시각과 길이를 가지며, 0개 이상의 audioPackFormat, 0개 이상의 중첩 audioObject, 0개 이상의 audioTrackUID를 참조한다. 콘텐츠가 에센스와 만나는 곳이 여기다.
  • audioPackFormat — 함께 묶이는 채널의 그룹. 7.1.4 bed, 스테레오 쌍, 특정 차수의 HOA 집합. audioChannelFormat을 참조하며 다른 팩을 중첩할 수 있다.
  • audioChannelFormat — 한 채널의 시간에 따른 거동. 하나 이상의 audioBlockFormat을 담는다.
  • audioBlockFormat — 원자 단위. Objects의 경우 위치(azimuth/elevation/distance 또는 직교 X/Y/Z), 게인, 크기, 확산도, 그리고 rtime과 duration. 정적 객체는 블록 하나, 움직이는 객체는 블록의 수열.
  • audioTrackUID — 잎사귀이며, 물리 트랙에 대응하는 유일한 요소. 선택적으로 sampleRate, bitDepth 속성을 가지고 audioTrackFormat과 audioPackFormat을 참조한다.

audioStreamFormat과 audioTrackFormat은 채널 포맷과 트랙 UID 사이에 놓여 스트림 부호화를 기술한다. BS.2076-3은 PCM의 경우 이들이 사실상 불필요하며 생략되어야 한다고 밝히면서도, 리더는 BS.2076-2 이전 기준으로 만들어진 기존 ADM 파일에 이들이 들어 있을 수 있음을 알고 있어야 한다고 덧붙인다. 두 형태 모두 적법하다. 한쪽만 고집하는 검증기는 다른 쪽에 대해 틀린 것이다.

ADM은 중첩된 문서가 아니라 참조의 그래프이며, 심각한 납품 실패는 전부 그 그래프에서 끊어진 간선(edge)이다.

참조가 끊겼을 때 실제로 무슨 일이 일어나는가. 정해진 동작이 없다는 것이 문제다. XML에 없는 팩을 가리키는 audioPackFormatIDRef를 만난 렌더러는 파싱을 중단하고 파일을 거부할 수도 있고, 그 객체만 건너뛰고 나머지를 렌더해 스템 하나가 조용히 빠진 믹스를 내놓을 수도 있고, 공통 정의로 폴백했다가 0x1000 이상 커스텀 대역의 ID에서 일치하는 것을 못 찾고 무음을 대입할 수도 있다. 세 결과 모두 "파일은 열렸다"이다. 그중 귀로 잡히는 것은 하나뿐이고, 그것도 무엇이 있어야 했는지 알고 있을 때만 잡힌다. 사람의 귀는 있어야 한다는 말을 들은 적 없는 부재를 들을 수 없다. ADM QC가 자동화되어야 하는 이유가 이것이다.

9. 렌더링: BS.2127과 BS.2051 배치

객체 기반 파일은 그 자체로는 소리가 나지 않는다. 렌더링되어야 소리가 난다. 그리고 렌더링 결과는 목표 배치에 따라 달라진다.

ITU-R BS.2051은 앞서 본 대로 진보된 음향 시스템의 확성기 배치를 정의한다. ITU-R BS.2127은 그 배치들을 대상으로 하는 기준 ADM 렌더러를 정의한다. 즉 BS.2076이 "무엇을 담을 것인가"를, BS.2051이 "어디로 보낼 것인가"를, BS.2127이 "어떻게 보낼 것인가"를 규정한다. 이 세 권고는 한 세트로 읽어야 한다.

실무적 함의는 분명하다.

  1. "이 파일은 이렇게 들린다"는 문장은 배치를 명시하지 않으면 불완전하다. 같은 BW64를 시스템 B(0+5+0)와 시스템 J(4+7+0)로 렌더하면 다른 결과가 나온다. 풍물의 궤적처럼 청취자 뒤쪽을 크게 도는 객체는 차이가 특히 크다.
  2. 렌더러도 명시해야 한다. BS.2127을 구현한 오픈소스 형제인 EBU ADM Renderer(EAR, EBU Tech 3388)는 재현 가능한 결과를 얻는 실질적인 수단이다. 자체 검증에 쓸 수 있고, 상대방도 같은 것으로 확인할 수 있다.
  3. 바이노럴 렌더는 또 다른 목표다. 국내 청취의 압도적 다수가 이어폰·헤드폰이라는 현실을 감안하면, 이머시브 마스터를 만들면서 바이노럴 결과를 한 번도 확인하지 않는 것은 위험하다. 판소리에서 소리꾼과 고수의 좌우 분리가 스피커 배치에서는 살아 있는데 바이노럴에서는 뭉개진다면, 실제 청취자 대부분에게는 분리가 없는 것이다.

10. BS.1770-5 기준의 이머시브 라우드니스

여기서는 공개된 것과 떠도는 것을 엄격히 구분해야 한다.

10.1 권고가 규정하는 것

ITU-R BS.1770은 K-가중(K-weighting)을 정의한다. 강체 구를 모델링한 하이셸프 "헤드" 필터에 이어 RLB 하이패스가 오는 2단 필터다. 이 곡선의 1 kHz에서의 이득은 +0.698 dB(선형 1.0836)이다. 측정은 400 ms 게이팅 블록을 75 % 겹쳐 수행하며, 절대 게이트는 −70 LKFS 미만 블록을 버리고, 상대 게이트는 절대 게이트를 통과한 블록들의 평균에서 −10 LU 오프셋한 값이다. 상대 게이트가 게이팅 이전 전체 평균이 아니라 살아남은 블록들의 평균에서 계산된다는 점은 구현이 자주 틀리는 지점이므로 다시 강조한다.

코어 알고리즘의 채널 가중은 L, R, C가 1.0(0 dB), Ls와 Rs가 1.41(약 +1.5 dB)이며 LFE는 제외된다. 기본 알고리즘의 적용 범위는 1채널에서 5채널까지다. BS.1770-5는 부속서에서 이 범위를 넘어선다 — BS.2051의 진보된 음향 시스템, 즉 임의 위치의 확성기와 높이 채널, 그리고 측정되기 전에 반드시 렌더되어야 하는 객체 기반 오디오를 다룬다.

판(edition)에 대하여. BS.1770에는 여섯 개의 판이 있다. -0(2006), -1(2007), -2(2011), -3(2012), -4(2015), -5(2023년 11월). 현재 유효한 것은 BS.1770-5(2023년 11월)이며, BS.1770-4(2015년 10월)는 대체(superseded)되었다. 다만 현장에 배치된 미터의 다수는 여전히 -4를 표기한다. 납품 노트에는 -5를 적되, 사용한 미터가 어느 판을 구현했는지도 함께 적어 두는 것이 안전하다.

이머시브 라우드니스는 파일의 속성이 아니라 렌더의 속성이다. 목표 배치를 바꾸면 숫자가 바뀐다.

스테레오와의 실질적 차이가 여기 있다. 스테레오 마스터의 라우드니스 값은 하나다. 객체 기반 마스터의 라우드니스 값은 렌더 대상의 개수만큼 있다. 따라서 수치를 정직하게 진술하는 유일한 방법은 어느 배치에서, 어느 렌더러로 측정했는지를 함께 적는 것이다.

10.2 관련 EBU 문서

EBU Tech 3341은 미터의 거동을 정의한다 — 순간(momentary) 400 ms, 단기(short-term) 3초. EBU Tech 3342는 라우드니스 레인지(LRA)를 정의하는데, LRA의 상대 게이트는 −20 LU이지 −10 LU가 아니다. LRA에 −10을 쓰는 것은 흔한 구현 버그다. EBU R 128은 방송 프로그램 목표를 −23 LUFS로 정한다. R 128은 방송 정규화 관행이지 음악 스트리밍 규격이 아니다.

10.3 음악에 대해 공개된 것

채널 기반 스테레오 음악에 대해 Spotify는 통합 목표 −14 LUFS와 트루 피크 상한 −1 dBTP를 공개하며, 마스터가 −14 LUFS보다 크면 −2 dBTP로 조인다. 출처: support.spotify.com.

AES TD1008은 음악에 대해 −16 LUFS를 권고한다. TD1008에 나오는 −18 LUFS는 말(speech) 중심 콘텐츠 — 뉴스, 토크, 드라마 — 에 적용되는 값이다. −18을 음악의 목표로 진술하는 것은 흔하고 심각한 오류다.

정규화의 방향에 대해서도 정확할 필요가 있다. Spotify는 목표보다 조용한 마스터에 양의 게인을 적용해 −14 LUFS에 맞춘다고 밝히면서, 동시에 트랙의 헤드룸을 고려하며 손실 부호화를 위해 1 dB의 헤드룸을 남겨 둔다고 명시한다. 따라서 피크가 높은 조용한 마스터는 목표까지 전부 올라가지 않을 수 있다. "조용한 마스터는 올려 주지 않는다"도 틀렸고, "조용한 마스터는 언제나 목표까지 올라간다"도 틀렸다.

여기서 나오는 결론이 이머시브에서 더 중요해진다. 과도한 리미팅이 사는 것은 크기가 아니라 평탄함이다. 그리고 이머시브에서는 잃는 것이 하나 더 있다. 다이내믹 레인지를 뭉개면 공간감도 함께 뭉개진다. 범종의 감쇠, 풍물의 다가옴과 멀어짐, 판소리에서 소리꾼이 목소리를 낮출 때 방이 드러나는 순간 — 이 모두가 레벨 차이로 존재하는 사건이다.

10.4 공개되지 않은 것

어떤 음악 스트리밍 서비스도 이머시브 납품에 대한 통합 라우드니스 목표를 공개하지 않는다. 포럼과 벤더 교육 자료에는 숫자가 널리 돌아다니고, 그중 일부는 그럴듯하며 일부는 아마 맞을 것이다. 그러나 어느 것도 공개된 규격이 아니며, 이 문서는 그것을 규격인 양 반복하지 않는다.

스테레오에 대해서도 마찬가지다. Apple Music, YouTube Music, Amazon Music, TIDAL, Deezer는 정규화 목표를 공개하지 않는다. 아래 값들은 널리 보고되고 있으나 서비스가 공개한 것은 아니다:

널리 보고되고 있으나 서비스가 공개하지 않은 수치 — Apple ≈ −16, YouTube Music ≈ −14, Amazon ≈ −14, TIDAL ≈ −14, Deezer ≈ −15. 이 값들로 게인 변화량을 계산하지 말 것.

방송과 영화 쪽이 음악보다 문서화가 잘 되어 있는 이유는 방송사가 규격을 공개하기 때문이다. 오늘 당장 방어 가능한 이머시브 라우드니스 수치가 필요하다면 방법은 하나다. BS.2127에 부합하는 렌더를 명시된 BS.2051 배치로 만들고, BS.1770-5 미터로 측정한 뒤, 세 가지를 모두 납품 노트에 적는다.

10.5 독점 시스템에 대하여

Dolby Atmos는 Dolby Laboratories의 독점 라이선스 기술이고, Sony 360 Reality Audio는 MPEG-H 위에 구축된 독점 시스템이다. 이들의 납품 요구사항은 소유자가 정하며 ITU나 EBU의 일정과 무관하게 바뀐다. 이 문서의 어떤 내용도 그 회사들의 요구사항에 대한 진술이 아니며, 어떠한 제휴·인증·보증도 주장하거나 암시하지 않는다. 라이선서가 요구사항을 공개하는 경우, 라이선서 본인의 최신 문서를 읽고 그것을 인용하라.

11. 정직한 현실: 당신은 아마 이머시브로 모니터링하고 있지 않다

이 문서는 스피커를 팔지 않으므로 솔직하게 쓸 수 있다.

한국에서 제대로 정렬된 이머시브 모니터링 환경은 소수의 방송사와 포스트프로덕션 시설에 존재하고, 음악 스튜디오에는 사실상 거의 없다. 12채널 이상을 정렬하고 캘리브레이션할 수 있는 방을 갖춘 음악 작업실은 손에 꼽는다. 마포·홍대·강남 일대의 작업실 다수는 좋은 스테레오 룸이며, 그것이 부끄러운 일은 아니다.

그렇다면 이 문서의 실용적 가치는 어디에 있는가. 모니터링이 아니라 세 가지에 있다.

  1. 올바른 납품. 파일이 규격에 맞고, 컨테이너가 정당하고, 청크 순서가 옳을 것.
  2. 올바른 메타데이터. 객체가 실제로 있어야 할 곳에 선언되어 있고, 참조 그래프에 끊어진 간선이 없을 것.
  3. 들어 볼 수 없는 파일을 검증하는 능력. 이것이 핵심이다.

세 번째가 왜 가능한가 하면, ADM 오류의 압도적 다수가 듣기와 무관한 오류이기 때문이다. fmt 의 채널 수와 chna의 트랙 수가 다른 것은 정수 두 개를 비교하면 알 수 있다. 고아가 된 UID는 집합 두 개의 대칭차를 구하면 알 수 있다. 블록 타이밍이 어긋난 것은 rtime[n] + duration[n] == rtime[n+1]을 검사하면 알 수 있다. 이 중 무엇도 스피커를 필요로 하지 않는다.

바이노럴 렌더는 그다음 층의 안전망이다. 12채널 방이 없어도 EAR 같은 BS.2127 구현으로 바이노럴 렌더를 만들어 좋은 헤드폰으로 들으면, 객체가 통째로 빠졌는지, 좌우가 뒤집혔는지, 높이 성분이 아예 없는지 정도는 확실히 알 수 있다. 정밀한 정위 판단은 못 한다. 그러나 이머시브 납품에서 반려되는 사유의 대부분은 정밀한 정위 문제가 아니다.

11.1 들을 수 없는 파일을 검증하는 구체적 절차

모니터링 환경이 없는 상태에서 실제로 수행할 수 있는 순서는 다음과 같다. 위에서 아래로 갈수록 비용이 커지므로 순서를 지키는 것이 중요하다.

  1. 파일 시그니처와 청크 목록을 뽑는다. 파일 전체를 읽지 않고 청크 헤더만 순회하면 몇 초면 끝난다. 이 단계에서 BW64 여부, ds64의 위치, axml의 존재와 그 오프셋이 확정된다. axml이 data 뒤에 있는지도 여기서 드러난다.
  2. 정수 세 개를 비교한다. fmt.nChannels, chna.numTracks, 그리고 chna 청크 크기에서 역산한 항목 수. 셋이 서로 모순되면 그 아래는 볼 필요가 없다.
  3. axml을 XML 파서에 통과시킨다. 정형(well-formed)이 아니면 여기서 걸린다. 인코딩 선언과 실제 바이트가 어긋난 경우도 여기서 잡힌다.
  4. 참조 그래프를 만든다. 모든 ID를 노드로, 모든 ...IDRef를 간선으로 삼아 그래프를 구성하고, 대상이 없는 간선과 아무도 가리키지 않는 노드를 나열한다. 이 목록이 비어야 한다.
  5. 블록 타이밍을 순회한다. 채널 포맷마다 블록을 정렬해 연속성을 단언한다.
  6. 에센스를 스캔한다. 각 트랙의 피크와 RMS를 뽑아 완전한 무음 트랙을 찾아낸다. 선언된 bed 채널이 무음이면 사람이 판단한다.
  7. 바이노럴 렌더를 만들어 듣는다. 여기서 처음으로 귀를 쓴다. 앞의 여섯 단계를 통과한 파일에서 귀로 잡을 것은 "있어야 할 것이 통째로 없다" 수준의 문제뿐이며, 그것으로 충분하다.

1번부터 5번까지는 어느 것도 스피커를 필요로 하지 않고, 전부 합해도 파일 크기에 비례하는 시간 안에 끝난다. 반려 사유의 압도적 다수가 이 다섯 단계에서 걸린다.

11.2 XML을 따로 보관해야 하는 이유

납품이 끝난 뒤 무엇을 아카이브할 것인가는 사소해 보이지만 나중에 큰 차이를 만든다. 58 GB짜리 BW64는 보관하기 번거롭고, 무엇보다 비교할 수 없다. 두 버전 중 어느 것이 맞는지 알아내려면 다시 파싱하는 수밖에 없다.

반면 axml을 뽑아 따로 저장해 두면 그것은 텍스트다. 버전 관리 시스템에 넣을 수 있고, 두 납품본의 메타데이터 차이를 한 줄 단위로 볼 수 있다. "지난번 마스터에서는 객체가 16개였는데 이번엔 15개다"라는 사실이 즉시 드러난다. 실무적으로 이것이 가장 값싼 보험이다. 세션 파일, axml, 체크섬 매니페스트 — 이 셋을 BW64와 분리해 보관하라.

12. 자주 나오는 QC 실패와 각각의 탐지법

12.1 fmt 와 chna의 채널 수 불일치

fmt.nChannels는 16이라고 하는데 chna.numTracks는 14라고 한다. 첫 두 청크에서부터 내부적으로 모순된 파일이다. 대개 메타데이터를 작성한 뒤에 트랙 수를 바꿔 바운스했거나, 트랙을 떨어뜨리면서 chna를 다시 쓰지 않은 도구가 원인이다.

탐지: 두 청크를 파싱해 정수를 비교한다. 파이프라인 전체에서 가장 값싼 검사이며, 놀랄 만큼 많은 실패를 잡아낸다. 아울러 chna의 모든 trackIndex가 1 … fmt.nChannels 범위 안에 있는지도 확인한다.

12.2 고아 트랙 UID

chna에는 있는데 어떤 audioObject도 참조하지 않는 UID, 또는 XML에는 audioTrackUIDRef가 있는데 대응하는 chna 항목이 없는 경우. 앞은 아무도 렌더하지 않을 오디오가 존재한다는 뜻이고, 뒤는 메타데이터가 없는 트랙을 기대한다는 뜻이다.

탐지: chna에서 얻은 UID 집합과 axml에서 얻은 UID 집합의 대칭차를 구한다. 비어 있어야 한다. EBU Tech 3392는 의도를 명시한다 — audioObject가 audioPackFormat을 참조한다면 대응하는 audioTrackUID도 참조해야 한다.

12.3 타이밍이 없거나 단조롭지 않은 블록 포맷

BS.2076은 명확하다. 하나의 audioChannelFormat 안에 audioBlockFormat이 둘 이상 있으면 rtime과 duration이 모두 있어야 한다. EBU Tech 3392는 이를 연속성 규칙으로 조인다 — 어떤 블록의 rtime + duration은 다음 블록의 rtime과 일치해야 하며, 객체의 첫 블록은 00:00:00.00000에서 시작하고, 어떤 블록도 1샘플보다 짧아서는 안 되며, 길이의 합은 상위 audioObject의 길이와 맞아야 한다.

탐지: 각 audioChannelFormat에 대해 문서 순서대로 블록을 순회하며 rtime[n] + duration[n] == rtime[n+1]을 단언한다. 실패는 세 유형으로 모인다. 틈(렌더러 동작이 정의되지 않음 — 마지막 위치를 유지하는 구현도 있고 음소거하는 구현도 있다), 겹침(블록들이 서로 싸운다), 역순(프로그램 도중에 오토메이션이 뒤로 점프한다). 풍물처럼 궤적이 긴 소재에서 이 오류가 나오면 상쇠가 무대 한가운데에서 순간이동하는 결과가 된다.

12.4 잘못된 샘플레이트 또는 비트 심도

audioTrackUID는 sampleRate, bitDepth 속성을 가질 수 있다. 이것이 fmt 와 모순되면 같은 에센스에 대한 두 개의 주장이 존재하는 것이다. EBU Tech 3392의 입장은 에센스에서 얻을 수 있다면 이 속성들을 무시해야 한다는 것이지만, 모든 렌더러가 그 안내를 따르지는 않는다. 한쪽에서는 48 000, 다른 쪽에서는 96 000이라고 말하는 파일은 도구마다 다르게 해석된다. 별도로, 그 레이트가 납품 규격이 요구하는 값인지도 확인해야 한다. ADM 작성 이후에 적용한 샘플레이트 변환은 샘플로 표현된 모든 rtime과 duration을 무효로 만든다.

탐지: fmt 를 XML 안의 모든 sampleRate/bitDepth 속성과 비교하고, 명목상 허용된다 해도 불일치를 표시한다.

12.5 스테레오·바이노럴 컨폼의 부재 또는 어긋남

대부분의 이머시브 납품은 이머시브 마스터와 함께 스테레오(그리고 흔히 바이노럴) 컨폼을 요구한다. 반복되는 실패는 부재가 아니라 — 부재는 눈에 띈다 — 드리프트다. 이전 버전에서 렌더된 컨폼, 몇 프레임 어긋난 컨폼, 시작 타임코드가 다른 컨폼. 이머시브 원본보다 40 ms 빠른 스테레오 파일은 파일 존재 검사를 통과하고 동기 청취에서 실패한다.

탐지: 길이를 샘플 단위로 비교하고, bext의 시작 타임코드를 비교하고, 컨폼을 마스터의 널 렌더와 상호상관한다. 현재 마스터에서 바이트 단위로 유도되지 않는 컨폼은 의심하고, 다시 검사하지 말고 다시 렌더하라.

12.6 파일에 없는 bed를 기술하는 메타데이터

XML은 7.1.4 DirectSpeakers 팩 — 12채널 — 을 선언하는데 실제로는 5.1 부분집합만 프린트되었거나, 바운스 시점에 높이 채널이 뮤트되어 디지털 블랙으로 프린트된 경우. 참조 그래프는 멀쩡하고 오디오가 없다.

탐지: 구조 검사로는 잡을 수 없다. 에센스 분석이 필요하다. DirectSpeakers 팩이 주장하는 모든 채널에 대해 트랙에 신호가 존재하는지를 측정한다. 선언된 bed 채널의 디지털 블랙이 자동으로 오류인 것은 아니다 — 정당한 믹스가 상단 후방 채널을 비워 둘 수 있다 — 그러나 언제나 사람의 판단을 거칠 값어치가 있다.

컨테이너가 완벽히 유효하고 XML이 완벽히 정형(well-formed)이면서도 딜리버러블이 틀릴 수 있다. 비어 있는 bed 채널을 확인하는 유일한 방법은 샘플을 들여다보는 것뿐이다.

이 검사들을 위해 무엇을 쓸지는 자유다. mazufa.com에는 브라우저에서 동작하는 무료 BW64/ADM 인스펙터가 있는데, 컨테이너와 메타데이터를 사용자 자신의 기기에서 전부 파싱하고 아무것도 업로드하지 않으므로, 계약상 건물 밖으로 나갈 수 없는 소재에도 쓸 수 있다.

13. 납품 체크리스트

순서대로 진행한다. 구조 검사가 먼저다. 빠르고, 실패하면 그 아래의 모든 것이 무의미해진다.

컨테이너

  1. 첫 4바이트가 BW64인가. RIFF라면 평범한 WAV이며 4 GB를 넘을 수 없다.
  2. ds64가 시그니처 바로 다음 첫 청크이며, 그 64비트 크기가 디스크의 실제 파일 크기 및 data 크기와 일치하는가.
  3. data 이외에 4 GB를 넘는 청크가 있다면 ds64 테이블에 ChunkSize64 항목이 있는가.
  4. axml을 명시적으로 찾았는가 — data 뒤도 포함해서. 부분 스캔으로 "ADM 없음"이라고 결론 내리지 말 것.

에센스

  1. fmt 의 샘플레이트와 비트 심도가 납품 규격과 정확히 일치하는가. ADM 작성 이후 SRC 없음.
  2. fmt.nChannels == chna.numTracks.
  3. chna의 모든 trackIndex가 범위 안에 있고 1부터 시작하는가.

chna 무결성

  1. 모든 항목이 정확히 40바이트이며 고정폭 필드가 올바르게 패딩되어 있는가.
  2. 0x1000 이상의 모든 packRef가 axml에 존재하는 커스텀 정의로 해소되는가.
  3. 중복된 trackIndex가 의도된 것인가(트랙이 정당하게 정의를 바꾼 경우), 아니면 중복 오류인가.

ADM 그래프

  1. 모든 audioContentIDRef, audioObjectIDRef, audioPackFormatIDRef, audioChannelFormatIDRef, audioTrackUIDRef가 해소되는가. 끊어진 간선 0.
  2. 양방향 모두에서 고아 audioTrackUID가 없는가.
  3. 순환 참조나 자기 참조 요소가 없는가.
  4. 각 audioChannelFormat의 typeLabel이 상위 audioPackFormat과 일치하는가.

타이밍

  1. 블록이 둘 이상인 채널 포맷의 모든 블록에 rtime과 duration이 있는가.
  2. 블록이 연속적이고 단조 증가하며, 길이의 합이 상위 audioObject의 길이와 맞는가.
  3. 객체가 00:00:00.00000에서 시작하는가.

콘텐츠

  1. 선언된 bed의 모든 채널이 있어야 할 것을 담고 있는가. 디지털 블랙은 조사할 것.
  2. 객체 수와 bed 구성이 납품 규격과 맞는가.
  3. bext 시작 타임코드가 정확하며 세트 내 모든 딜리버러블에서 일관된가.

렌더와 컨폼

  1. 스테레오·바이노럴 컨폼이 현재 마스터에서 다시 렌더된 것인가. 이전 것을 끌고 오지 않았는가.
  2. 길이와 시작 타임코드가 마스터와 샘플 단위로 일치하는가.
  3. 라우드니스를 명시된 배치·명시된 렌더러로 만든 명시된 렌더에서 측정하고, 셋 모두를 납품 노트에 기록했는가.

한글·문자 처리

  1. axml이 UTF-8이며 한글 문자열이 NFC로 정규화되어 있는가.
  2. ID 참조에 ASCII만 쓰였는가. 한글은 사람이 읽는 이름 속성에만.

재현성

  1. 모든 딜리버러블의 체크섬을 만들고 매니페스트를 보관했는가.
  2. 세션과 ADM XML을 BW64와 별도로 아카이브했는가. 나중에 가치가 있는 것은 다시 파싱할 수밖에 없는 바이너리가 아니라 diff를 뜰 수 있는 XML이다.
이머시브 딜리버러블은 좋게 들릴 때 끝나는 것이 아니라, 한 번도 들어 본 적 없는 기계가 참조가 해소된다는 것을 증명할 수 있을 때 끝난다.

13.1 납품 노트에 반드시 들어가야 할 것

체크리스트를 통과했다는 사실 자체를 문서로 남겨야 한다. 최소한 다음이 들어간다.

  • 컨테이너: BW64, 파일 크기, data 크기, axml의 위치(파일 앞인지 뒤인지).
  • 에센스: 샘플레이트, 비트 심도, 총 트랙 수, bed 구성(예: 7.1.4)과 객체 수.
  • 트랙 시트: 물리 트랙 번호 ↔ audioTrackUID ↔ 사람이 읽는 이름의 대응표. 이것이 없으면 상대편이 파일을 열었을 때 3번 트랙이 무엇인지 알 방법이 없다. 국악처럼 편성이 익숙하지 않은 소재일수록 필수다.
  • 렌더 조건: 라우드니스를 측정한 BS.2051 배치, 사용한 렌더러와 그 버전, 사용한 미터와 그것이 구현한 BS.1770 판.
  • 측정값: 통합 라우드니스, 라우드니스 레인지, 트루 피크 — 셋 모두 위의 렌더 조건과 묶여서만 의미가 있다.
  • 컨폼 목록: 스테레오·바이노럴 파일명, 각각의 길이와 시작 타임코드, 마스터와의 일치 여부.
  • 체크섬: 모든 딜리버러블의 해시.

이 문서를 만드는 데 걸리는 시간은 30분이고, 없어서 생기는 왕복은 며칠이다.

14. 맺음

BW64와 ADM은 공개되어 있고 발행되어 있으며 누구나 읽을 수 있는 표준이다. 이 업계의 이 구석에서 그것은 드문 일이고, 활용할 가치가 있다. BS.2088과 BS.2076을 직접 읽을 수 있고, 마흔 줄 남짓의 코드로 chna 청크를 파싱할 수 있으며, 벤더의 익스포터가 대화상자에서 뭐라고 주장했는지가 아니라 실제로 무엇을 썼는지를 검증할 수 있다.

한국의 음악 제작 환경에서 이머시브는 아직 소수의 방과 소수의 프로젝트에 머물러 있다. 그러나 풍물이 도는 원과 판소리의 두 사람과 종각에 걸린 범종은 이머시브 포맷이 기술하려고 만들어진 바로 그 종류의 사건이다. 모니터링 환경은 시간이 지나면 갖춰진다. 그 사이에 할 수 있고 해야 하는 일은, 파일이 스스로를 정확히 설명하도록 만드는 것이다. 불필요한 반려의 가장 큰 몫이 여전히 이머시브에서 발생하며, 그 거의 전부는 검증기가 1초 안에 잡아내는 참조 무결성 오류다.

Mazufa의 배포는 무료다 — 업로드 비용도, 구독료도, 릴리스별 과금도 없다. 공제는 수령한 로열티의 5%뿐이며, 모든 완성된 지원서는 사람이 검토한다.

출처

ITU-R 권고

EBU 기술문서

AES

서비스 문서

유니코드

최종 검토 2026년 9월. 표준은 개정된다. 조항 번호를 인용하기 전에 위의 ITU·EBU 페이지에서 현재 판을 반드시 확인하라.

다른 기술 레퍼런스

실무자를 위해 쓰였고, 원본 표준에서 직접 가져왔으며, 무료로 읽을 수 있습니다.

스트리밍을 위한 라우드니스 정규화: 한국어 기술 레퍼런스트루 피크(true peak, 실제 첨두값) 실링을 −1 dBTP로 고정하고, 인티그레이티드 라우드니스(integrated loudness, 전체 통합 라우드니스)는 음악이 도달하는 자리에 그대로 두십시오. 굳이 공개된 목표치가 필요하다면 AES TD1008이…ISRC·ISWC·UPC/EAN — 녹음, 저작물, 발매를 각각 식별한다는 것ISRC는 녹음물을, ISWC는 저작물(곡)을, UPC/EAN은 발매 상품을 식별한다. 셋은 서로 대체되지 않고, 하나가 틀리면 그 층위의 정산만 조용히 끊긴다. ISRC는 12자리(국가 2 + 등록자 3 + 참조연도 2 + 지정번호 5)이고 하이픈은 표기…음원 릴리스 메타데이터: 한글 표기와 유통 체인을 통과하는 법아티스트명, 트랙 제목, 참여 아티스트, 버전 표기 — 그리고 한글 정규화라는, 아무도 설명해 주지 않는 실패.

이 주제의 무료 도구 열기 →

확인은 끝났어요. 이제 발매할 차례예요.

파일이 준비되어 있다면 신청은 몇 분이면 끝나고, 사람이 직접 읽습니다.

심사 신청하기

신청은 무료입니다. 계정은 만들지 않으며, 담당자가 직접 검토해 이메일로 답장합니다.

다른 무료 도구

무료, 계정 불필요, 업로드 없음. 모든 것이 브라우저에서 실행됩니다.

▣반려되기 전에 커버를 점검하세요
아트워크는 릴리스가 반려되는 가장 흔한 이유입니다. 커버를 올려 공개된 스토어 요건과 대조해 보고, 사람들이 실제로 보게 될 크기로 확인하세요. 모든 처리는 브라우저에서 이뤄지며 이미지는 업로드되지 않습니다.
✎메타데이터를 스토어 규정과 대조하세요
제목에 들어간 피처링 아티스트, 괄호 안의 버전 정보, 아티스트 항목에 넣은 검색어. 발매 전 금요일에 도착하는 반려는 대개 이런 것들입니다. 제출하려는 내용을 입력해 지금 확인하세요. 모든 처리는 브라우저에서 이뤄
⌘ISRC와 바코드를 확인하세요
두 개의 코드가 당신의 수익을 나릅니다. 음원을 식별하는 ISRC와 릴리스를 식별하는 바코드입니다. 어느 쪽이든 숫자 하나가 틀리면 로열티가 다른 곳으로 갑니다. 제출 전에 붙여넣고 확인하세요.
⏱발매일에서 거꾸로 계산하세요
릴리스에서 놓치는 기회는 대부분 재능이 아니라 마감을 놓친 결과입니다. 공개하고 싶은 날짜를 입력하면 모든 단계가 그 날짜에서 역산되어 나옵니다. 되돌릴 수 없는 단 하나, 피치 마감을 포함해서요.
◈스토어가 손대기 전에 마스터를 점검하세요
믹스를 올리면 스트리밍 서비스가 측정하는 것과 같은 방식으로 적분 라우드니스, 트루 피크, 라우드니스 레인지를 확인할 수 있습니다. 이어서 각 서비스가 적용할 정확한 게인까지 보여줍니다. 파일은 브라우저 안에서 분석