이머시브 마스터가 파형 편집기는 통과하고 QC에서 걸리는 이유

이머시브 납품물은 파형 편집기에서 열리고, 멀쩡해 보이는 트랙 열두 개나 열여섯 개를 보여 주고, 무난하게 재생되면서도 반려될 수 있습니다. 이유는 구조적입니다. BW64 파일에서 오디오와 메타데이터는 서로 정확히 일치해야 하는 별개의 두 가지인데, 포맷에는 그것을 강제하는 장치가 전혀 없습니다. 렌더러는 참조를 해석하고, 편집기는 샘플을 그립니다. 하는 일이 서로 다른 것이며, 그래서 ADM QC는 듣기가 아니라 참조 무결성 검사입니다. 두 표준이 무엇을 말하는지, 참조는 어디에서 끊어지는지, 어떤 검사가 어떤 실패를 잡아내는지를 정리했습니다.

세 종류의 오디오, 그리고 이 구분이 모든 것을 결정하는 이유

이머시브 납품 문제는 전부 트랙이 셋 중 무엇인가에 대한 혼동에서 시작됩니다.

채널 기반 오디오는 각 트랙을 고정된 스피커 위치에 배정합니다. 스테레오가 채널 기반이고, 5.1도, 7.1.4 베드도 그렇습니다. 위치는 채널 정체성 안에 구워져 있습니다. 트랙 3은 센터 스피커이고, 이를 재생하는 모든 시스템에서 센터 스피커입니다. ITU-R BS.2051은 이를 어드밴스드 사운드 시스템에 대해 공식화하며, 레이아웃을 Upper + Middle + Bottom 레이어 개수로 기술합니다. System A는 0+2+0(스테레오), System B는 0+5+0(5.1), System D는 4+5+0, System J는 4+7+0, System H는 9+10+3인 22.2 구성입니다. ADM에서는 DirectSpeakers typeDefinition, typeLabel 0001입니다.

객체 기반 오디오는 모노(또는 다채널 팩) 신호와 시간에 따라 변하는 위치 메타데이터를 함께 담습니다. 어떤 실제 스피커가 이를 재생할지는 렌더러가 그 공간에 있는 레이아웃을 보고 결정합니다. 트랙 자체는 어떤 스피커도 전제하지 않습니다. typeDefinition Objects, typeLabel 0003입니다.

장면 기반 오디오는 실무적으로 고차 앰비소닉스를 말하며, 음장 전체를 구면조화 성분으로 부호화합니다. 어떤 성분도 그 자체로는 방향에 대응하지 않고, 방향은 선형 결합에서 비로소 나타납니다. HOA, typeLabel 0004입니다. ADM은 미드-사이드나 Lt/Rt 같은 매트릭스 신호를 위한 Matrix(0002)와 Binaural(0005)도 정의합니다.

이 구분은 분류학의 문제가 아닙니다. 채널 기반 납품물은 맨 WAV로도 살아남을 만큼 자기 설명적입니다. 채널 순서만 맞으면 재생됩니다. 반면 객체 기반이나 장면 기반 납품물은 메타데이터 없이는 아무 의미가 없습니다. 오디오는 구분되지 않는 모노 스트림 더미이고, 그렇지 않다고 말해 주는 것은 ADM뿐입니다. BW64와 ADM이 존재하는 이유가 바로 이 비대칭입니다.

BW64는 32비트 숫자 하나 때문에 존재합니다

고전적인 WAV는 RIFF 파일입니다. 1991년의 RIFF는 모든 청크 앞에 32비트 크기 필드를 붙입니다. 32비트는 4,294,967,296바이트, 즉 4 GB를 주소 지정할 수 있고, 이것이 파일 전체와 그 안의 data 청크 모두에 걸리는 절대 상한입니다.

48 kHz / 24비트 스테레오라면 데이터 전송률이 초당 288,000바이트이므로 4 GB는 약 4시간 8분입니다. 문제가 되지 않습니다. 그러나 96 kHz / 24비트의 128트랙 객체 기반 마스터라면 전송률은 초당 36,864,000바이트이고, 4 GB는 2분도 되지 않는 116.5초입니다.

이머시브 마스터는 이 한계를 일상적으로 넘어서며, 여기에 부딪힌 WAV 라이터는 잘린 파일이나 선언된 크기가 조용히 자리올림되어 버린 파일을 내놓습니다. EBU가 먼저 RF64(EBU Tech 3306)로 이 문제를 다루었고, ITU가 이를 이어받아 권고 ITU-R BS.2088, 즉 BW64로 만들었습니다.

센티널 트릭: 0xFFFFFFFF와 ds64 청크

BS.2088은 그 작동 원리를 명시합니다. "The ID 'BW64' is used instead of 'RIFF' in the first four bytes of the file"이며, 기존 32비트 크기 필드는 이스케이프 플래그가 됩니다. "If the 32-bit value in the field is 0xFFFFFFFF the 64-bit value in the 'ds64' chunk is used instead."

트릭은 이것이 전부이고, 분명히 짚어 둘 가치가 있습니다. BW64는 RIFF의 크기 필드를 넓히지 않습니다. 그 필드를 0xFFFFFFFF라는 센티널로 채우고, 진짜 64비트 크기는 파일 맨 앞에 와야 하는 ds64 청크에 넣습니다. 그래서 4 GB 미만인 BW64 파일은 4문자 시그니처만 빼면 모든 면에서 WAV 리더와 바이트 단위로 호환됩니다. 많은 도구가 이를 받아들이지만, 완강히 거부하는 것들도 있습니다.

청크들, 그리고 항목당 정확히 40바이트인 것

BS.2088에 따르면 BW64 파일에는 최소한 ds64, fmt , chna, axml(대체 메타데이터 운반체로 bxml과 sxml), 그리고 웨이브 데이터가 들어 있어야 합니다.

ds64는 시그니처 다음의 첫 청크여야 합니다. 리더가 다른 무엇이든 훑기 전에 실제 크기를 알아야 하기 때문입니다. 파일 전체 크기와 data 크기의 32비트 상위/하위 절반을 담고, 여기에 크기가 초과된 다른 청크를 위한 ChunkSize64 항목 표를 담습니다. 샘플 단위로 정확한 오토메이션이 붙은 수천 개 객체를 기술하는 axml 청크는 그 자체로 4 GB에 육박하거나 이를 넘을 수 있습니다.

fmt 는 표준 WAVE 포맷 청크입니다. 샘플 포맷, 샘플레이트, 채널 수, 샘플당 비트 수, 블록 얼라인이 들어갑니다. data에 몇 개의 인터리브된 채널이 있는지에 대한 유일한 권위 있는 진술입니다. 그 뒤의 모든 것은 그 채널들에 관한 메타데이터이고, 메타데이터는 거짓말을 할 수 있습니다.

chna는 물리적 트랙과 ADM 사이의 다리입니다. ckID, ckSize, 2바이트 numTracks, 2바이트 numUIDs 뒤에, 각각 정확히 40바이트인 고정폭 audioID 항목의 평면 배열이 옵니다.

2 + 12 + 14 + 11 + 1 = 40. 이 폭은 권고 사항이 아닙니다. 고정폭 ASCII이며, 13자짜리 UID를 내보내는 라이터는 조금 특이한 표가 아니라 손상된 표를 만들어 낸 것입니다.

ID 규약도 중요합니다. 0x0FFF 이하의 값은 ADM 공통 정의, 즉 미리 정의된 표준 채널·팩 포맷을 가리키고, 0x1000 이상은 axml에 반드시 존재해야 하는 커스텀 정의를 뜻합니다. AP_00010003은 공통 정의상 5.1이므로 XML이 필요 없지만, AP_00031001은 커스텀 객체 팩이므로 XML이 필요하고, 없으면 참조가 허공에 뜹니다.

numUIDs가 numTracks를 넘어서는 것도 정당할 수 있습니다. EBU 지침은 "the audio elements of a track may be [defined] differently in the course of a file … there will be a different UID for each definition"이라고 적어 두었습니다. 즉 하나의 trackIndex가 여러 항목에 나타날 수 있습니다. 트랙당 UID 하나를 전제하는 QC 도구는 정상 파일을 고장 난 것으로 표시합니다.

axml은 <audioFormatExtended> 트리를 담은 UTF-8 XML 문서입니다. 이것이 ADM이고, 흥미로운 실패는 사실상 전부 여기에 삽니다. data는 그냥 인터리브된 PCM이며, 그 안의 어떤 것도 객체에 대해 아무것도 알지 못합니다.

순서. ds64는 언제나 맨 앞, fmt 는 data보다 앞. 그러나 axml은 data 뒤에 와도 정당하며 실제로 자주 그렇습니다. BS.2088이 지적하듯 녹음 중에는 "the XML metadata will likely be of an unknown length"이기 때문입니다. axml이 꼬리에 붙은 파일은 잘못된 파일이 아니지만, 앞쪽 1메가바이트만 훑는 리더는 ADM이 아예 없다고 보고합니다. "내 파일에 메타데이터가 없다"는 신고의 상당 부분이 여기서 나옵니다.

ADM은 그래프이고, 실패는 끊어진 간선입니다

ITU-R BS.2076의 계층은 audioProgramme → audioContent → audioObject → audioPackFormat → audioChannelFormat → audioBlockFormat으로 이어지며, audioTrackUID가 잎이자 물리적 트랙에 대응하는 유일한 요소입니다.

이는 중첩된 문서가 아니라 참조의 그래프이고, 심각한 납품 실패는 전부 그 안의 끊어진 간선입니다. 허공에 뜬 참조가 위험한 이유는 하나가 끊어졌을 때의 동작이 단일하지 않다는 데 있습니다. XML에 없는 팩을 가리키는 audioPackFormatIDRef를 만난 렌더러는 파싱을 중단하고 파일을 거부할 수도 있고, 그 객체만 건너뛰고 나머지를 렌더링해 스템 하나가 조용히 빠진 믹스를 만들 수도 있으며, 공통 정의로 폴백했다가 0x1000 이상 커스텀 범위의 ID를 찾지 못해 무음으로 대체할 수도 있습니다. 세 결과 모두 "파일은 열렸다"입니다. 그중 듣기로 잡히는 것은 하나뿐이고, 그마저도 무엇이 있어야 했는지 알고 있을 때뿐입니다.

반려의 대부분을 차지하는 네 가지 실패

chna와 어긋나는 fmt 트랙 수. fmt .nChannels는 16이라 하고 chna.numTracks는 14라 합니다. 첫 두 청크에서부터 파일이 내부적으로 모순됩니다. 대개 메타데이터를 작성한 뒤 트랙 수가 바뀐 바운스이거나, chna를 다시 쓰지 않고 트랙을 떨어뜨린 도구입니다. 검출은 정수 두 개를 파싱해 비교하는 것으로 끝납니다. 파이프라인에서 가장 값싼 검사이면서 놀라울 만큼 많은 실패를 잡아냅니다. 동시에 모든 trackIndex가 1 … fmt .nChannels 범위 안에 있는지도 확인하십시오.

어떤 객체도 참조하지 않는 audioTrackUID. chna에 있는데 어떤 audioObject도 참조하지 않는 UID는 아무것도 렌더링하지 않을 오디오가 존재한다는 뜻입니다. 그 거울상, 즉 대응하는 chna 항목이 없는 XML 속 audioTrackUIDRef는 메타데이터가 있지도 않은 트랙을 기대하고 있다는 뜻입니다. chna에서 뽑은 UID 집합과 axml에서 뽑은 집합의 대칭차를 구하십시오. 비어 있어야 합니다. EBU Tech 3392는 그 의도를 직접 밝힙니다. "If the audioObject refers to an audioPackFormat it should also refer to the corresponding audioTrackUIDs."

거꾸로 흐르는 블록 타이밍. BS.2076은 모호하지 않습니다. "When there is more than one audioBlockFormat within an audioChannelFormat … both rtime and duration shall be present." EBU Tech 3392는 이를 연속성으로 조입니다. "rtime + duration of an audioBlockFormat should match the rtime of the following block"이며, 객체의 첫 블록은 00:00:00.00000에서 시작하고, 한 샘플보다 짧은 블록은 없어야 하며, 지속 시간의 합은 상위 audioObject와 맞아야 합니다. 블록을 문서 순서대로 훑으며 rtime[n] + duration[n] == rtime[n+1]을 확인하십시오. 실패는 세 가지 모양으로 옵니다. 간극은 렌더러 동작이 정의되어 있지 않아 어떤 것은 마지막 위치를 유지하고 어떤 것은 뮤트합니다. 겹침은 블록끼리 다툽니다. 시간순을 벗어난 블록은 프로그램 중간에 오토메이션이 뒤로 점프한 것입니다.

XML에는 기술되었지만 디스크에는 한 번도 기록되지 않은 베드. XML은 12채널짜리 7.1.4 DirectSpeakers 팩을 선언하는데 실제로는 5.1 부분집합만 기록되었거나, 하이트 채널이 바운스 시점에 뮤트되어 디지털 블랙으로 기록된 경우입니다. 참조 그래프는 온전한데 오디오가 그렇지 않습니다. 구조 검사로는 이를 잡을 수 없습니다. DirectSpeakers 팩이 주장하는 모든 채널에 신호가 조금이라도 들어 있는지 측정하는 에센스 분석이 필요합니다. 선언된 베드 채널의 디지털 블랙이 자동으로 오류인 것은 아니며, 정당한 믹스가 톱-리어 채널을 비워 둘 수도 있습니다. 다만 사람이 판단할 가치는 언제나 있습니다.

이머시브 라우드니스에 관해 공개된 것과 공개되지 않은 것

스테레오에서 옮겨 올 때 살아남지 못하는 숫자가 하나 있고, 그 이유는 말해 둘 가치가 있습니다.

BS.1770-5(November 2023)가 현행 판이고 BS.1770-4는 폐지되었지만, 현장에 깔린 대부분의 미터는 여전히 -4를 인용합니다. 핵심 알고리즘은 L, R, C에 1.0, Ls와 Rs에 1.41(약 +1.5 dB)의 가중치를 주고 LFE를 제외하며, 적용 범위는 "from one to five channels"입니다. BS.1770-5는 부속서에서 그 너머로 확장해 BS.2051 어드밴스드 사운드 시스템과 객체 기반 오디오를 다루는데, 후자는 측정하기 전에 반드시 렌더링되어야 합니다. 따라서 이머시브 라우드니스는 파일의 속성이 아니라 렌더의 속성이며, 목표 레이아웃을 바꾸면 숫자도 바뀝니다. BS.2127을 준수하는 렌더를 이름이 명시된 BS.2051 레이아웃으로 만들어 BS.1770-5 미터로 측정하고, 이 셋을 모두 납품 노트에 기록하십시오. BS.2127은 기준 ADM 렌더러를 정의하며, 그 오픈소스 형제인 EBU ADM Renderer(EBU Tech 3388)가 재현 가능한 수치를 얻는 실질적인 방법입니다.

이머시브 납품에 대해 통합 라우드니스 목표치를 공개한 음악 스트리밍 서비스는 하나도 없습니다. 포럼과 벤더 교육 자료에 수치가 돌아다니지만 어느 것도 공개된 규격이 아니며, 이 글은 그런 수치를 규격인 양 옮겨 싣지 않겠습니다. 공개되어 있는 것은 채널 기반 스테레오에 관한 것입니다. Spotify의 통합 목표치 −14 LUFS와 트루 피크 상한 −1 dBTP, −14 LUFS를 넘으면 −2 dBTP로 조여지는 것, 그리고 AES TD1008의 음악용 −16 LUFS입니다(TD1008의 −18 LUFS는 말 중심 콘텐츠에 적용되며, −18을 음악 목표치로 제시하는 것은 흔하면서도 중대한 오류입니다).

Dolby Atmos는 Dolby Laboratories의 독점 라이선스 기술이고, Sony 360 Reality Audio는 MPEG-H 위에 구축된 독점 시스템입니다. 그 요구 사항은 소유자가 정하고 ITU나 EBU의 일정과 무관하게 바뀌므로 여기 적지 않습니다. 어떤 제휴나 보증 관계도 주장하지 않습니다. 라이선서 자신의 최신 문서를 읽으십시오.

보내기 전에 확인할 것

구조 검사가 먼저입니다. 빠르고, 뒤따르는 모든 것을 무효로 만들기 때문입니다.

• 첫 4바이트가 BW64인지. RIFF로 읽힌다면 그것은 평범한 WAV이고 4 GB를 넘을 수 없습니다.
• ds64가 시그니처 다음의 첫 청크이고, 그 64비트 크기가 디스크상의 파일 크기 및 data 크기와 일치하며, 크기가 초과된 data 외 청크마다 표에 ChunkSize64 항목이 있는지.
• axml을 data 뒤까지 포함해 명시적으로 찾을 것. 부분 스캔만으로 "ADM 없음"이라고 결론짓지 마십시오.
• fmt 의 샘플레이트와 비트 심도가 납품 규격과 정확히 일치하는지. ADM 작성 이후의 샘플레이트 변환은 금물입니다. 샘플로 표현된 모든 rtime과 duration을 무효로 만듭니다.
• fmt .nChannels가 chna.numTracks와 같은지, 모든 trackIndex가 범위 안에 있고 1부터 시작하는지.
• 모든 chna 항목이 정확히 40바이트이고 고정폭 필드가 올바르게 패딩되었는지, 0x1000 이상인 모든 packRef가 axml에 존재하는 커스텀 정의로 해석되는지.
• 모든 audioContentIDRef, audioObjectIDRef, audioPackFormatIDRef, audioChannelFormatIDRef, audioTrackUIDRef가 해석되는지. 양방향 모두 허공에 뜬 간선이 0이고 순환 참조가 없어야 합니다.
• 다중 블록 채널 포맷은 모든 블록에 rtime과 duration을 함께 담고 있는지, 블록이 연속적이고 단조 증가하는지, 객체가 00:00:00.00000에서 시작하는지.
• 선언된 베드의 모든 채널에 있어야 할 것이 들어 있는지. 디지털 블랙은 조사하십시오.
• bext 시작 타임코드가 납품물 전체에서 일관되는지, 스테레오와 바이노럴 컨폼이 현재 마스터에서 다시 렌더링되었는지. 이머시브 부모보다 40 ms 이른 컨폼은 파일 존재 검사는 통과하고 동기 청취에서는 걸립니다.
• 모든 납품물의 체크섬을 내고 매니페스트를 보관하며, ADM XML은 BW64와 별도로 아카이브하십시오. 나중에는 다시 파싱해야만 하는 바이너리보다 diff할 수 있는 XML이 더 값집니다.

BW64와 ADM은 공개되어 있고 누구나 무료로 읽을 수 있는 표준이며, 이 점은 활용할 가치가 있습니다. BS.2088과 BS.2076을 직접 읽고, 40줄짜리 코드로 chna 청크를 파싱해서, 벤더 익스포터의 대화 상자가 주장하는 것이 아니라 실제로 무엇을 썼는지 검증할 수 있습니다. 불필요한 이머시브 반려는 거의 전부 밸리데이터가 1초 안에 잡아내는 참조 무결성 오류입니다.

Mazufa의 무료 BW64/ADM 인스펙터는 mazufa.com/immersive-master-check에 있습니다. 컨테이너와 메타데이터를 전부 당신 기기 안에서 파싱하고 아무것도 업로드하지 않으므로, 계약상 건물 밖으로 나갈 수 없는 소재에도 쓸 수 있습니다. Mazufa 자체는 발매가 무료이고, 수수료는 0%이며, 초대제로 운영되면서 완성된 신청서는 모두 사람이 검토합니다.

출처

ITU-R 권고

• ITU-R BS.2088-2 (11/2025), Long-form file format for the international exchange of audio programme materials with metadata (BW64) — https://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.2088-2-202511-I!!PDF-E.pdf
• ITU-R BS.2076-3 (02/2025), Audio Definition Model — https://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.2076-3-202502-I!!PDF-E.pdf
• ITU-R BS.1770-5 (11/2023), Algorithms to measure audio programme loudness and true-peak audio level — https://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.1770-5-202311-I!!PDF-E.pdf
• ITU-R BS.2051-2 (07/2018), Advanced sound system for programme production — https://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.2051-2-201807-S!!PDF-E.pdf
• ITU-R BS.2127-1 (11/2023), Audio Definition Model renderer for advanced sound systems — https://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.2127-1-202311-I!!PDF-E.pdf

EBU 기술 문서

• EBU Tech 3306, RF64: An extended file format for audio data — https://tech.ebu.ch/docs/tech/tech3306.pdf
• EBU Tech 3285 (and supplements), Specification of the Broadcast Wave Format — https://tech.ebu.ch/files/live/sites/tech/files/shared/tech/tech3285s7.pdf
• EBU Tech 3392, ADM Broadcast Production Profile — https://tech.ebu.ch/files/live/sites/tech/files/shared/tech/tech3392.pdf
• EBU Tech 3388, ADM Renderer for use in Next Generation Audio broadcasting — https://tech.ebu.ch/publications/tech3388
• EBU ADM Guidelines — CHNA chunk — https://adm.ebu.io/reference/excursions/chna_chunk.html
• EBU ADM Guidelines — BW64 and ADM — https://adm.ebu.io/reference/excursions/bw64_and_adm.html
• EBU ADM Guidelines — audioTrackUID — https://adm.ebu.io/reference/adm_elements/audio_track_uid.html
• libbw64 reference implementation — https://github.com/ebu/libbw64

AES

• AES TD1008, Recommendations for loudness of internet audio streaming and on-demand distribution — https://www.aes.org/community/technical-council/technical-document-aestd1008/

서비스 문서

• Spotify, Loudness normalization — https://support.spotify.com/us/artists/article/loudness-normalization/