BW64 y ADM: referencia técnica para entregar audio inmersivo — del tablao al mariachi

Referencia de trabajo para ingenieros que preparan masters basados en objetos y en escena, y para músicos a quienes les han pedido «un entregable inmersivo» sin explicarles qué es lo que reprueba el control de calidad.

Respuesta corta

El Audio Definition Model (ADM) es un modelo de metadatos abierto, la Recomendación UIT-R BS.2076, que describe qué es cada pista de un archivo de audio: un canal de altavoz, un objeto que se mueve, o una componente ambisónica. Ese modelo viaja como XML dentro de un contenedor BW64, la Recomendación UIT-R BS.2088, que es una extensión de 64 bits de RIFF/WAVE y existe precisamente para superar el techo de 4 GB del WAV clásico. Una entrega inmersiva falla el QC porque el audio y los metadatos son dos cosas separadas que deben coincidir exactamente, y nada en el formato obliga a que coincidan: un recuento de canales en fmt que no cuadra con la tabla chna, un audioTrackUID al que no apunta ningún objeto, bloques cuya línea de tiempo retrocede, un bed declarado en el XML que nunca se imprimió en disco. Ninguno de esos errores se oye. El QC de ADM es verificación de integridad referencial, no una escucha.

1. El tablao: el caso de audio basado en objetos más nítido que existe en español

Antes del contenedor, la música. Casi todos los problemas de entrega inmersiva empiezan por una confusión sobre qué es realmente una pista, y el flamenco de tablao resuelve esa confusión mejor que ningún diagrama.

Un tablao es una sala pequeña. El cantaor, el tocaor, dos o tres palmeros y el bailaor están a pocos metros unos de otros y a pocos metros del público. No hay foso, no hay distancia, no hay difusión de sala que suavice nada. La geometría no es un adorno del sonido: es el sonido.

Y esa geometría no es simétrica ni estable. El tocaor suele estar sentado a un lado, ligeramente detrás del plano del cante. Los palmeros están a los lados del cantaor, y su posición importa de forma estructural: las palmas sordas y las palmas claras no son un relleno rítmico, son la referencia de compás sobre la que todo el mundo se apoya, y llegan desde puntos distintos del escenario. Si se colapsan al centro, el compás pierde el ancla espacial que tiene en la sala; el público de un tablao no oye «palmas», oye estas palmas desde ahí.

1.1 El bailaor es un objeto que varía en el tiempo, en el sentido literal del ADM

El bailaor es el caso de manual. No está en un sitio: recorre el suelo del tablao. Un zapateado por soleá no llega del mismo punto en dos compases seguidos, y no es solo que el intérprete se desplace, es que la propia madera del tablao radía distinto según dónde se golpee. En términos de ADM, eso es exactamente un audioObject con muchos audioBlockFormat: una secuencia de bloques, cada uno con su posición (azimuth, elevation, distance, o cartesiana X/Y/Z), su ganancia, su tamaño, su difusividad, y sus atributos rtime y duration.

Un objeto estático es un solo bloque. El bailaor no es un objeto estático. Y ahí aparece la primera trampa: la contigüidad temporal de esos bloques es una condición formal, no una recomendación estética. Si el rtime del bloque siguiente no coincide con rtime + duration del anterior, hay un hueco, y el comportamiento del renderizador en un hueco no está definido: unos mantienen la última posición, otros silencian. En un zapateado, un hueco de 200 ms puede significar que tres golpes salen del sitio equivocado, o que no salen.

1.2 Qué es objeto y qué no, en un tablao

Un reparto razonable de una captación de tablao:

• cantaor — objeto. Se mueve poco, pero se gira, y su directividad respecto al público cambia dentro de una misma letra.
• tocaor — objeto estático o casi. Una posición fija con una anchura (width) pequeña.
• palmeros — objetos discretos, uno por palmero. Es tentador tratarlos como un par estéreo; el par estéreo destruye justo la información que hace que el compás se sostenga.
• bailaor — objeto con automatización densa. El caso de tiempo variable.
• cajón, cuando lo hay — objeto, con posición propia; suele estar detrás del plano del cante.
• jaleo del público y respuesta de la sala — esto no es objeto. Es campo, y le corresponde un bed o una codificación en escena.

El criterio no es «¿suena importante?», sino «¿tiene esto una posición que el oyente debe poder localizar, y esa posición cambia?». Si la respuesta es sí, es objeto. Si describe el espacio en lugar de habitarlo, es bed.

2. El mariachi: cuando la geometría ya está ensayada, es una escena, no un conjunto de objetos

El contraejemplo está a la misma distancia cultural y en la dirección opuesta.

Un mariachi tiene una formación. Los violines van en una hilera al frente, las trompetas detrás y ligeramente elevadas por encima del plano de los violines, y el guitarrón y la vihuela al centro, sosteniendo el armazón armónico y rítmico. Esa disposición no es una casualidad de una noche: es una convención ensayada, estable de una agrupación a otra, y el balance interno del grupo está calculado para esa disposición. Las trompetas están detrás porque proyectan más; el guitarrón está al centro porque es el ancla.

Eso no es una colección de objetos móviles. Es una escena fija, y la respuesta técnica correcta es un bed basado en canales: cada pista asignada a una posición de altavoz definida, con la posición horneada en la identidad del canal. En ADM, eso es la typeDefinition DirectSpeakers, typeLabel 0001.

Tratar un mariachi como doce objetos es un error caro de dos maneras. Primero, se paga automatización, tamaño de XML y superficie de fallo por una información que nunca cambia. Segundo, y peor: se le entrega al renderizador la libertad de recolocar el grupo según el layout de la sala, con lo que el balance ensayado entre trompeta y violín —que depende de la relación geométrica concreta— puede reordenarse de una forma que ningún mariachi tocaría.

La regla práctica que se deriva:

Lo que ensaya su propia geometría se entrega como bed. Lo que la geometría del intérprete decide en cada función se entrega como objeto.

Un ejemplo mixto muy común: un mariachi con cantante solista al frente. El grupo va en bed; el solista, que sí se desplaza y se gira, va como objeto. Un audioObject puede referenciar un audioPackFormat completo (el bed) o pistas sueltas, y una entrega sana normalmente contiene ambas cosas.

3. Plaza abierta y procesión: los dos casos que rompen la intuición de estudio

Hay dos situaciones muy frecuentes en el mundo hispanohablante que no encajan ni en el tablao ni en el mariachi.

El conjunto andino en plaza abierta. Sikus y zampoñas, quenas, charango, bombo. La plaza no tiene techo, no tiene paredes cercanas y no tiene una reverberación que se pueda describir como «cola»: tiene reflexiones tardías de fachadas a distinta distancia y un fondo ambiental muy vivo. Aquí el error típico es el opuesto al del tablao: sobreobjetivar. En una plaza, el campo es la mitad del contenido, y a menudo lo correcto es una captación en escena (Ambisónica de orden alto, typeDefinition HOA, typeLabel 0004) para el entorno más un puñado corto de objetos para los solistas, en lugar de veinte objetos y ningún campo.

Un detalle específico de las zampoñas y sikus: en la interpretación tradicional en ira y arca, la melodía se reparte entre dos ejecutantes que se alternan nota a nota. Eso es un caso donde dos objetos separados con posiciones reales sí valen la pena, porque la línea melódica físicamente rebota entre dos puntos del espacio. Colapsarlos a un solo objeto reproduce las notas y borra el fenómeno.

Las tradiciones de procesión. Una banda de cornetas y tambores que avanza por una calle estrecha, una agrupación que atraviesa a la multitud, una saeta que cae desde un balcón sobre una calle llena: la fuente se mueve a través del público, no delante de él. Esto es objeto en el sentido más puro, con dos exigencias añadidas.

Primero, la trayectoria puede pasar por detrás del oyente y por encima de él, de modo que la posición debe expresarse con elevation y con distance reales, no con un panorama frontal disfrazado. Segundo, la envolvente de distancia cambia mucho: una banda que se acerca durante noventa segundos y se aleja durante otros noventa recorre un margen dinámico que ninguna automatización de ganancia estática representa. La combinación de distance con gain en bloques sucesivos es lo que lo describe; el error habitual es automatizar solo la ganancia y dejar la distancia congelada, con lo que el renderizador aplica un tratamiento de proximidad constante a una fuente que en realidad se aleja.

4. Los tres tipos de audio, formalizados

Recapitulando lo anterior en los términos de la Recomendación:

Basado en canales. Cada pista pertenece a una posición de altavoz fija. El estéreo es basado en canales; el 5.1 también; y también lo es un bed 7.1.4. La UIT-R BS.2051 formaliza esto para los sistemas de sonido avanzados, definiendo los layouts como recuentos de capas Superior + Medio + Inferior: el Sistema A es 0+2+0 (estéreo), el Sistema B es 0+5+0 (5.1), el Sistema D es 4+5+0, el Sistema J es 4+7+0, y el Sistema H es 9+10+3, la configuración 22.2. En ADM: DirectSpeakers, typeLabel 0001. El mariachi vive aquí.

Basado en objetos. Una señal mono (o un pack multicanal) más metadatos de posición que cambian con el tiempo. El renderizador decide qué altavoces reales lo reproducen, según el layout que haya de verdad en la sala. Nada en la pista presupone un altavoz. Objects, typeLabel 0003. El bailaor vive aquí.

Basado en escena. En la práctica, Ambisónica de orden alto: todo el campo sonoro codificado como componentes de armónicos esféricos. Ninguna componente corresponde por sí sola a una dirección; la dirección emerge de la combinación lineal. HOA, typeLabel 0004. La plaza vive aquí.

El ADM define además Matrix (0002) para señales matrizadas como Mid-Side o Lt/Rt, y Binaural (0005) para pares ya preparados para auriculares.

La asimetría importante es esta: un entregable basado en canales sobrevive como WAV pelado —con el orden de canales correcto, se reproduce—, mientras que un entregable basado en objetos o en escena no significa nada sin sus metadatos. El audio es un montón de flujos mono indiferenciados y el ADM es lo único que dice lo contrario. Esa asimetría es toda la razón de ser de BW64 y ADM, y toda la razón de que el QC inmersivo sea más difícil que el estéreo.

5. BW64: por qué existe el contenedor, con la aritmética hecha

El WAV clásico es un archivo RIFF. RIFF, de 1991, antepone a cada chunk un campo de tamaño de 32 bits. Treinta y dos bits direccionan 4 294 967 296 bytes —4 GiB— y ese es el techo duro tanto del archivo completo como del chunk data que va dentro.

Hagamos la cuenta con material real.

Estéreo, 48 kHz, 24 bits. El caudal es 2 canales × 3 bytes × 48 000 muestras/s = 288 000 bytes/s. El techo son 4 294 967 296 ÷ 288 000 ≈ 14 913 s, es decir 4 h 8 min 33 s. Irrelevante para cualquier canción.

Bed 7.1.4 (12 canales), 96 kHz, 24 bits. 12 × 3 × 96 000 = 3 456 000 bytes/s. Techo: 4 294 967 296 ÷ 3 456 000 ≈ 1 242,8 s, unos 20 min 43 s. Todavía cómodo para una canción, ya no para un directo entero.

Captación de tablao: 16 objetos + bed 7.1.4 = 28 pistas, 96 kHz, 24 bits. 28 × 3 × 96 000 = 8 064 000 bytes/s. Techo: 4 294 967 296 ÷ 8 064 000 ≈ 532,6 s, es decir 8 min 52 s. Una soleá larga, con salida, letras y macho, se pasa. Un archivo de nueve minutos con esa configuración pesa 9 × 60 × 8 064 000 = 4 354 560 000 bytes ≈ 4,06 GiB: por encima del techo, y no por poco margen simbólico sino de forma completamente rutinaria.

Sesión grande, 128 pistas, 96 kHz, 24 bits. 128 × 3 × 96 000 = 36 864 000 bytes/s. Techo: 116,5 s. Menos de dos minutos.

Un escritor de WAV que llegue a ese techo produce, o bien un archivo truncado, o bien un archivo cuyos tamaños declarados han desbordado en silencio. Ninguna de las dos cosas avisa.

La EBU abordó el problema primero con RF64 (EBU Tech 3306). La UIT retomó ese trabajo como la Recomendación UIT-R BS.2088, Long-form file format for the international exchange of audio programme materials with metadata —BW64—. La BS.2088 es explícita sobre el mecanismo: «The ID 'BW64' is used instead of 'RIFF' in the first four bytes of the file» («se usa el identificador 'BW64' en lugar de 'RIFF' en los primeros cuatro bytes del archivo»), y los campos originales de 32 bits pasan a funcionar como banderas de escape: «If the 32-bit value in the field is 0xFFFFFFFF the 64-bit value in the 'ds64' chunk is used instead» («si el valor de 32 bits del campo es 0xFFFFFFFF, se usa en su lugar el valor de 64 bits del chunk 'ds64'»).

Ese es todo el truco, y conviene decirlo sin rodeos:

BW64 no ensancha los campos de tamaño de RIFF: los rellena con 0xFFFFFFFF como centinela y guarda los tamaños reales de 64 bits en un chunk ds64 que debe ir el primero del archivo.

BW64 se entiende mejor como la tercera generación de un mismo linaje. RIFF/WAVE aportó el contenedor por chunks. Broadcast Wave (BWF, EBU Tech 3285) añadió el chunk bext —originador, referencia de código de tiempo, historial de codificación— convirtiendo el WAV en un formato de intercambio de radiodifusión. BW64 conserva todo eso, añade direccionamiento de 64 bits y añade los chunks que transportan el ADM. Un archivo BW64 por debajo de 4 GiB es compatible byte a byte con un lector de WAV en todo salvo en la firma de cuatro caracteres; muchas herramientas lo aceptan, y algunas se empeñan en no hacerlo.

6. El layout de chunks, en concreto

Según la BS.2088, se espera que un archivo BW64 contenga al menos <ds64-ck>, <fmt-ck>, <chna-ck>, <axml-ck> (con <bxml-ck> y <sxml-ck> como portadores alternativos de metadatos) y <wave-data>.

6.1 ds64 — la tabla de tamaños de 64 bits

Tiene que ser el primer chunk tras la firma BW64, porque un lector necesita conocer los tamaños reales antes de poder recorrer nada. Sus campos son mitades de 32 bits de cantidades de 64 bits:

Con tableLength a cero, el chunk ocupa 8 bytes de cabecera más 24 bytes de los tres pares de campos más 4 de tableLength: 36 bytes en total. Cada entrada de table[] añade su propio identificador de chunk y su tamaño de 64 bits.

La tabla importa más de lo que parece. Un chunk axml que describa un bailaor con automatización con precisión de muestra durante un espectáculo entero puede acercarse a 4 GiB o superarlo; la tabla es el mecanismo por el que cualquier chunk distinto de data declara un tamaño de 64 bits.

6.2 fmt — la descripción de la esencia

Chunk de formato WAVE estándar: formato de muestra, frecuencia de muestreo, número de canales, bits por muestra, alineación de bloque. Es la única declaración autorizada de cuántos canales entrelazados hay realmente en data. Todo lo demás son metadatos sobre esos canales, y los metadatos pueden mentir.

6.3 chna — la tabla de asignación de canales y la aritmética de los 40 bytes

El chna es el puente entre las pistas físicas y el ADM. Empieza con:

• ckID — 4 bytes, 'chna'
• ckSize — 4 bytes
• numTracks — 2 bytes, número de pistas del archivo
• numUIDs — 2 bytes, número de entradas audioTrackUID que siguen

Y a continuación un array plano de entradas audioID de ancho fijo. Cada entrada ocupa exactamente 40 bytes:

2 + 12 + 14 + 11 + 1 = 40. Las anchuras no son orientativas: son ASCII de ancho fijo. Un escritor que emita un UID de trece caracteres no ha producido una tabla ligeramente inusual, ha producido una tabla corrupta.

Comprobación de tamaño que se puede hacer a mano. Para la captación de tablao de 28 pistas con una definición por pista, el chna tiene 28 entradas: la carga útil es 2 (numTracks) + 2 (numUIDs) + 40 × 28 = 1 124 bytes, y el chunk completo con su cabecera de 8 bytes ocupa 1 132 bytes. Si ckSize no vale 1 124, o el chunk no mide 1 132 bytes en disco, el archivo está mal escrito y no hace falta abrir el XML para saberlo. Generalizando: ckSize = 4 + 40 × numUIDs, siempre.

Conviene fijarse también en la convención de identificadores: los valores hasta 0x0FFF remiten a las definiciones comunes del ADM —los formatos de canal y de pack predefinidos—, mientras que 0x1000 en adelante indica definiciones personalizadas que deben estar presentes en el chunk axml. Un packRef con valor AP_00010003 es un 5.1 por definición común y no necesita XML; AP_00031001 es un pack de objetos personalizado y, sin XML, queda colgando.

Un track UID es el número de serie que el archivo asigna a la identidad de una pista física, y existe justamente para que una pista pueda cambiar legítimamente de contenido a mitad de programa.

Ese último punto es la razón de que numUIDs pueda ser mayor que numTracks: la guía de la EBU señala que cuando «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» («los elementos de audio de una pista pueden definirse de manera distinta a lo largo de un archivo … habrá un UID diferente para cada definición»). Un mismo trackIndex puede aparecer, por tanto, en varias entradas. Es lo que ocurre de forma natural en una grabación de tablao con dos pases: el micrófono que en el primer pase sigue al bailaor puede, en el segundo, quedar asignado a un palmero distinto. Las herramientas de QC que dan por hecho un UID por pista reprueban archivos correctos.

6.4 axml — el ADM propiamente dicho

Un documento XML en UTF-8 con el árbol <audioFormatExtended>. Esto es el ADM. Es texto, es inspeccionable, y es donde vive prácticamente todo lo que falla de forma interesante.

6.5 data — el PCM entrelazado

Muestras entrelazadas, exactamente como en WAV. Nada dentro de data sabe nada de objetos.

6.6 El orden, y la trampa que atrapa a todo el mundo

ds64 primero, siempre. fmt antes que data. Pero axml puede ir legítimamente después de data, y a menudo va, porque —como observa la BS.2088— durante la grabación «the XML metadata will likely be of an unknown length» («los metadatos XML tendrán probablemente una longitud desconocida»). Un archivo con axml al final no está malformado; un lector que solo escanee el primer megabyte informará, sin embargo, de que no hay ADM en absoluto. Este único hecho explica una proporción sorprendente de los avisos de tipo «mi archivo no tiene metadatos».

7. El modelo ADM: un grafo de referencias

La UIT-R BS.2076 divide el modelo en dos mitades. La parte de formato «describes the technical nature of the audio so it can be decoded or rendered correctly» («describe la naturaleza técnica del audio para que pueda decodificarse o renderizarse correctamente») y puede escribirse antes de que exista ningún audio. La parte de contenido describe «the language of dialogue, the loudness, etc.» y solo puede completarse cuando ya hay señales. Saber a qué mitad pertenece un elemento indica en qué etapa de producción se introdujo un error dado.

La jerarquía, de arriba abajo:

• audioProgramme — una presentación completa entregable. Referencia uno o más audioContent.
• audioContent — un componente con sentido editorial: el stem de cante, el de guitarra, una versión de idioma. Referencia uno o más audioObject.
• audioObject — la juntura entre intención editorial y formato técnico. Lleva tiempo de inicio y duración, y referencia cero o más audioPackFormat, cero o más audioObject anidados y cero o más audioTrackUID. Aquí es donde el contenido se encuentra con la esencia.
• audioPackFormat — un grupo de canales que van juntos: el bed 7.1.4 del mariachi, un par estéreo, un conjunto HOA de un orden dado. Referencia elementos audioChannelFormat y puede anidar otros packs.
• audioChannelFormat — el comportamiento de un canal a lo largo del tiempo. Contiene uno o más audioBlockFormat.
• audioBlockFormat — el átomo. Para Objects: posición, ganancia, tamaño, difusividad, más rtime y duration. El tocaor es un bloque; el bailaor es una secuencia larga.
• audioTrackUID — la hoja, y el único elemento que corresponde a una pista física. Lleva atributos opcionales sampleRate y bitDepth y referencia un audioTrackFormat y un audioPackFormat.

audioStreamFormat y audioTrackFormat se sitúan entre el formato de canal y el UID de pista y describen la codificación del flujo. La BS.2076-3 indica que, para PCM, son redundantes en la práctica —«the audioStreamFormat and the audioTrackFormat should be omitted»— pero advierte de que los lectores «should be aware that existing ADM files (based on Recommendation ITU-R BS.2076-2 and earlier) for PCM audio may contain» esos elementos. Las dos formas son legales. Un validador que exija una está equivocado respecto a la otra.

El ADM es un grafo de referencias, no un documento anidado, y todo fallo serio de entrega es una arista rota de ese grafo.

Qué ocurre de verdad cuando una referencia queda colgando. No hay un único comportamiento, y ese es el problema. Un renderizador que resuelva un audioPackFormatIDRef apuntando a un pack ausente del XML puede abortar el análisis y rechazar el archivo; puede saltarse ese objeto y renderizar todo lo demás, produciendo una mezcla a la que le falta un stem sin decirlo; o puede recurrir a las definiciones comunes, encontrar un identificador del rango personalizado 0x1000+ sin correspondencia, y sustituirlo por silencio. Los tres desenlaces son «el archivo abrió». Solo uno se detecta escuchando, y solo si uno sabía de antemano qué debía haber ahí. Si el objeto que desaparece es el palmero de la derecha, la mezcla sigue teniendo compás y sigue sonando a flamenco. Por eso el QC de ADM tiene que ser automático: el oído no oye una ausencia que nadie le anunció.

8. Renderizado: la BS.2127 hacia los layouts de la BS.2051

Un archivo ADM basado en objetos no «suena» de una manera. Suena de tantas maneras como layouts de reproducción existan, porque el renderizador toma las posiciones y las convierte en ganancias de altavoz para el sistema que hay delante.

La UIT-R BS.2127 define el renderizador ADM de referencia para sistemas de sonido avanzados, y su hermano de código abierto, el EBU ADM Renderer (EBU Tech 3388), es la vía práctica para obtener un resultado reproducible. «Reproducible» es la palabra clave: dos renderizadores distintos con el mismo archivo y el mismo layout no tienen por qué coincidir muestra a muestra, y sin nombrar cuál se usó, un número medido no es verificable.

Esto cambia cómo hay que hablar de una entrega inmersiva. El mismo tablao renderizado al Sistema B (0+5+0) y al Sistema J (4+7+0) produce dos distribuciones de energía distintas: en el primero, todo lo que estaba por encima del plano del oyente se rebaja al plano; en el segundo, no. La procesión que pasa por encima y por detrás, en un 0+5+0, se aplana hasta convertirse en un desplazamiento horizontal. Ninguno de los dos renders «es el archivo»: los dos son renders.

Consecuencia operativa: al registrar cualquier medición o cualquier decisión de mezcla, nombre el layout y nombre el renderizador, no solo el número.

9. Loudness inmersivo bajo la BS.1770-5

Aquí es imprescindible separar lo que está publicado de lo que circula.

9.1 Qué especifica la Recomendación

La edición en vigor es la BS.1770-5, de noviembre de 2023. La BS.1770-4 (octubre de 2015) está superada, aunque siga siendo la edición que citan la mayoría de los medidores desplegados. Al documentar una medición, nombre la -5.

La BS.1770 define la ponderación K: un filtro de estantería alta («head» filter) que modela una esfera rígida, seguido de un paso alto RLB. La ganancia de la curva a 1 kHz es +0,698 dB (lineal 1,0836). La medición usa bloques de 400 ms con 75 % de solapamiento, una puerta absoluta que descarta los bloques por debajo de −70 LUFS, y una puerta relativa calculada a partir de la media de los bloques que sobrevivieron a la puerta absoluta, desplazada después −10 LU. Esa puerta relativa se calcula sobre los bloques supervivientes, no sobre la media sin puerta: es una distinción que las implementaciones equivocan con suficiente frecuencia como para importar.

La ponderación de canales en el algoritmo base es 1,0 (0 dB) para L, R y C, y 1,41 (≈ +1,5 dB) para Ls y Rs, con el LFE excluido. El algoritmo base está delimitado a «from one to five channels». La BS.1770-5 va más allá en sus anexos, cubriendo los sistemas de sonido avanzados de la BS.2051 —altavoces en posiciones arbitrarias y canales de altura— y el audio basado en objetos, que debe renderizarse antes de poder medirse.

El loudness inmersivo no es una propiedad del archivo: es una propiedad de un render, y cambiar el layout de destino cambia el número.

Esa es la diferencia sustantiva respecto al estéreo. Un master estéreo tiene un valor de loudness. Un master basado en objetos tiene tantos como destinos de render, y la forma honesta de dar una cifra es nombrar el layout sobre el que se midió y el renderizador que se usó.

Documentos EBU relacionados. La EBU Tech 3341 define los comportamientos de medidor (momentáneo 400 ms, corto plazo 3 s). La EBU Tech 3342 define el Loudness Range (LRA), que usa una puerta relativa de −20 LU, no de −10 LU; usar −10 para el LRA es un bug de implementación habitual. La EBU R 128 fija el objetivo de programa de radiodifusión en −23 LUFS: es una práctica de normalización de broadcast, no una especificación de streaming musical.

9.2 Qué sí está publicado para música

Para música estéreo basada en canales, Spotify publica un objetivo integrado de −14 LUFS y un techo de pico real de −1 dBTP, que se aprieta a −2 dBTP para masters más fuertes que −14 LUFS. La AES TD1008 recomienda −16 LUFS para música; su cifra de −18 LUFS se aplica a contenido dominado por voz hablada (informativos, tertulia, dramático), y dar −18 como objetivo musical es un error frecuente y grave.

Sobre el pico real: se mide sobre la señal sobremuestreada (mínimo 4× según la BS.1770; 8× es mejor). El pico de muestra no es el pico real, y los picos entre muestras pueden superar el valor de la muestra más alta.

Sobre la normalización ascendente, que se malinterpreta en las dos direcciones: Spotify indica que «Positive gain is applied to softer masters so the loudness level is -14 dB LUFS» y también que «We consider the headroom of the track, and leave 1 dB headroom for lossy encodings to preserve audio quality». Es decir: un master silencioso con picos altos puede no ser subido del todo. Ni «los masters silenciosos no se suben» ni «los masters silenciosos siempre se suben hasta el objetivo» son afirmaciones correctas.

9.3 Qué no está publicado

Ningún servicio de streaming musical publica un objetivo de loudness integrado para entrega inmersiva. Circulan cifras en foros y en material de formación de fabricantes; varias son plausibles y algunas probablemente sean correctas. Ninguna es una especificación publicada, y este documento no va a repetir una como si lo fuera.

En el mismo apartado: Apple Music, YouTube Music, Amazon Music, TIDAL y Deezer no publican objetivo de normalización tampoco para estéreo. Las cifras que se citan habitualmente para esos servicios (Apple ≈ −16, YouTube Music ≈ −14, Amazon ≈ −14, TIDAL ≈ −14, Deezer ≈ −15) son ampliamente difundidas pero no publicadas por el servicio, y no deben tratarse como una especificación de la que calcular un cambio de ganancia.

Radiodifusión y cine están mejor documentados que la música, sencillamente porque los radiodifusores publican. Si hoy necesita una cifra de loudness inmersivo defendible: mida un render conforme a la BS.2127 hacia un layout BS.2051 nombrado, con un medidor BS.1770-5, y consigne las tres cosas en sus notas de entrega.

9.4 Sobre sistemas propietarios

Dolby Atmos es una tecnología propietaria y licenciada de Dolby Laboratories, y Sony 360 Reality Audio es un sistema propietario construido sobre MPEG-H. Sus requisitos de entrega los fijan sus titulares y cambian sin atenerse a los calendarios de la UIT ni de la EBU. Nada en este documento constituye una declaración de los requisitos de esas empresas, y no se reclama ni se insinúa afiliación, certificación ni respaldo alguno. Donde un licenciante publique un requisito, lea la documentación vigente del propio licenciante y cite esa.

10. La posición honesta: casi nadie tiene monitoreo inmersivo

Conviene decirlo sin adornos. El monitoreo inmersivo es raro en los estudios de música en español, fuera de un puñado de instalaciones de postproducción en unas pocas ciudades. La mayoría de quien lea esto no tiene una sala calibrada con doce altavoces, y no la va a tener el mes que viene. Un tablao no tiene sala de control.

Eso no invalida el trabajo, pero sí redefine dónde está el valor. Si no puede auditar la entrega en condiciones, su ventaja no está en la mezcla: está en la corrección del entregable. Y resulta que la corrección del entregable es exactamente la parte que reprueba el QC, y exactamente la parte que sí se puede verificar sin sala.

Lo que se puede verificar sin monitoreo inmersivo:

• que la firma del archivo sea BW64 y no RIFF;
• que ds64 sea el primer chunk y que sus tamaños de 64 bits coincidan con lo que hay en disco;
• que fmt.nChannels sea igual a chna.numTracks;
• que cada entrada de chna mida exactamente 40 bytes y que ckSize valga 4 + 40 × numUIDs;
• que todas las referencias del grafo ADM resuelvan, en ambas direcciones;
• que los audioBlockFormat del bailaor sean contiguos y monótonos;
• que cada canal declarado del bed del mariachi contenga señal de verdad, y no negro digital;
• que la frecuencia de muestreo y la profundidad de bits sean las que pide la especificación.

Lo que no se puede verificar sin sala: si la altura suena bien, si el objeto del bailaor cruza de forma convincente, si el campo de la plaza tiene el tamaño adecuado. Esas son decisiones artísticas y necesitan escucha.

La conclusión práctica es cómoda: la parte cara —la sala— quizá no la tenga; la parte que hace que le devuelvan la entrega la puede comprobar usted mismo, con un parser y una tarde. Un inspector gratuito de BW64/ADM en mazufa.com analiza el contenedor y los metadatos íntegramente en su propio dispositivo y no sube nada, lo que lo hace utilizable sobre material que contractualmente no puede salir del edificio.

11. Fallos de QC más frecuentes, y cómo detectar cada uno

11.1 Desajuste de recuento de canales entre fmt y chna

fmt.nChannels dice 28; chna.numTracks dice 26. El archivo es internamente inconsistente desde los dos primeros chunks. Causa habitual: un bounce que cambió el número de pistas después de escribir los metadatos, o una herramienta que descartó pistas sin reescribir el chna.

Detección: analizar ambos chunks y comparar enteros. Es la comprobación más barata de todo el flujo y atrapa una proporción asombrosa de fallos. Verifique además que todo trackIndex del chna esté en el rango 1 … fmt.nChannels.

11.2 UIDs de pista huérfanos

Un UID presente en chna al que no apunta ningún audioObject, o un audioTrackUIDRef en el XML sin entrada correspondiente en chna. Lo primero significa que hay audio que nadie va a renderizar —el palmero que desaparece—; lo segundo, que los metadatos esperan una pista que no existe.

Detección: construir el conjunto de UIDs del chna y el del axml, y calcular la diferencia simétrica. Debe ser vacía. La EBU Tech 3392 lo explicita: «If the audioObject refers to an audioPackFormat it should also refer to the corresponding audioTrackUIDs».

11.3 Bloques con temporización ausente o no monótona

La BS.2076 no deja margen: «When there is more than one audioBlockFormat within an audioChannelFormat … both rtime and duration shall be present». La EBU Tech 3392 lo aprieta con una regla de contigüidad —«rtime + duration of an audioBlockFormat should match the rtime of the following block»— con el primer bloque de un objeto empezando en 00:00:00.00000, ningún bloque más corto que una muestra, y la suma de duraciones coincidiendo con la del audioObject padre.

Detección: para cada audioChannelFormat, recorrer los bloques en orden documental y comprobar que rtime[n] + duration[n] == rtime[n+1]. Los fallos se agrupan en tres formas: huecos (comportamiento del renderizador indefinido), solapamientos (bloques peleándose) y bloques fuera de orden cronológico (automatización que salta hacia atrás a mitad de programa). Un bailaor con automatización densa es donde esto aparece.

11.4 Frecuencia de muestreo o profundidad de bits incorrectas

audioTrackUID puede llevar atributos sampleRate y bitDepth. Cuando contradicen a fmt , hay dos afirmaciones sobre la misma esencia. La postura de la EBU Tech 3392 es que «Should be ignored if available from the audio essence», pero no todos los renderizadores siguen esa guía, y un archivo que dice 48 000 en un sitio y 96 000 en otro será interpretado de forma distinta por herramientas distintas. Aparte: confirme que la frecuencia es la que pide la especificación de entrega, porque una conversión de frecuencia aplicada después de escribir el ADM invalida todos los rtime y duration expresados en muestras.

Detección: comparar fmt con todos los atributos sampleRate/bitDepth del XML y señalar cualquier desacuerdo, aunque sea nominalmente tolerable.

11.5 Conformados estéreo o binaural ausentes, o desincronizados

Casi toda entrega inmersiva exige un conformado estéreo, y a menudo también binaural, junto al master inmersivo. El fallo recurrente no es la ausencia —la ausencia es obvia— sino la deriva: el conformado se renderizó desde una versión anterior, va unos cuadros desplazado, o tiene otro código de tiempo de inicio. Un estéreo 40 ms adelantado respecto a su padre inmersivo pasa una comprobación de presencia de archivo y falla una escucha sincronizada.

Detección: comparar duraciones muestra a muestra, comparar el código de tiempo de inicio del bext, y correlacionar el conformado contra un render nulo del master. Trate como sospechoso cualquier conformado que no sea derivable del master actual, y vuelva a renderizarlo en lugar de volver a comprobarlo.

11.6 Metadatos que describen un bed que no está en el archivo

El XML declara un pack DirectSpeakers 7.1.4 —doce canales— pero solo se imprimió el subconjunto 5.1, o los canales de altura se silenciaron en el bounce y se imprimieron como negro digital. El grafo de referencias está intacto; el audio no. En un mariachi capturado como bed, esto se traduce en un grupo que existe en el papel y está incompleto en el disco.

Detección: las comprobaciones estructurales no lo detectan. Hace falta análisis de esencia: para cada canal reclamado por un pack DirectSpeakers, medir si la pista contiene señal. El negro digital en un canal de bed declarado no es automáticamente un error —una mezcla legítima puede dejar vacío un canal superior trasero— pero siempre merece una decisión humana.

El contenedor puede ser perfectamente válido, el XML perfectamente bien formado, y el entregable seguir estando mal; la única comprobación para un canal de bed vacío es mirar las muestras.

12. Lista de comprobación de entrega

En este orden. Las comprobaciones estructurales primero: son rápidas e invalidan todo lo que viene después.

Contenedor

1. Los primeros cuatro bytes son BW64. Si son RIFF, es un WAV plano y no puede pasar de 4 GiB.
2. ds64 es el primer chunk tras la firma, y sus tamaños de 64 bits coinciden con el archivo y con data en disco.
3. Todo chunk sobredimensionado distinto de data tiene su entrada ChunkSize64 en la tabla de ds64.
4. Localice axml explícitamente, incluso después de data. No concluya «no hay ADM» a partir de un escaneo parcial.

Esencia

1. Frecuencia de muestreo y profundidad de bits de fmt coinciden exactamente con la especificación. Sin SRC posterior al ADM.
2. fmt.nChannels es igual a chna.numTracks.
3. Todo trackIndex del chna está en rango y con base 1.

Integridad de chna

1. Cada entrada mide exactamente 40 bytes, con campos de ancho fijo correctamente rellenados, y ckSize = 4 + 40 × numUIDs.
2. Todo packRef de 0x1000 en adelante resuelve a una definición personalizada presente en axml.
3. Los trackIndex repetidos son intencionados (una pista que cambia legítimamente de definición), no duplicados por error.

Grafo ADM

1. Todo audioContentIDRef, audioObjectIDRef, audioPackFormatIDRef, audioChannelFormatIDRef y audioTrackUIDRef resuelve. Cero aristas colgando.
2. Ningún audioTrackUID huérfano en ninguna de las dos direcciones.
3. Sin elementos circulares ni autorreferenciales.
4. El typeLabel de cada audioChannelFormat coincide con el de su audioPackFormat padre.

Temporización

1. Los formatos de canal con varios bloques llevan rtime y duration en todos los bloques.
2. Los bloques son contiguos y monótonos; las duraciones suman la duración del audioObject padre.
3. Los objetos empiezan en 00:00:00.00000.

Contenido

1. Cada canal de un bed declarado contiene lo que debe; investigue el negro digital.
2. El recuento de objetos y la configuración de bed coinciden con la especificación.
3. El código de tiempo de inicio del bext es correcto y consistente en todos los entregables del conjunto.

Renders y conformados

1. Los conformados estéreo y binaural se rerenderizan desde el master actual, no se arrastran.
2. Duraciones y códigos de tiempo de inicio coinciden con el master muestra a muestra.
3. El loudness se mide sobre un render nombrado, hacia un layout nombrado, con un renderizador nombrado, y las tres cosas quedan escritas en las notas de entrega.

Reproducibilidad

1. Calcule una suma de verificación de cada entregable y guarde el manifiesto.
2. Archive la sesión y el XML del ADM por separado del BW64. Un XML que se puede diferenciar con diff vale más a medio plazo que un binario que solo se puede volver a analizar.

Un entregable inmersivo no está terminado cuando suena bien; está terminado cuando una máquina que nunca lo ha oído puede demostrar que sus referencias resuelven.

13. Cierre

BW64 y ADM son estándares abiertos, publicados y de lectura libre. Eso es poco habitual en este rincón de la industria y conviene aprovecharlo: se puede leer la BS.2088 y la BS.2076 por cuenta propia, escribir cuarenta líneas de código que recorran un chna, y verificar qué escribió de verdad el exportador de un fabricante en lugar de lo que afirmó su cuadro de diálogo.

Para quien graba un tablao, un mariachi, un conjunto en una plaza o una procesión que atraviesa a la gente, la lección es la misma en los cuatro casos. Decida primero qué es objeto y qué es escena —el bailaor es objeto, la formación del mariachi es escena— y después compruebe que el archivo dice exactamente eso. Casi todos los rechazos innecesarios en audio inmersivo son errores de integridad referencial que un validador detecta en menos de un segundo.

La distribución de Mazufa es gratuita —sin coste de subida, sin suscripción y sin cargo por lanzamiento—, la única deducción es un 5 % de las regalías recibidas, y toda solicitud completa pasa por revisión humana.

Fuentes

Recomendaciones UIT-R

• UIT-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
• UIT-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
• UIT-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
• UIT-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
• UIT-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
• UIT-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 de la Recomendación BS.2127 — https://www.itu.int/rec/R-REC-BS.2127

Documentos técnicos de la EBU

• EBU Tech 3306, RF64: An extended file format for audio data — https://tech.ebu.ch/docs/tech/tech3306.pdf
• EBU Tech 3285 (y 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 y https://tech.ebu.ch/publications/tech3388
• 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), 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 y 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
• Documentación del EBU ADM Renderer (EAR), E/S BW64 — https://ear.readthedocs.io/en/latest/BW64.html
• Implementación de referencia libbw64 — https://github.com/ebu/libbw64
• Implementación de referencia 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/

Documentación de servicios

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

Última revisión: septiembre de 2026. Los estándares se revisan; compruebe siempre las páginas de la UIT y de la EBU antes de citar un número de cláusula.