Por que uma masterização imersiva passa num editor de forma de onda e reprova no QC

Uma entrega imersiva pode abrir num editor de forma de onda, mostrar doze ou dezesseis faixas de aparência saudável, tocar de forma sensata e ainda assim ser recusada. O motivo é estrutural: num arquivo BW64 o áudio e os metadados são duas coisas separadas que precisam concordar exatamente, e nada no formato obriga isso. Um renderizador resolve referências. Um editor desenha amostras. Trabalhos diferentes — e é por isso que QC de ADM é verificação de integridade referencial, não escuta. Aqui está o que os dois padrões dizem, onde as referências se quebram e qual verificação pega qual falha.

Três tipos de áudio, e por que a distinção decide tudo

Todo problema de entrega imersiva começa com confusão sobre qual das três coisas uma faixa é.

Áudio baseado em canais atribui cada faixa a uma posição fixa de alto-falante. Estéreo é baseado em canais, 5.1 também, e um bed 7.1.4 também. A posição está embutida na identidade do canal: a faixa 3 é o alto-falante central, e é o alto-falante central em todo sistema que a reproduza. A ITU-R BS.2051 formaliza isso para sistemas de som avançados, descrevendo layouts como contagens de camadas Upper + Middle + Bottom — o System A é 0+2+0 (estéreo), o System B é 0+5+0 (5.1), o System D é 4+5+0, o System J é 4+7+0, o System H é 9+10+3, a configuração 22.2. No ADM isso é a typeDefinition DirectSpeakers, typeLabel 0001.

Áudio baseado em objetos carrega um sinal mono (ou um pack multicanal) mais metadados posicionais que mudam ao longo do tempo. O renderizador decide quais alto-falantes reais o reproduzem, com base no layout presente na sala. Nada na faixa pressupõe um alto-falante. Isso é a typeDefinition Objects, typeLabel 0003.

Áudio baseado em cena, na prática Ambisonics de ordem superior, codifica todo o campo sonoro como componentes de harmônicos esféricos. Nenhum componente corresponde a uma direção por si só; a direção emerge da combinação linear. Isso é HOA, typeLabel 0004. O ADM também define Matrix (0002) para sinais matriciados como Mid-Side ou Lt/Rt, e Binaural (0005).

A distinção não é taxonomia. Uma entrega baseada em canais se autodescreve o bastante para sobreviver como um WAV pelado — acerte a ordem dos canais e ela toca. Uma entrega baseada em objetos ou em cena não significa nada sem os seus metadados: o áudio é um monte de fluxos mono indiferenciados, e o ADM é a única coisa que diz o contrário. Essa assimetria é a razão de existirem o BW64 e o ADM.

O BW64 existe por causa de um número de 32 bits

O WAV clássico é um arquivo RIFF. O 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 GB — e esse é o teto rígido tanto do arquivo inteiro quanto do chunk data dentro dele.

Para estéreo a 48 kHz / 24 bits, a taxa de dados é de 288,000 bytes por segundo, então 4 GB dão cerca de 4 horas e 8 minutos. Irrelevante. Para uma masterização baseada em objetos com 128 faixas a 96 kHz / 24 bits, a taxa é de 36,864,000 bytes por segundo, e 4 GB dão menos de dois minutos — 116.5 segundos.

Masterizações imersivas ultrapassam esse limite rotineiramente, e um gravador de WAV que o atinge produz ou um arquivo truncado ou um cujos tamanhos declarados deram a volta silenciosamente. A EBU tratou disso primeiro com o RF64 (EBU Tech 3306); a ITU levou adiante como Recomendação ITU-R BS.2088 — o BW64.

O truque da sentinela: 0xFFFFFFFF e um chunk ds64

A BS.2088 é explícita sobre o mecanismo. "The ID 'BW64' is used instead of 'RIFF' in the first four bytes of the file", e os campos originais de tamanho de 32 bits viram sinalizadores de escape: "If the 32-bit value in the field is 0xFFFFFFFF the 64-bit value in the 'ds64' chunk is used instead."

É esse o truque inteiro, e vale dizê-lo com todas as letras: 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. Ou seja, um arquivo BW64 com menos de 4 GB é compatível byte a byte com um leitor de WAV em todos os aspectos, exceto pela assinatura de quatro caracteres. Muitas ferramentas o aceitam; algumas teimosamente não.

Os chunks, e aquele que tem exatamente 40 bytes por entrada

Pela BS.2088, espera-se que um arquivo BW64 contenha ao menos ds64, fmt , chna, axml (com bxml e sxml como portadores alternativos de metadados) e os dados de áudio.

ds64 precisa ser o primeiro chunk depois da assinatura, porque um leitor tem de saber os tamanhos reais antes de conseguir percorrer qualquer outra coisa. Ele carrega as metades baixa/alta de 32 bits do tamanho do arquivo inteiro e do tamanho do data, mais uma tabela de entradas ChunkSize64 para qualquer outro chunk superdimensionado — um chunk axml descrevendo milhares de objetos com automação precisa por amostra pode ele próprio se aproximar de 4 GB ou passar disso.

fmt é o chunk de formato WAVE padrão — formato de amostra, taxa de amostragem, contagem de canais, bits por amostra, alinhamento de bloco. É a única declaração autoritativa de quantos canais intercalados existem em data. Tudo daí para a frente é metadado sobre esses canais, e metadado pode mentir.

chna é a ponte entre as faixas físicas e o ADM. Depois de ckID, ckSize, um numTracks de 2 bytes e um numUIDs de 2 bytes, ele guarda um array plano de entradas audioID de largura fixa, cada uma com exatamente 40 bytes:

2 + 12 + 14 + 11 + 1 = 40. As larguras não são sugestões: são ASCII de largura fixa, e um gravador que emite um UID de 13 caracteres produziu uma tabela corrompida, não uma tabela levemente incomum.

A convenção de IDs também importa. Valores de 0x0FFF para baixo se referem às definições comuns do ADM — os formatos de canal e de pack padrão, predefinidos — enquanto 0x1000 para cima indica definições personalizadas que precisam estar presentes no axml. AP_00010003 é 5.1 por definição comum e não precisa de XML; AP_00031001 é um pack de objetos personalizado e precisa de XML, ou fica pendurado no vazio.

numUIDs também pode legitimamente exceder numTracks: a orientação da EBU observa que, onde "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", então um mesmo trackIndex pode aparecer em várias entradas. Ferramentas de QC que presumem um UID por faixa marcam arquivos corretos como quebrados.

axml é um documento XML em UTF-8 contendo a árvore <audioFormatExtended>. É esse o ADM, e é ali que mora praticamente toda falha interessante. data é PCM intercalado puro; nada dentro dele sabe qualquer coisa sobre objetos.

Ordenação: ds64 primeiro, sempre; fmt antes de data. Mas o axml pode legitimamente ficar depois do data, e muitas vezes fica, porque — como a BS.2088 observa — durante a gravação "the XML metadata will likely be of an unknown length." 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. Isso explica uma parcela surpreendente dos relatos de "meu arquivo não tem metadados".

O ADM é um grafo, e as falhas são arestas quebradas

A hierarquia da ITU-R BS.2076 vai de audioProgramme → audioContent → audioObject → audioPackFormat → audioChannelFormat → audioBlockFormat, com audioTrackUID como folha e como o único elemento que corresponde a uma faixa física.

Isso é um grafo de referências, não um documento aninhado, e toda falha séria de entrega é uma aresta quebrada nele. O que torna uma referência pendurada perigosa é que não existe um comportamento único quando uma delas se quebra. Um renderizador resolvendo um audioPackFormatIDRef que nomeia um pack ausente do XML pode abortar a análise e recusar o arquivo; pode pular aquele objeto e renderizar todo o resto, produzindo uma mixagem silenciosamente sem um stem; ou pode recorrer às definições comuns, encontrar um ID na faixa personalizada de 0x1000 para cima sem correspondência e substituí-lo por silêncio. Os três desfechos são "o arquivo abriu". Só um é pego pela escuta, e só se você souber o que deveria estar ali.

As quatro falhas que respondem pela maioria das recusas

Uma contagem de faixas em fmt que discorda do chna. fmt .nChannels diz 16; chna.numTracks diz 14. O arquivo é internamente inconsistente já a partir dos dois primeiros chunks — em geral um bounce que mudou a contagem de faixas depois que os metadados foram criados, ou uma ferramenta que descartou faixas sem reescrever o chna. A detecção é analisar dois inteiros e compará-los: a verificação mais barata da esteira, e ela pega uma proporção assustadora das falhas. Verifique ao mesmo tempo que todo trackIndex está dentro de 1 … fmt .nChannels.

Um audioTrackUID que nenhum objeto referencia. Um UID no chna que nenhum audioObject referencia significa que existe áudio que nada vai renderizar; o caso espelhado, um audioTrackUIDRef no XML sem entrada correspondente no chna, significa que os metadados esperam uma faixa que não está ali. Monte o conjunto de UIDs a partir do chna e o conjunto a partir do axml e tire a diferença simétrica; ela deve ser vazia. A EBU Tech 3392 declara a intenção diretamente: "If the audioObject refers to an audioPackFormat it should also refer to the corresponding audioTrackUIDs."

Temporização de blocos que corre para trás. A BS.2076 é inequívoca: "When there is more than one audioBlockFormat within an audioChannelFormat … both rtime and duration shall be present." A EBU Tech 3392 aperta isso para contiguidade — "rtime + duration of an audioBlockFormat should match the rtime of the following block" — com o primeiro bloco de um objeto começando em 00:00:00.00000, nenhum bloco mais curto que uma amostra, e durações somando o audioObject pai. Percorra os blocos na ordem do documento e assegure rtime[n] + duration[n] == rtime[n+1]. As falhas vêm em três formatos: lacunas, em que o comportamento do renderizador é indefinido e alguns seguram a última posição enquanto outros silenciam; sobreposições, em que os blocos brigam; e blocos fora de ordem cronológica, que é automação pulando para trás no meio do programa.

Um bed descrito no XML que nunca foi gravado em disco. O XML declara um pack DirectSpeakers 7.1.4 — doze canais — mas só o subconjunto 5.1 foi gravado, ou os canais de altura estavam mutados no bounce e saíram como preto digital. O grafo de referências está intacto; o áudio não. Verificações estruturais não pegam isso: você precisa de análise de essência, medindo se todo canal reivindicado por um pack DirectSpeakers contém algum sinal. Preto digital num canal de bed declarado não é automaticamente um erro — uma mixagem legítima pode deixar um canal traseiro superior vazio — mas sempre merece uma decisão humana.

O que é publicado sobre loudness imersivo, e o que não é

Um número não sobrevive à saída do estéreo, e vale dizer por quê.

A BS.1770-5 (novembro de 2023) é a edição atual; a BS.1770-4 está superada, ainda que a maioria dos medidores em uso continue citando-a. O seu algoritmo central pondera L, R e C em 1.0 e Ls e Rs em 1.41 (cerca de +1.5 dB), exclui o LFE e tem escopo "from one to five channels". A BS.1770-5 vai além disso nos anexos, cobrindo os sistemas de som avançados da BS.2051 e o áudio baseado em objetos — que precisa ser renderizado antes de poder ser medido. O loudness imersivo, portanto, não é uma propriedade do arquivo, mas de uma renderização, e mudar o layout de destino muda o número. Meça uma renderização conforme a BS.2127 para um layout nomeado da BS.2051 com um medidor BS.1770-5 e registre os três nas suas notas de entrega; a BS.2127 define o renderizador ADM de referência, e sua irmã de código aberto, o EBU ADM Renderer (EBU Tech 3388), é a forma prática de obter um valor reproduzível.

Nenhum serviço de streaming de música publica um alvo de loudness integrado para entrega imersiva. Circulam valores em fóruns e em material de treinamento de fornecedores; nenhum deles é uma especificação publicada, e este artigo não vai repetir nenhum como se fosse. O que é publicado se refere a estéreo baseado em canais — o alvo integrado do Spotify de −14 LUFS com um teto de true peak de −1 dBTP, apertando para −2 dBTP acima de −14 LUFS, e os −16 LUFS da AES TD1008 para música (o valor de −18 LUFS dela se aplica a conteúdo conduzido por fala, e afirmar −18 como o alvo para música é um erro frequente e grave).

O Dolby Atmos é uma tecnologia proprietária e licenciada da Dolby Laboratories, e o Sony 360 Reality Audio é um sistema proprietário construído sobre MPEG-H. Seus requisitos são definidos pelos donos, mudam sem referência aos calendários da ITU ou da EBU, e não são declarados aqui; nenhuma afiliação ou endosso é alegado. Leia a documentação atual do próprio licenciador.

O que conferir antes de enviar

Verificações estruturais primeiro; elas são rápidas e invalidam tudo que vem depois.

• Os quatro primeiros bytes são BW64. Se lerem RIFF, é um WAV simples e não pode passar de 4 GB.
• O ds64 é o primeiro chunk depois da assinatura, seus tamanhos de 64 bits batem com os tamanhos do arquivo e do data em disco, e todo chunk superdimensionado que não seja data tem uma entrada ChunkSize64 na tabela.
• Localize o axml explicitamente, inclusive depois do data — nunca conclua "sem ADM" a partir de uma varredura parcial.
• A taxa de amostragem e a profundidade de bits do fmt batem exatamente com a especificação de entrega. Nenhuma conversão de taxa de amostragem depois da criação do ADM — isso invalida todo rtime e duration expressos em amostras.
• fmt .nChannels é igual a chna.numTracks; todo trackIndex está dentro da faixa e tem base 1.
• Toda entrada de chna tem exatamente 40 bytes com campos de largura fixa corretamente preenchidos, e todo packRef em 0x1000 ou acima resolve para uma definição personalizada presente no axml.
• Todo audioContentIDRef, audioObjectIDRef, audioPackFormatIDRef, audioChannelFormatIDRef e audioTrackUIDRef resolve. Zero arestas penduradas, nos dois sentidos, sem referências circulares.
• Formatos de canal com múltiplos blocos carregam rtime e duration em todos os blocos; os blocos são contíguos e monotônicos; os objetos começam em 00:00:00.00000.
• Todo canal de um bed declarado contém o que deveria. Investigue preto digital.
• O timecode inicial do bext é consistente em todo o conjunto, e os conforms estéreo e binaural são rerrenderizados a partir da masterização atual. Um conform 40 ms adiantado em relação ao seu pai imersivo passa numa verificação de presença de arquivo e reprova numa escuta sincronizada.
• Faça checksum de toda entrega, guarde o manifesto e arquive o XML do ADM separado do BW64 — um XML que você pode comparar com diff vale mais depois do que um binário que você só pode reanalisar.

O BW64 e o ADM são padrões abertos, publicados e de leitura livre, e vale usar isso: você pode ler a BS.2088 e a BS.2076 por conta própria, analisar um chunk chna com quarenta linhas de código e verificar o que o exportador de um fornecedor de fato escreveu, em vez do que a caixa de diálogo dele alegou. Quase todas as recusas imersivas desnecessárias são erros de integridade referencial que um validador pega em menos de um segundo.

O inspetor gratuito de BW64/ADM da Mazufa, em mazufa.com/immersive-master-check, analisa o contêiner e os metadados inteiramente no seu próprio dispositivo e não envia nada, o que o torna utilizável em material que contratualmente não pode sair do prédio. A própria Mazufa é gratuita para lançar, cobra 0% de comissão e é por convite, com análise humana de toda inscrição completa.

Fontes

Recomendações da 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

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/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
• Implementação de referência libbw64 — 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/

Documentação de serviço

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