Por qué un máster inmersivo pasa un editor de onda y falla el QC

Un entregable inmersivo puede abrirse en un editor de onda, mostrar doce o dieciséis pistas de aspecto saludable, reproducirse de forma razonable y aun así ser rechazado. La razón es estructural: en un archivo BW64 el audio y los metadatos son dos cosas distintas que deben coincidir exactamente, y nada en el formato los obliga a hacerlo. Un renderizador resuelve referencias. Un editor dibuja muestras. Trabajos distintos — y por eso el QC de ADM es una verificación de integridad referencial, no una escucha. Esto es lo que dicen las dos normas, dónde se rompen las referencias y qué comprobación detecta cada falla.

Tres clases de audio, y por qué la distinción lo decide todo

Todo problema de entrega inmersiva empieza con la confusión sobre cuál de tres cosas es una pista.

El audio basado en canales asigna cada pista a una posición fija de altavoz. El estéreo es basado en canales, el 5.1 también, y un lecho 7.1.4 también. La posición está incorporada en la identidad del canal: la pista 3 es el altavoz central, y es el altavoz central en todo sistema que la reproduzca. La ITU-R BS.2051 formaliza esto para los sistemas de sonido avanzados, describiendo las configuraciones como conteos de capas Upper + Middle + Bottom — el System A es 0+2+0 (estéreo), el System B es 0+5+0 (5.1), el System D es 4+5+0, el System J es 4+7+0, el System H es 9+10+3, la configuración 22.2. En ADM esto es el typeDefinition DirectSpeakers, typeLabel 0001.

El audio basado en objetos lleva 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 la configuración presente en la sala. Nada en la pista presupone un altavoz. Esto es el typeDefinition Objects, typeLabel 0003.

El audio basado en escena, en la práctica Higher-Order Ambisonics, codifica todo el campo sonoro como componentes de armónicos esféricos. Ningún componente corresponde por sí solo a una dirección; la dirección emerge de la combinación lineal. Esto es HOA, typeLabel 0004. ADM también define Matrix (0002) para señales matrizadas como Mid-Side o Lt/Rt, y Binaural (0005).

La distinción no es taxonomía. Un entregable basado en canales se autodescribe lo suficiente como para sobrevivir como un WAV pelado — acierta el orden de canales y suena. 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 otra cosa. Esa asimetría es la razón de ser de BW64 y de ADM.

BW64 existe por culpa de un número de 32 bits

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 GB — y ese es el techo duro tanto del archivo completo como del chunk data que contiene.

Para estéreo a 48 kHz / 24 bits el flujo de datos es de 288,000 bytes por segundo, así que 4 GB son unas 4 horas 8 minutos. Irrelevante. Para un máster basado en objetos de 128 pistas a 96 kHz / 24 bits el flujo es de 36,864,000 bytes por segundo, y 4 GB son menos de dos minutos — 116.5 segundos.

Los másteres inmersivos cruzan ese límite de forma rutinaria, y un escritor de WAV que lo alcanza produce o bien un archivo truncado o bien uno cuyos tamaños declarados se desbordaron en silencio. La EBU abordó esto primero con RF64 (EBU Tech 3306); la ITU lo retomó como la Recomendación ITU-R BS.2088 — BW64.

El truco del centinela: 0xFFFFFFFF y un chunk ds64

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", y los campos de tamaño originales de 32 bits pasan a ser banderas de escape: "If the 32-bit value in the field is 0xFFFFFFFF the 64-bit value in the 'ds64' chunk is used instead."

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 pone los tamaños reales de 64 bits en un chunk ds64 que debe ir primero en el archivo. De modo que un archivo BW64 de menos de 4 GB es compatible byte a byte con un lector de WAV en todos los aspectos salvo en la firma de cuatro caracteres. Muchas herramientas lo aceptan; otras se niegan con terquedad.

Los chunks, y el que mide exactamente 40 bytes por entrada

Según la BS.2088, se espera que un archivo BW64 contenga al menos ds64, fmt , chna, axml (con bxml y sxml como portadores alternativos de metadatos) y los datos de onda.

ds64 debe ser el primer chunk después de la firma, porque un lector tiene que conocer los tamaños reales antes de poder recorrer cualquier otra cosa. Lleva mitades baja/alta de 32 bits para el tamaño del archivo completo y para el tamaño de data, más una tabla de entradas ChunkSize64 para cualquier otro chunk sobredimensionado — un chunk axml que describa miles de objetos con automatización de precisión de muestra puede acercarse a los 4 GB o superarlos.

fmt es el 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 en data. Todo lo que viene después son metadatos sobre esos canales, y los metadatos pueden mentir.

chna es el puente entre las pistas físicas y el ADM. Después de ckID, ckSize, un numTracks de 2 bytes y un numUIDs de 2 bytes, contiene un arreglo plano de entradas audioID de ancho fijo, cada una de exactamente 40 bytes:

2 + 12 + 14 + 11 + 1 = 40. Los anchos no son orientativos: son ASCII de ancho fijo, y un escritor que emite un UID de 13 caracteres ha producido una tabla corrupta, no una levemente inusual.

La convención de los identificadores también importa. Los valores de 0x0FFF para abajo remiten a las definiciones comunes de ADM — los formatos de canal y de pack estándar, predefinidos — mientras que 0x1000 y superiores indican definiciones personalizadas que deben estar presentes en axml. AP_00010003 es 5.1 por definición común y no necesita XML; AP_00031001 es un pack de objetos personalizado y necesita XML, o queda colgando.

numUIDs también puede superar legítimamente a 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", de modo que un mismo trackIndex puede aparecer en varias entradas. Las herramientas de QC que suponen un UID por pista marcan como rotos archivos correctos.

axml es un documento XML en UTF-8 que contiene el árbol <audioFormatExtended>. Eso es el ADM, y ahí viven prácticamente todas las fallas interesantes. data es PCM entrelazado sin más; nada en él sabe nada de objetos.

Orden: ds64 primero, siempre; fmt antes que data. Pero axml puede ir legítimamente después de data, y a menudo lo hace, porque — como observa la BS.2088 — durante la grabación "the XML metadata will likely be of an unknown length." Un archivo con axml al final no está mal formado, pero un lector que solo escanea el primer megabyte informará que no hay ADM alguno. Eso explica una proporción sorprendente de los reportes de "mi archivo no tiene metadatos".

ADM es un grafo, y las fallas son aristas rotas

La jerarquía de la ITU-R BS.2076 va audioProgramme → audioContent → audioObject → audioPackFormat → audioChannelFormat → audioBlockFormat, con audioTrackUID como hoja y como único elemento que corresponde a una pista física.

Eso es un grafo de referencias, no un documento anidado, y toda falla seria de entrega es una arista rota en él. Lo que hace peligrosa a una referencia colgante es que no hay un único comportamiento cuando se rompe. Un renderizador que resuelve un audioPackFormatIDRef que nombra 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 avisar; o puede recurrir a las definiciones comunes, encontrar un identificador en el rango personalizado de 0x1000 para arriba sin coincidencia, y sustituirlo por silencio. Los tres desenlaces son "el archivo abrió". Solo uno se detecta escuchando, y solo si sabes qué debería haber estado ahí.

Las cuatro fallas que explican la mayoría de los rechazos

Un conteo de pistas en fmt que no concuerda con chna. fmt .nChannels dice 16; chna.numTracks dice 14. El archivo es internamente inconsistente desde los dos primeros chunks — por lo general un bounce que cambió el número de pistas después de haber creado los metadatos, o una herramienta que eliminó pistas sin reescribir chna. Detectarlo consiste en leer dos enteros y compararlos: la comprobación más barata del proceso, y atrapa una proporción asombrosa de fallas. Verifica al mismo tiempo que todo trackIndex esté dentro de 1 … fmt .nChannels.

Un audioTrackUID al que ningún objeto hace referencia. Un UID en chna que ningún audioObject referencia significa que existe audio que nada va a renderizar; el caso espejo, un audioTrackUIDRef en el XML sin entrada correspondiente en chna, significa que los metadatos esperan una pista que no está. Construye el conjunto de UID de chna y el conjunto de axml y toma la diferencia simétrica; debe quedar vacía. La EBU Tech 3392 enuncia la intención directamente: "If the audioObject refers to an audioPackFormat it should also refer to the corresponding audioTrackUIDs."

Tiempos de bloque que corren hacia atrás. La BS.2076 es inequívoca: "When there is more than one audioBlockFormat within an audioChannelFormat … both rtime and duration shall be present." La EBU Tech 3392 lo aprieta hasta la contigüidad — "rtime + duration of an audioBlockFormat should match the rtime of the following block" — con el primer bloque de un objeto comenzando en 00:00:00.00000, ningún bloque más corto que una muestra, y las duraciones sumando el audioObject padre. Recorre los bloques en el orden del documento y comprueba que rtime[n] + duration[n] == rtime[n+1]. Las fallas vienen en tres formas: huecos, donde el comportamiento del renderizador es indefinido y unos mantienen la última posición mientras otros silencian; solapamientos, donde los bloques pelean entre sí; y bloques fuera de orden cronológico, que es automatización saltando hacia atrás a mitad de programa.

Un lecho descrito en el XML que nunca se imprimió al disco. El XML declara un pack DirectSpeakers 7.1.4 — doce canales — pero solo se imprimió el subconjunto 5.1, o los canales de altura estaban silenciados en el bounce y se imprimieron como negro digital. El grafo de referencias está intacto; el audio no. Las comprobaciones estructurales no pueden atrapar esto: hace falta análisis de esencia, medir si cada canal reclamado por un pack DirectSpeakers contiene señal siquiera. El negro digital en un canal de lecho declarado no es automáticamente un error — una mezcla legítima puede dejar vacío un canal trasero superior — pero siempre merece una decisión humana.

Qué está publicado sobre la sonoridad inmersiva, y qué no

Un número no sobrevive al salto desde el estéreo, y vale la pena decir por qué.

La BS.1770-5 (November 2023) es la edición vigente; la BS.1770-4 está superada, aunque la mayoría de los medidores desplegados todavía la citan. Su algoritmo central pondera L, R y C en 1.0 y Ls y Rs en 1.41 (unos +1.5 dB), excluye el LFE, y su alcance es "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 y el audio basado en objetos — que debe ser renderizado antes de poder medirse. La sonoridad inmersiva no es, por lo tanto, una propiedad del archivo sino de un render, y cambiar la configuración de destino cambia el número. Mide un render conforme a la BS.2127 hacia una configuración BS.2051 con nombre, con un medidor BS.1770-5, y registra las tres cosas en tus notas de entrega; la BS.2127 define el renderizador ADM de referencia, y su hermano de código abierto, el EBU ADM Renderer (EBU Tech 3388), es la vía práctica para obtener una cifra reproducible.

Ningún servicio de streaming musical publica un objetivo de sonoridad integrada para entrega inmersiva. Circulan cifras en foros y en material de capacitación de fabricantes; ninguna es una especificación publicada y este artículo no va a repetir ninguna como si lo fuera. Lo que sí está publicado es para estéreo basado en canales — el objetivo integrado de Spotify de −14 LUFS con un techo de pico real de −1 dBTP, que se aprieta a −2 dBTP por encima de −14 LUFS, y los −16 LUFS de la AES TD1008 para música (su cifra de −18 LUFS aplica a contenido hablado, y declarar −18 como el objetivo para música es un error frecuente y grave).

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 los fijan sus dueños, cambian sin atenerse a los calendarios de la ITU o de la EBU, y no se enuncian aquí; no se reclama afiliación ni respaldo alguno. Lee la documentación vigente del propio licenciante.

Qué comprobar antes de enviarlo

Primero las comprobaciones estructurales; son rápidas e invalidan todo lo que viene después.

• Los primeros cuatro bytes son BW64. Si dicen RIFF, es un WAV común y no puede superar los 4 GB.
• ds64 es el primer chunk después de la firma, sus tamaños de 64 bits coinciden con los tamaños del archivo y de data en disco, y todo chunk sobredimensionado que no sea data tiene una entrada ChunkSize64 en la tabla.
• Localiza axml explícitamente, incluso después de data — nunca concluyas "no hay ADM" a partir de un escaneo parcial.
• La frecuencia de muestreo y la profundidad de bits de fmt coinciden exactamente con la especificación de entrega. Nada de conversión de frecuencia de muestreo después de crear el ADM — invalida todo rtime y toda duration expresados en muestras.
• fmt .nChannels es igual a chna.numTracks; todo trackIndex está en rango y con base 1.
• Cada entrada de chna mide exactamente 40 bytes con los campos de ancho fijo correctamente rellenados, y todo packRef de 0x1000 para arriba resuelve a una definición personalizada presente en axml.
• Todo audioContentIDRef, audioObjectIDRef, audioPackFormatIDRef, audioChannelFormatIDRef y audioTrackUIDRef resuelve. Cero aristas colgantes, en ninguna de las dos direcciones, y sin referencias circulares.
• Los formatos de canal de múltiples bloques llevan tanto rtime como duration en cada bloque; los bloques son contiguos y monótonos; los objetos empiezan en 00:00:00.00000.
• Cada canal de un lecho declarado contiene lo que debe. Investiga el negro digital.
• El timecode de inicio de bext es consistente en todo el conjunto, y las conformaciones estéreo y binaural están rerrenderizadas a partir del máster vigente. Una conformación 40 ms adelantada respecto de su padre inmersivo pasa una comprobación de presencia de archivos y falla una escucha sincronizada.
• Saca checksum de cada entregable, guarda el manifiesto, y archiva el XML del ADM aparte del BW64 — un XML que puedes comparar con diff vale más después que un binario que solo puedes volver a analizar.

BW64 y ADM son normas abiertas, publicadas y de lectura libre, y eso conviene aprovecharlo: puedes leer tú mismo la BS.2088 y la BS.2076, analizar un chunk chna con cuarenta líneas de código, y verificar lo que el exportador de un fabricante escribió realmente en lugar de lo que afirmaba su cuadro de diálogo. Casi todos los rechazos inmersivos innecesarios son errores de integridad referencial que un validador atrapa en menos de un segundo.

El inspector gratuito de BW64/ADM de Mazufa, en mazufa.com/immersive-master-check, analiza el contenedor y los metadatos por completo en tu propio dispositivo y no sube nada, lo que lo hace utilizable con material que contractualmente no puede salir del edificio. Mazufa en sí es gratuita para lanzar, se queda con el 0% de comisión, y es solo por invitación, con revisión humana de cada solicitud completa.

Fuentes

Recomendaciones 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 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/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
• Implementación de referencia 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/

Documentación de servicios

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