Áudio imersivo em BW64 e ADM: entregando bateria de escola de samba, roda e capoeira como objetos

Referência técnica para quem prepara masters imersivos no Brasil — inclusive (principalmente) para quem vai entregar um arquivo que não tem como escutar direito.

Resposta curta

O ADM (Audio Definition Model, Recomendação ITU-R BS.2076) é um modelo de metadados aberto que descreve o que cada faixa de áudio de um arquivo é — um canal de caixa acústica, um objeto que se move, ou uma componente Ambisonics — e como essas faixas se combinam num programa. Ele viaja como XML dentro de um contêiner BW64 (Recomendação ITU-R BS.2088), uma extensão de 64 bits do RIFF/WAVE que existe justamente para furar o teto de 4 GB do WAV clássico. Entrega imersiva reprova em QC porque áudio e metadado são duas coisas separadas que precisam concordar exatamente, e nada no formato obriga isso: um fmt que discorda do chna, um audioTrackUID que nenhum objeto referencia, um bloco cujo tempo anda para trás, um bed descrito no XML que nunca foi impresso em disco — tudo isso é silencioso num editor de forma de onda e fatal num renderizador. Conferir ADM é checar integridade referencial, não escutar. E é exatamente por isso que a maior parte do trabalho é verificável mesmo num estúdio brasileiro que só tem par de near-fields e um sub.

1. A bateria de escola de samba é o argumento object-based mais forte que o Brasil tem

Antes do contêiner, o modelo. E antes do modelo, o caso de uso — porque quase todo erro de entrega imersiva começa com alguém tratando como "canal" uma coisa que é, na verdade, um objeto.

Uma bateria de escola de samba de Grupo Especial tem entre duzentos e trezentos ritmistas dispostos numa formação fixa. Não é uma multidão: é uma arquitetura. Os surdos ocupam o fundo, divididos em surdo de primeira, de segunda e de terceira (ou "centrador"), cada naipe em fileiras. À frente e nas laterais vêm as caixas, os repiniques, os tamborins — que costumam ficar juntos e em bloco, porque fazem viradas coreografadas —, as cuícas, os agogôs, o chocalho e o reco-reco. O mestre fica de frente para o conjunto, e o apito dele corta o campo inteiro.

Essa geometria não é decoração de palco. Ela carrega informação musical.

1.1 O surdo de primeira e o de segunda estão conversando

O andamento do samba de enredo é sustentado por uma pergunta e uma resposta: o surdo de segunda marca o primeiro tempo, o surdo de primeira responde no segundo. É uma conversa entre dois naipes que estão fisicamente em pontos diferentes da bateria. O surdo de terceira preenche entre eles, com liberdade rítmica.

Quando você colapsa isso em estéreo, os dois naipes viram a mesma coisa: uma massa grave centrada, tocando colcheias. A alternância continua existindo no tempo, mas some no espaço — e é no espaço que ela era legível. Quem estava dentro da quadra ouviu dois lugares diferentes se revezando; quem escuta o estéreo ouve um lugar só, mais rápido. A conversa foi destruída, não reduzida.

Áudio baseado em objetos resolve isso pelo motivo certo, não por marketing: cada naipe recebe uma posição, e a posição é preservada e re-derivada em qualquer sala de reprodução, em vez de ser pré-misturada em pares de canais que assumem onde as caixas estão.

1.2 A bateria anda — e isso é um caso legítimo de objeto que varia no tempo

O detalhe que torna o exemplo incontornável: na avenida, a bateria não fica parada. Ela desfila, entra no recuo, permanece ali enquanto o resto da escola passa, e depois volta a se deslocar. Do ponto de vista de qualquer ponto fixo de escuta — um camarote, uma arquibancada, um par de microfones de ambiência — a fonte muda de azimute e de distância ao longo do programa.

Isso não é uma metáfora de objeto. É a definição literal de um audioBlockFormat com rtime e duration que se sucedem. Um bed de 7.1.4 não representa uma bateria que se desloca: representa uma bateria que ficou onde estava. Um objeto com automação de posição representa. Essa é a diferença prática entre os dois modelos, e a bateria é o exemplo brasileiro em que ela custa mais caro ignorar.

2. Os três tipos de áudio, e por que a distinção decide o formato do arquivo

Áudio baseado em canais. Cada faixa é atribuída a uma posição fixa de caixa acústica. Estéreo é baseado em canais; 5.1 também; um "bed" 7.1.4 também. A posição está embutida na identidade do canal: a faixa 3 é o centro, e é o centro em todo sistema que a reproduzir. A ITU-R BS.2051 formaliza isso para sistemas avançados, descrevendo os layouts como contagem de camadas superior + média + inferior: o Sistema A é 0+2+0 (estéreo), o Sistema B é 0+5+0 (5.1), o Sistema D é 4+5+0, o Sistema J é 4+7+0 e o Sistema H é 9+10+3, o 22.2. No ADM, conteúdo baseado em canais usa a typeDefinition DirectSpeakers, typeLabel 0001.

Áudio baseado em objetos. Uma faixa mono (ou um pack multicanal) mais metadados de posição que mudam com o tempo. Quem decide quais alto-falantes reais reproduzem aquilo é o renderizador, com base no layout que de fato existe na sala. Nada na faixa pressupõe uma caixa. É a typeDefinition Objects, typeLabel 0003. A bateria em deslocamento vive aqui.

Áudio baseado em cena. Na prática, Ambisonics de ordem alta (HOA): o campo sonoro inteiro codificado como um conjunto de componentes de harmônicos esféricos. Nenhuma componente corresponde sozinha a uma direção; a direção emerge da combinação linear. É typeDefinition HOA, typeLabel 0004. O ADM define ainda Matrix (0002), para sinais matriciados como M-S ou Lt/Rt, e Binaural (0005), para pares já prontos para fone.

Áudio baseado em canais diz ao arquivo onde estão as caixas; áudio baseado em objetos se recusa a adivinhar; áudio baseado em cena descreve o campo em vez das fontes.

A assimetria importante é esta: uma entrega baseada em canais sobrevive como WAV cru — acerte a ordem dos canais e ela toca. Uma entrega baseada em objetos ou em cena é literalmente sem sentido sem os metadados: o áudio é um monte de fluxos mono indiferenciados, e o ADM é a única coisa que diz o contrário. É essa assimetria que justifica a existência do BW64 e do ADM, e é ela que faz o QC imersivo ser mais difícil que o QC de estéreo.

3. Quadra e avenida: dois espaços acústicos, duas decisões de bed

A mesma bateria soa como dois instrumentos diferentes conforme o espaço, e a decisão de bed muda junto.

A quadra é um galpão: laje ou telhado metálico, piso duro, paredes paralelas, público em volta e a bateria numa cabine ou num canto elevado. É um espaço reverberante e fechado, com reflexões de teto reais e fortes. O campo difuso é parte do som — quem já gravou ensaio de quadra sabe que os microfones de ambiência entregam metade do caráter. Aqui um bed com camada de altura faz sentido físico: existe teto, existe energia vindo de cima, e o bed é a representação honesta do que a sala devolve.

A avenida é o oposto: um corredor aberto, sem teto, com arquibancadas e camarotes de concreto dos dois lados e uma pista longa. Não há reflexão superior; há reflexões laterais duras e um campo que muda continuamente porque a fonte se move em relação ao ouvinte. Aqui a camada de altura do bed tende a ficar vazia ou a receber apenas ambiência de público das arquibancadas superiores — e é justamente aqui que aparece o erro de QC mais chato do documento: um bed 7.1.4 declarado no XML cujos canais de altura foram impressos em silêncio digital. Estruturalmente perfeito, musicalmente vazio.

A escolha razoável para a avenida costuma ser bed enxuto para o ambiente + objetos para os naipes, com a bateria como um grupo de objetos que se desloca. Para a quadra, bed mais generoso + objetos para os naipes, porque a sala é uma fonte legítima e um bed é a maneira eficiente de descrevê-la.

4. Roda de samba e roda de capoeira: o ouvinte dentro do círculo

A bateria é o caso grande. Os dois casos pequenos são circulares, e circulares de maneiras diferentes.

4.1 A roda de samba

Numa roda, os músicos estão em volta de uma mesa e o ponto de escuta natural não está fora do conjunto: está dentro dele. Cavaquinho, banjo, pandeiro, tantã, repique de mão, surdo, reco-reco e as vozes ocupam posições ao redor de um círculo de dois ou três metros. Quem canta responde ao lado de quem toca.

Isso inverte a lógica da gravação de palco. Não existe "frente". A imagem correta não é um leque de 60° na sua frente: é 360° com o ouvinte no centro, e é exatamente o que um render object-based ou HOA sabe fazer e um estéreo não sabe. Numa roda pequena, o número de fontes é baixo o suficiente para que um objeto por músico seja perfeitamente prático — oito a doze objetos, posições estáticas, um audioBlockFormat cada.

4.2 A roda de capoeira

A roda de capoeira é circular como a de samba, mas com uma diferença estrutural: a bateria de capoeira fica concentrada num único ponto do círculo. Os três berimbaus — gunga, médio e viola — mais pandeiros, atabaque, agogô e reco-reco ocupam um arco pequeno, e todo o resto da circunferência é ocupado pelo coro e pelas palmas dos participantes, que respondem ao chamado e formam um anel contínuo de fonte.

Musicalmente, é o gunga que comanda: o toque define o jogo, e uma mudança de toque muda o evento inteiro. Espacialmente, isso significa que uma fonte pequena, direcional e fixa governa um campo grande e envolvente. É a configuração ideal para uma abordagem híbrida:

• os berimbaus e a percussão de bateria como objetos discretos, agrupados num arco estreito com posições precisas;
• o coro e as palmas como cena (HOA) ou como um bed, porque são um anel difuso, não fontes localizáveis;
• o contramestre ou o solista que canta como um objeto próprio, para poder ser mixado sem mexer no coro.

Em ADM isso se escreve limpo: um audioProgramme, dois ou três audioContent (percussão, canto, ambiência), e audioObject distintos apontando para audioPackFormat de tipos diferentes. Nada disso exige um estúdio caro. Exige clareza sobre o que é fonte e o que é campo.

5. BW64: por que o contêiner existe — a aritmética do teto de 4 GB

WAV clássico é um arquivo RIFF. RIFF, de 1991, prefixa cada chunk com um campo de tamanho de 32 bits. Trinta e dois bits endereçam 4 294 967 296 bytes — 4 GiB — e esse é o teto rígido tanto do arquivo inteiro quanto do chunk data dentro dele.

Fazendo a conta com material real (taxa PCM = canais × bytes por amostra × taxa de amostragem):

Contas: 36 × 3 bytes × 96 000 = 10 368 000 bytes por segundo; 4 294 967 296 ÷ 10 368 000 = 414,25 s = 6 min 54 s.

Agora aplique isso a um caso brasileiro concreto: uma gravação contínua de duas horas de ensaio de quadra com bed 7.1.4 e 24 objetos a 96 kHz/24 bits ocupa 10 368 000 × 7 200 = 74 649 600 000 bytes, ou aproximadamente 69,5 GiB — cerca de 17,4 vezes o teto do RIFF. Não é um caso extremo de laboratório: é um sábado de ensaio gravado sem parar. Um escritor de WAV que bate no limite produz um arquivo truncado, ou um arquivo cujos tamanhos declarados deram a volta silenciosamente.

A EBU resolveu isso primeiro com o RF64 (EBU Tech 3306). A ITU levou o trabalho adiante como Recomendação ITU-R BS.2088, Long-form file format for the international exchange of audio programme materials with metadata — o BW64. A BS.2088 é explícita quanto ao mecanismo: "The ID 'BW64' is used instead of 'RIFF' in the first four bytes of the file", e os campos originais de 32 bits viram bandeiras de escape: "If the 32-bit value in the field is 0xFFFFFFFF the 64-bit value in the 'ds64' chunk is used instead."

O BW64 não alarga os campos de tamanho do RIFF: ele os preenche com 0xFFFFFFFF como sentinela e coloca os tamanhos verdadeiros de 64 bits num chunk ds64 que precisa vir primeiro no arquivo.

Vale enxergar a linhagem: RIFF/WAVE deu o contêiner em chunks; Broadcast Wave (BWF, EBU Tech 3285) acrescentou o chunk bext — originador, referência de timecode, histórico de codificação; BW64 mantém tudo isso, acrescenta endereçamento de 64 bits e acrescenta os chunks que carregam o ADM. Um BW64 abaixo de 4 GiB é compatível byte a byte com um leitor de WAV em tudo, exceto na assinatura de quatro caracteres — muitas ferramentas aceitam, e algumas teimosamente não.

6. O layout dos chunks, byte a byte

Pela BS.2088, espera-se que um arquivo BW64 contenha ao menos <ds64-ck>, <fmt-ck>, <chna-ck>, <axml-ck> (com <bxml-ck> e <sxml-ck> como portadores alternativos de metadado) e <wave-data>.

6.1 ds64 — a tabela de tamanhos de 64 bits

Tem de ser o primeiro chunk depois da assinatura BW64, porque um leitor precisa conhecer os tamanhos reais antes de conseguir percorrer qualquer outra coisa. Os campos são metades de 32 bits de quantidades de 64 bits:

A table[] importa mais do que parece. Um axml que descreve dezenas de objetos com automação sample-accurate cresce rápido: 24 objetos com um bloco a cada 20 ms ao longo de duas horas dão 24 × 360 000 = 8 640 000 blocos; a 400 bytes de XML por bloco, isso é cerca de 3,2 GiB de axml — ainda abaixo do teto, mas na mesma ordem de grandeza dele. Baixe para um bloco a cada 100 ms e você tem 1 728 000 blocos, ~0,64 GiB. A table[] é justamente o mecanismo pelo qual um chunk que não seja o data declara um tamanho de 64 bits.

6.2 fmt — a descrição da essência

Chunk WAVE padrão: formato de amostra, taxa de amostragem, contagem de canais, bits por amostra, block align. É a única declaração autoritativa de quantos canais intercalados existem de fato no data. Tudo depois disso é metadado sobre esses canais, e metadado pode mentir.

6.3 chna — a tabela de alocação de canais, e a aritmética dos 40 bytes

O chna é a ponte entre faixas físicas e o ADM. Ele abre com:

• ckID — 4 bytes, 'chna'
• ckSize — 4 bytes
• numTracks — 2 bytes, faixas no arquivo
• numUIDs — 2 bytes, entradas audioTrackUID que seguem

Depois vem um vetor plano de entradas audioID de largura fixa. Cada entrada tem exatamente 40 bytes:

2 + 12 + 14 + 11 + 1 = 40. Confira a largura contando os caracteres: ATU_00000001 tem 12 caracteres, AT_00031001_01 tem 14, AP_00031001 tem 11. As larguras não são sugestões — são ASCII de largura fixa, e um escritor que emite um UID de 13 caracteres produziu uma tabela corrompida, não uma tabela levemente incomum.

Fechando a conta do chunk inteiro para a nossa sessão de bateria: 36 faixas e, digamos, 40 UIDs (alguns naipes trocam de definição no meio do programa) dão corpo de 2 + 2 + (40 × 40) = 1 604 bytes, e o chunk completo com ckID e ckSize mede 1 612 bytes. Com 36 UIDs seriam 1 444 e 1 452. Um chna é pequeno: o custo de conferi-lo é zero e o custo de não conferi-lo é uma reprovação.

Repare também na convenção de IDs: valores de 0x0FFF para baixo referem-se às definições comuns do ADM — os formatos de canal e de pack padronizados — enquanto 0x1000 para cima indicam definições customizadas, que precisam estar presentes no axml. Um packRef AP_00010003 é 5.1 por definição comum e não precisa de XML; AP_00031001 é um pack de objetos customizado e, sem XML, fica pendurado no vazio.

Um track UID é o número de série que o arquivo dá à identidade de uma faixa física, e ele existe justamente para que uma faixa possa legitimamente mudar o que carrega no meio do programa.

Esse último ponto é a razão de numUIDs poder ser maior que numTracks. A orientação da EBU registra que, quando "os elementos de áudio de uma faixa podem ser [definidos] de maneira diferente ao longo de um arquivo … haverá um UID diferente para cada definição". Um trackIndex pode, portanto, aparecer em várias entradas — e isso é comum em captação de escola de samba, em que a mesma linha de microfone serve o ensaio na quadra e depois a passagem na avenida. Ferramentas de QC que assumem um UID por faixa reprovam arquivos corretos.

6.4 axml — o ADM propriamente dito

Um documento XML em UTF-8 com a árvore <audioFormatExtended>. É texto, é inspecionável, e é onde vive praticamente toda falha interessante. Como é UTF-8, nomes com acento — Repinique de Mão, Surdo de Terceira, Berimbau Gunga — cabem sem problema em campos de nome; o que não cabe é acento nos identificadores, que são ASCII de largura fixa por definição.

6.5 data — o PCM intercalado

Amostras intercaladas, exatamente como em WAV. Nada dentro de data sabe qualquer coisa sobre objetos.

6.6 Ordem — e a armadilha que pega todo mundo

ds64 primeiro, sempre. fmt antes de data. E o axml pode legitimamente vir depois do data, e frequentemente vem, porque — como a própria BS.2088 observa — durante a gravação "o metadado XML provavelmente terá comprimento desconhecido". Um arquivo com axml no fim não está malformado; mas um leitor que só varre o primeiro megabyte vai relatar que não há ADM nenhum. Boa parte dos relatos de "meu arquivo perdeu os metadados" é isto, e nada mais.

7. O modelo ADM: um grafo de referências

A ITU-R BS.2076 divide o modelo em duas metades. A parte de formato "descreve a natureza técnica do áudio, para que ele possa ser decodificado ou renderizado corretamente", e pode ser escrita antes de existir qualquer áudio. A parte de conteúdo descreve "o idioma do diálogo, o loudness, etc." e só pode ser completada quando os sinais existem. Saber a qual metade um elemento pertence diz em que etapa da produção o erro entrou.

A hierarquia, de cima para baixo:

• audioProgramme — uma apresentação completa. Referencia um ou mais audioContent.
• audioContent — um componente com significado editorial: percussão, vozes, ambiência de público. Referencia um ou mais audioObject.
• audioObject — a junção entre intenção editorial e formato técnico. Carrega tempo de início e duração, e referencia zero ou mais audioPackFormat, zero ou mais audioObject aninhados e zero ou mais audioTrackUID.
• audioPackFormat — um grupo de canais que anda junto: um bed 7.1.4, um par estéreo, um conjunto HOA de ordem definida.
• audioChannelFormat — o comportamento de um canal ao longo do tempo. Contém um ou mais audioBlockFormat.
• audioBlockFormat — o átomo. Para Objects: posição (azimuth/elevation/distance, ou cartesiana X/Y/Z), ganho, tamanho, difusidade, mais rtime e duration. Objeto estático = um bloco. Objeto que se move = uma sequência.
• audioTrackUID — a folha, e o único elemento que corresponde a uma faixa física. Tem atributos opcionais sampleRate e bitDepth.

audioStreamFormat e audioTrackFormat ficam entre o formato de canal e o track UID. A BS.2076-3 observa que, para PCM, eles são efetivamente redundantes — "o audioStreamFormat e o audioTrackFormat deveriam ser omitidos" — mas que leitores "devem estar cientes de que arquivos ADM existentes (baseados na Recomendação ITU-R BS.2076-2 e anteriores) para áudio PCM podem contê-los". As duas formas são legais. Um validador que exige uma delas está errado sobre a outra.

O ADM é um grafo de referências, não um documento aninhado, e toda falha séria de entrega é uma aresta quebrada nesse grafo.

Escrevendo a bateria nesse modelo. Um audioProgramme "Desfile"; um audioContent "Bateria"; dentro dele, um audioObject por naipe — surdo de primeira, surdo de segunda, surdo de terceira, caixas, repiniques, tamborins, cuícas, agogôs — cada um apontando para um audioPackFormat de objetos e para os audioTrackUID das faixas correspondentes; um audioObject separado para o apito do mestre, porque ele precisa ser posicionado e mixado independentemente; e um audioContent "Ambiência" com um pack DirectSpeakers para o bed. Os naipes que se deslocam ganham sequências de audioBlockFormat com azimute variando ao longo do desfile; os que ficam parados ganham um bloco só.

O que acontece de fato quando uma referência fica pendurada. Não há um comportamento único, e esse é o problema. Um renderizador que resolve um audioPackFormatIDRef apontando para um pack ausente do XML pode abortar a leitura e rejeitar o arquivo; pode pular aquele objeto e renderizar o resto, produzindo uma mixagem silenciosamente sem um naipe; ou pode recorrer às definições comuns, encontrar um ID na faixa customizada 0x1000+ sem correspondência, e substituir por silêncio. Os três desfechos são "o arquivo abriu". Só um deles é pego escutando — e só se você souber que os tamborins deveriam estar lá. Um ouvido humano não escuta uma ausência que ninguém avisou que era pra existir.

8. Renderização: BS.2127 para os layouts da BS.2051

Um arquivo ADM não tem "um som". Ele tem tantos sons quantos forem os layouts-alvo. A ITU-R BS.2127 define o renderizador ADM de referência para sistemas avançados, e a ITU-R BS.2051 define os layouts para os quais ele renderiza. O irmão de código aberto da BS.2127, o EBU ADM Renderer (EBU Tech 3388), é a forma prática de obter um resultado reproduzível.

Isso muda como se fala de uma entrega imersiva. Uma mesma roda de samba renderizada para o Sistema B (0+5+0) e para o Sistema J (4+7+0) produz duas distribuições de energia diferentes — na primeira, tudo que estava acima do plano do ouvinte é rebaixado; na segunda, não. Nenhuma das duas é "o arquivo": as duas são renders. Por isso, ao registrar qualquer medição, nomeie o layout e o renderizador, não só o número.

9. Loudness imersivo sob a BS.1770-5

Aqui é essencial separar o que é publicado do que apenas circula.

9.1 O que a Recomendação especifica

A ITU-R BS.1770 tem seis edições — -0 (2006), -1 (2007), -2 (2011), -3 (2012), -4 (2015) e -5 (novembro de 2023). A BS.1770-5 está em vigor; a BS.1770-4 (outubro de 2015) está superada, ainda que seja a edição que a maioria dos medidores instalados continua citando. Cite a -5.

A BS.1770 define a ponderação K: um filtro de duas etapas — um high-shelf (o filtro "head", que modela uma esfera rígida) seguido de um passa-altas RLB. O ganho da curva K em 1 kHz é +0,698 dB (linear 1,0836). A medição usa blocos de 400 ms com 75% de sobreposição, um gate absoluto que descarta blocos abaixo de −70 LUFS, e um gate relativo calculado a partir da média dos blocos que sobreviveram ao gate absoluto, deslocada em −10 LU. Esse gate relativo não é a média não-gated — é uma distinção que implementações erram com frequência suficiente para importar.

A ponderação de canais no algoritmo central é 1,0 (0 dB) para L, R e C, e 1,41 (≈ +1,5 dB) para Ls e Rs, com o LFE excluído. O algoritmo base é definido "de um a cinco canais". A BS.1770-5 vai além disso nos anexos, cobrindo os sistemas avançados da BS.2051 — alto-falantes em posições arbitrárias e canais de altura — e áudio baseado em objetos, que precisa ser renderizado antes de poder ser medido.

Loudness imersivo não é propriedade do arquivo; é propriedade de um render. Trocar o layout-alvo troca o número.

Essa é a diferença substantiva em relação ao estéreo. Um master estéreo tem um valor de loudness. Um master baseado em objetos tem tantos quantos forem os alvos de render, e a forma honesta de declarar um número é nomear o layout em que foi medido e o renderizador usado.

Documentos EBU relacionados. A EBU Tech 3341 define o comportamento dos medidores (momentâneo 400 ms, short-term 3 s). A EBU Tech 3342 define o Loudness Range (LRA), que usa gate relativo de −20 LU — não −10 LU; usar −10 no LRA é um bug de implementação clássico. A EBU R 128 fixa o alvo de programa de radiodifusão em −23 LUFS, e é prática de radiodifusão, não especificação de streaming musical.

True peak. Medido em sinal superamostrado (mínimo 4× pela BS.1770; 8× é melhor). Pico de amostra não é true peak, e picos entre amostras podem ultrapassar o maior valor amostrado — coisa que percussão de ataque rápido, que é o assunto deste documento inteiro, produz o tempo todo.

9.2 O que é publicado para música

Para música estéreo baseada em canais, o Spotify publica alvo integrado de −14 LUFS e teto de true peak de −1 dBTP, apertando para −2 dBTP se o master for mais alto que −14 LUFS (support.spotify.com/us/artists/article/loudness-normalization/). A AES TD1008 recomenda −16 LUFS para música; a cifra de −18 LUFS do mesmo documento vale para conteúdo falado (jornalismo, entrevista, radiodrama), e afirmar −18 como alvo musical é um erro comum e sério.

9.3 O que não é publicado

Nenhum serviço de streaming musical publica um alvo de loudness integrado para entrega imersiva. Circulam números em fóruns e em material de treinamento de fabricantes; alguns são plausíveis e alguns provavelmente estão certos. Nenhum deles é especificação publicada, e este documento não vai repetir nenhum como se fosse.

O mesmo vale, aliás, para estéreo fora do Spotify: Apple Music, YouTube Music, Amazon Music, TIDAL e Deezer não publicam alvo de normalização. As cifras que se vê por aí (Apple ≈ −16, YouTube Music ≈ −14, Amazon ≈ −14, TIDAL ≈ −14, Deezer ≈ −15) são amplamente divulgadas, mas não publicadas pelo serviço — e não servem para calcular ganho nenhum.

Se você precisa de um número imersivo defensável hoje: meça um render conforme a BS.2127 para um layout nomeado da BS.2051 com um medidor BS.1770-5, e declare os três nas notas de entrega.

9.4 Sobre sistemas proprietários

Dolby Atmos é tecnologia proprietária e licenciada da Dolby Laboratories, e o Sony 360 Reality Audio é um sistema proprietário construído sobre MPEG-H. Os requisitos de entrega deles são definidos pelos respectivos donos e mudam sem relação com o calendário da ITU ou da EBU. Nada aqui constitui declaração dos requisitos dessas empresas, e nenhuma afiliação, certificação ou endosso é reivindicado ou sugerido. Onde um licenciador publica um requisito, leia a documentação atual do próprio licenciador e cite aquilo.

10. A posição honesta: quase nenhum estúdio brasileiro tem monitoração imersiva

Vale dizer isto sem rodeio, porque é o contexto real de quem lê: praticamente nenhum estúdio de música no Brasil tem sala de monitoração imersiva calibrada. Existem algumas casas de pós-produção — audiovisual, publicidade, cinema — com salas montadas para camada de altura, e elas são poucas e concentradas em duas ou três cidades. A esmagadora maioria dos produtores, mixadores e engenheiros brasileiros que vai preparar um master imersivo vai fazê-lo com fone e um par de near-fields, checando em binaural.

Isso não é motivo para não entregar. É motivo para saber o que dá para garantir e o que não dá.

O que você consegue verificar com absoluta certeza sem monitoração imersiva:

• que o arquivo é BW64 de verdade e que o ds64 bate com o tamanho em disco;
• que fmt.nChannels é igual a chna.numTracks;
• que toda entrada do chna tem 40 bytes e todo trackIndex está dentro do intervalo;
• que todo packRef em 0x1000+ resolve para uma definição presente no axml;
• que nenhuma referência do grafo ADM está pendurada, nos dois sentidos;
• que os audioBlockFormat são contíguos e monotônicos, e que as durações somam a duração do audioObject pai;
• que taxa de amostragem e profundidade de bits batem com a especificação de entrega e entre fmt e XML;
• que nenhum canal de bed declarado está em silêncio digital por acidente;
• que os conforms estéreo e binaural têm exatamente a mesma duração e o mesmo timecode de início do master.

Isso é a maior parte das reprovações. Praticamente todas elas são erros de integridade referencial que um validador pega em menos de um segundo — e nenhuma delas exige uma sala.

O que você não consegue julgar sem a sala: se a altura está exagerada, se um objeto está longe demais, se o campo difuso ficou grande demais. Para isso, a atitude defensável é conservadora: mantenha os elementos estruturais da música no plano do ouvinte — no nosso caso, os surdos, as caixas e as vozes — e use a camada de altura para ambiência, público e reflexões, que são justamente o que o ouvido perdoa quando o balanço não está perfeito. Um desfile em que o surdo de primeira vai parar no teto é um erro audível em qualquer sistema; um desfile com um pouco de arquibancada a mais na altura, não.

Existe um inspetor BW64/ADM gratuito e baseado em navegador em mazufa.com que interpreta o contêiner e os metadados inteiramente no seu próprio dispositivo, sem enviar nada — o que o torna utilizável em material que contratualmente não pode sair da sala.

11. Falhas de QC mais comuns, e como detectar cada uma

Contagem de canais divergente entre fmt e chna. O fmt diz 36, o chna diz 34. Em geral, um bounce mudou a contagem de faixas depois que o metadado foi escrito. Detecção: leia os dois chunks e compare inteiros. É a checagem mais barata do pipeline inteiro e pega uma fatia surpreendente das falhas.

Track UIDs órfãos. Um UID no chna que nenhum audioObject referencia (áudio que nada vai renderizar), ou um audioTrackUIDRef no XML sem entrada correspondente no chna (metadado esperando uma faixa que não existe). Detecção: monte os dois conjuntos e tire a diferença simétrica; ela tem de ser vazia. A EBU Tech 3392 é explícita: "Se o audioObject se refere a um audioPackFormat, ele deve também se referir aos audioTrackUIDs correspondentes."

Blocos com tempo faltando ou não monotônico. A BS.2076 não deixa margem: "Quando há mais de um audioBlockFormat dentro de um audioChannelFormat … tanto rtime quanto duration devem estar presentes." A EBU Tech 3392 aperta com uma regra de contiguidade: "rtime + duration de um audioBlockFormat deve coincidir com o rtime do bloco seguinte", com o primeiro bloco começando em 00:00:00.00000 e nenhum bloco menor que uma amostra. Detecção: percorra os blocos na ordem do documento e verifique rtime[n] + duration[n] == rtime[n+1]. As falhas aparecem em três formatos: lacunas (comportamento indefinido — alguns renderizadores seguram a última posição, outros mutam), sobreposições, e blocos fora de ordem cronológica. Automação de bateria em deslocamento é onde isso mais aparece.

Taxa de amostragem ou profundidade de bits contraditórias. O audioTrackUID pode trazer sampleRate e bitDepth. Quando contradizem o fmt , você tem duas afirmações sobre a mesma essência. A posição da EBU Tech 3392 é que esses atributos "devem ser ignorados se disponíveis na essência de áudio" — mas nem todo renderizador segue isso. Pior: conversão de taxa de amostragem depois da autoria do ADM invalida todo rtime e duration expresso em amostras. Nunca converta depois.

Conform estéreo ou binaural ausente ou fora de sincronia. A falha recorrente não é a ausência — ausência é óbvia — e sim o desvio: o conform foi renderizado de uma versão anterior, está alguns frames deslocado, ou tem timecode de início diferente. Detecção: compare durações amostra a amostra, compare o timecode do bext e correlacione o conform contra um render nulo do master. Qualquer conform que não seja derivável do master atual deve ser refeito, não reconferido.

Bed declarado que não está no arquivo. O XML declara um pack DirectSpeakers 7.1.4 — doze canais — mas só o subconjunto 5.1 foi impresso, ou os canais de altura estavam mutados no bounce e saíram como silêncio digital. O grafo está íntegro; o áudio não. Detecção: checagem estrutural não pega isso. É preciso análise de essência: para cada canal reivindicado por um pack DirectSpeakers, medir se há sinal. Silêncio digital não é automaticamente erro — uma mixagem legítima pode deixar um canal traseiro superior vazio —, mas é sempre motivo para decisão humana.

O contêiner pode estar perfeitamente válido, o XML perfeitamente bem-formado, e a entrega ainda assim errada; a única checagem para um canal de bed vazio é olhar as amostras.

12. Checklist de entrega

Faça na ordem. As checagens estruturais vêm primeiro porque são rápidas e invalidam tudo que vem depois.

Contêiner

1. Os quatro primeiros bytes são BW64. Se forem RIFF, é WAV comum e não passa de 4 GiB.
2. ds64 é o primeiro chunk após a assinatura, e seus tamanhos de 64 bits batem com o arquivo e com o data em disco.
3. Todo chunk não-data grande demais tem entrada ChunkSize64 na tabela do ds64.
4. Localize o axml explicitamente, inclusive depois do data. Não conclua "sem ADM" a partir de uma varredura parcial.

Essência

1. Taxa de amostragem e profundidade de bits do fmt batem exatamente com a especificação. Nenhuma conversão depois da autoria do ADM.
2. fmt.nChannels = chna.numTracks.
3. Todo trackIndex do chna está no intervalo e é base 1.

Integridade do chna

1. Toda entrada tem exatamente 40 bytes, com campos de largura fixa corretamente preenchidos.
2. Todo packRef em 0x1000 ou acima resolve para definição customizada presente no axml.
3. trackIndex repetidos são intencionais (faixa que legitimamente muda de definição), não duplicação.

Grafo ADM

1. Todo audioContentIDRef, audioObjectIDRef, audioPackFormatIDRef, audioChannelFormatIDRef e audioTrackUIDRef resolve. Zero arestas penduradas.
2. Nenhum audioTrackUID órfão, nos dois sentidos.
3. Nada circular nem auto-referente.
4. O typeLabel de cada audioChannelFormat bate com o do audioPackFormat pai.

Tempo

1. Formatos de canal com múltiplos blocos trazem rtime e duration em todos os blocos.
2. Blocos contíguos e monotônicos; durações somam a duração do audioObject pai.
3. Objetos começam em 00:00:00.00000.

Conteúdo

1. Todo canal de bed declarado contém o que deveria; investigue silêncio digital.
2. Contagem de objetos e configuração de bed conferem com a especificação.
3. Timecode de início no bext correto e consistente em todas as entregas do conjunto.

Renders e conforms

1. Conforms estéreo e binaural re-renderizados a partir do master atual, nunca carregados de versão anterior.
2. Durações e timecodes batendo amostra a amostra com o master.
3. Loudness medido num render nomeado, para um layout nomeado, com um renderizador nomeado — e os três registrados nas notas de entrega.

Reprodutibilidade

1. Checksum de cada entrega, com manifesto guardado.
2. Arquive a sessão e o XML do ADM separadamente do BW64. Um XML que você consegue diferenciar linha a linha vale mais, daqui a dois anos, do que um binário que você só consegue reprocessar.

Uma entrega imersiva não está pronta quando soa bem; está pronta quando uma máquina que nunca a ouviu consegue provar que as referências resolvem.

13. Fechamento

BW64 e ADM são padrões abertos, publicados e de leitura livre — o que é incomum neste canto da indústria e vale aproveitar. Você pode ler a BS.2088 e a BS.2076 por conta própria, escrever quarenta linhas de código que percorrem um chna, e verificar o que o exportador de um fabricante de fato escreveu, em vez do que a caixa de diálogo dele afirmou. Para quem grava bateria de escola de samba, roda de samba ou roda de capoeira no Brasil, isso é especialmente importante: a parte cara — a sala — talvez você não tenha, mas a parte que reprova a entrega é justamente a parte que você consegue conferir sozinho, com um parser e uma tarde.

A distribuição da Mazufa é gratuita — sem taxa de upload, sem assinatura, sem cobrança por lançamento —, a única dedução é 5% dos royalties recebidos, e toda candidatura completa passa por revisão humana.

Fontes

Recomendações 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.2076-2 (10/2019), Audio definition model — https://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.2076-2-201910-S!!TOC-HTM-E.htm
• 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
• Página da Recomendação BS.2127 — https://www.itu.int/rec/R-REC-BS.2127

Documentos técnicos da EBU

• EBU Tech 3306, RF64: An extended file format for audio data — https://tech.ebu.ch/docs/tech/tech3306.pdf
• EBU Tech 3285 (e suplementos), 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/docs/tech/tech3388.pdf
• EBU Tech 3343, Practical guidelines for production and implementation in accordance with EBU R 128 — https://tech.ebu.ch/files/live/sites/tech/files/shared/tech/tech3343v2_0.pdf
• EBU R 128, EBU Tech 3341 (medidores) e EBU Tech 3342 (Loudness Range) — https://tech.ebu.ch
• EBU ADM Guidelines — chunk chna — https://adm.ebu.io/reference/excursions/chna_chunk.html
• EBU ADM Guidelines — BW64 e 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
• Documentação do EBU ADM Renderer (EAR), E/S BW64 — https://ear.readthedocs.io/en/latest/BW64.html
• Implementação de referência libbw64 — https://github.com/ebu/libbw64
• Implementação de referência libadm — https://github.com/ebu/libadm

AES

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

Documentação de serviço

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

Última revisão: setembro de 2026. Recomendações são revisadas; confira sempre as páginas da ITU e da EBU acima para a edição vigente antes de citar um número de cláusula.