DDEX 4.3 vs 3.8.2: ¿Cuál Es la Diferencia?
Las diferencias prácticas entre DDEX ERN 4.3 y ERN 3.8.2: estructura del mensaje, clips UGC, audio inmersivo, estándares de enriquecimiento y qué significa cada versión para sellos y distribuidoras.
ERN 3.8.2 y ERN 4.3 son dos versiones del mismo estándar DDEX: la Electronic Release Notification, el formato de mensaje que las distribuidoras usan para entregar lanzamientos a las DSP. 3.8.2 es la versión veterana sobre la que todavía corre buena parte de la industria; 4.3 es el rediseño moderno, reestructurado alrededor de un único lanzamiento por mensaje, con soporte de primera clase para clips UGC, audio inmersivo y los estándares de enriquecimiento MEAD y PIE. Las dos están en uso activo, y por eso las plataformas serias de distribución hablan ambas.
Si primero quieres la base de DDEX, empieza por qué es DDEX en distribución musical. Este artículo es la comparación de versiones.
La comparación corta
| ERN 3.8.2 | ERN 4.3 | |
|---|---|---|
| Rol | Versión veterana, todavía muy usada | Rediseño de generación actual |
| Estructura del mensaje | El álbum y todos los lanzamientos de track descritos en un solo mensaje muy anidado | Reestructurado alrededor de un único lanzamiento, con separación clara de recursos, lanzamientos y deals |
| Clips UGC | No modelados | Soporte de primera clase para clips en plataformas UGC y sociales |
| Audio inmersivo y hi-res | Limitado | Mejor soporte para formatos inmersivos y metadata técnica de audio más rica |
| Enriquecimiento | Datos editoriales embutidos en el propio ERN, o enviados fuera del estándar | Diseñado para trabajar junto a MEAD (datos editoriales y de marketing) y PIE (datos de artistas) |
| Adopción | Todavía requerida por muchas integraciones con DSP | Cada vez más preferida en integraciones nuevas |
Qué es ERN 3.8.2
ERN 3.8.2 es la versión de la notificación de lanzamientos de DDEX sobre la que se construyó gran parte de las integraciones con DSP de la industria. Un mensaje 3.8.2 es un único archivo XML muy anidado que describe juntos los recursos (audio, portada), los lanzamientos (el álbum y cada track) y los deals (quién puede vender o hacer streaming de qué, dónde y desde cuándo).
Funciona, a escala enorme, todos los días. Sus límites son estructurales: el anidamiento hace que los mensajes sean difíciles de validar y fáciles de equivocar sutilmente, varias descripciones de lanzamiento en un archivo invitan a la inconsistencia, y los conceptos que hoy importan (clips UGC, ediciones inmersivas, datos editoriales ricos) no tienen un lugar natural.
Qué agrega ERN 4.3
La familia ERN 4.x es un rediseño, no un parche. Los cambios que importan en la práctica:
- Un lanzamiento por mensaje, estructura más limpia. Recursos, lanzamiento y deals quedan claramente separados, lo que hace los mensajes más fáciles de generar, validar y depurar. Menos piezas móviles por mensaje significa menos inconsistencias silenciosas.
- Clips como ciudadanos de primera clase. ERN 4.3 modela correctamente los clips cortos, que es como el catálogo se autoriza para uso UGC y social sin planillas por fuera.
- Metadata de audio inmersivo y técnica. Las ediciones modernas (mezclas inmersivas, masters hi-res) se describen dentro del estándar, no pegadas por fuera.
- Diseñado para el enriquecimiento. ERN 4.3 trabaja junto a MEAD (Media Enrichment and Description: moods, focus tracks, textos de marketing) y PIE (Party Identification and Enrichment: datos más ricos de artistas y colaboradores). Los datos editoriales tienen su propio estándar en vez de ir embutidos en el mensaje de entrega.
Qué significa esto para sellos y distribuidoras
El punto práctico es este: la versión de ERN es problema de tu plataforma, no tuyo. Las DSP adoptan versiones en sus propios plazos, así que el mundo real es mixto: algunas integraciones requieren 3.8.2, otras prefieren 4.x, y la respuesta cambia a medida que las tiendas se actualizan. Un sello nunca debería tener que rehacer su catálogo por un formato de mensaje.
Lo que sí conviene verificar antes de firmar con cualquier plataforma de distribución:
- ¿Habla las dos? Si una plataforma solo maneja una versión, alguna parte del mapa de DSPs se está sirviendo con un workaround.
- ¿La versión se elige por DSP? El comportamiento correcto es un mapa de protocolos por DSP, mantenido del lado de la plataforma, invisible para ti.
- ¿Es DDEX nativo o una capa de traducción? La infraestructura que guarda el catálogo en su propio formato y traduce a DDEX en el borde tiende a perder datos en las esquinas. Los sistemas DDEX nativos, no.
Cómo lo maneja limbo/
limbo/ es DDEX nativo de punta a punta: ERN 3.8.2 y 4.3, elegidos por DSP desde un mapa de protocolos que mantenemos nosotros, generados desde los mismos datos de catálogo. El control de calidad valida cada mensaje contra los requisitos de cada tienda antes de enviarlo, y esa es gran parte de la razón por la que la entrega toma horas, no semanas. Si construyes sobre la distribución, el mismo catálogo está disponible a través de la API de limbo/.
