La generación de feeds DDEX es el proceso de convertir un lanzamiento musical y sus metadatos en un mensaje XML estandarizado que las plataformas de streaming pueden ingerir de forma automática. El formato es el ERN (Electronic Release Notification) de DDEX, y lleva todo lo que una DSP necesita para publicar un lanzamiento: títulos, artistas, ISRC, referencias de portada, recursos de audio, territorios y condiciones del acuerdo. Generar ese feed correctamente es lo que hace que tu música se entregue sin reintroducir datos a mano.
DDEX (Digital Data Exchange) es el organismo de estándares que define la mensajería XML utilizada en toda la cadena de suministro de la música digital, entre sellos, distribuidores, DSP, editoriales y sociedades de gestión (documentación de DDEX ERN). No tienes que ser miembro de DDEX para implementar el estándar. El trabajo, y la parte que la mayoría de los sellos preferirían no asumir, es generar feeds ERN válidos y mantenerlos al día a medida que cambian los requisitos de cada DSP.
Esta guía explica qué contiene un mensaje ERN, cómo funciona la generación de feeds paso a paso, la diferencia entre ERN 3.8.2 y 4.3 y cómo evaluar a un proveedor que lo gestione por ti, incluido dónde encaja LabelGrid.
¿Qué es un feed DDEX ERN?
Un feed ERN es un documento XML que describe un lanzamiento y cómo debe ponerse a disposición. El mensaje principal es el NewReleaseMessage, y agrupa tres cosas que una DSP necesita: los recursos, el lanzamiento y las condiciones.
- ResourceList contiene las grabaciones de sonido, el vídeo y las imágenes, cada uno con identificadores (ISRC para las pistas) y detalles técnicos.
- ReleaseList es el lanzamiento en sí: título, artista mostrado, nombre del sello, UPC, género, fecha de lanzamiento.
- DealList fija las condiciones comerciales, incluyendo qué territorios y plataformas lo reciben, el calendario de lanzamiento y cualquier ventana de pre-pedido o pre-save.
Las compañías discográficas y los distribuidores envían estos mensajes a las DSP; la DSP analiza el feed y publica el lanzamiento según las condiciones del acuerdo (documentación de DDEX ERN). Una retirada, una corrección de metadatos o un nuevo territorio se convierten cada uno en su propio mensaje con el mismo formato. Equivoca un solo campo obligatorio y la DSP rechaza el feed entero, por lo que la validación importa tanto como la generación.
¿Cómo funciona la generación de feeds DDEX?
La generación de feeds toma los datos de tu lanzamiento y produce un paquete ERN listo para las DSP. Un pipeline típico funciona así:
- Recopila los metadatos. Campos de lanzamiento y de pista, colaboradores, identificadores (ISRC, UPC), territorios y advertencias de contenido explícito.
- Referencia los recursos. Los archivos de audio transcodificados a la especificación de cada DSP y la portada que cumple los requisitos de tamaño (normalmente 3000x3000px como mínimo) se adjuntan como recursos.
- Valida. El feed se comprueba contra el esquema de DDEX y el propio perfil de la DSP de destino antes de enviar nada. Las líneas de copyright que faltan, los ISRC malformados o las portadas demasiado pequeñas se detectan aquí.
- Genera el XML ERN. El
NewReleaseMessagese construye con la versión correcta (3.8.2 o 4.3) para el destino. - Entrega. El paquete se envía a cada DSP y se devuelve un acuse de recibo.
- Gestiona las actualizaciones. Las correcciones, las retiradas y las altas de nuevos territorios se envían como mensajes de seguimiento vinculados al mismo lanzamiento.
Por qué esto no es trivial: en 2024 se entregaron a los servicios de streaming unas 99.000 pistas nuevas cada día (Luminate 2024 Year-End Report). Nadie codifica XML a mano a ese volumen. LabelGrid gestiona la generación de feeds DDEX de principio a fin, generando y validando ERN contra el perfil actual de cada DSP y entregando a todas las plataformas principales, para que los sellos y distribuidores envíen lanzamientos en lugar de construir y mantener un motor de feeds.
ERN 3.8.2 frente a ERN 4.3: ¿qué versión usan las DSP?
Hoy hay dos generaciones de ERN en uso activo. ERN 3.8.2 sigue siendo la más desplegada; ERN 4.3.x es la que DDEX recomienda para nuevas implementaciones. No son intercambiables. Un motor de feeds tiene que hablar la versión que cada DSP espera.
| Aspecto | ERN 3.8.2 | ERN 4.3.x |
|---|---|---|
| Estado | La más desplegada en implementaciones activas | Recomendada por DDEX para nuevas implementaciones |
| Datos de territorio | Los bloques DetailsByTerritory repiten títulos por territorio | Sobrescrituras territoriales solo donde los datos realmente difieren |
| Colaboradores | Artistas y compositores repetidos por todo el mensaje | Definidos una vez en PartyList, referenciados por ID |
| Lanzamientos de pista | Estructura de lanzamiento completa, con campos redundantes | Composite TrackRelease ligero |
| Tamaño del mensaje | Mayor, por la duplicación | Menor, sin duplicados |
| Audio espacial | Sin estructuras nativas de Dolby Atmos | Metadatos nativos de audio inmersivo |
| Aceptación por las DSP | Aceptada por casi todas las DSP principales | En crecimiento; requerida para nuevas funciones |
La conclusión práctica: muchos distribuidores medianos se quedan en ERN 3.8.2 porque las DSP aún lo aceptan y migrar de ERN 3 a 4 implica reestructurar todo el modelo de datos territorial. Pero las capacidades más nuevas, incluidos los metadatos nativos de Dolby Atmos y la deduplicación de PartyList, solo existen en ERN 4.x. Un proveedor que merezca la pena admite ambas y elige la correcta para cada destino. LabelGrid admite DDEX ERN 3.8.2, 4.3.0, 4.3.1 y 4.3.2 para entrega e importación.
Lo que está en juego al hacer bien la entrega no deja de crecer. El streaming alcanzó el 69,6 % de los ingresos globales de la música grabada en 2025, con 837 millones de suscriptores de pago (IFPI Global Music Report 2026). Un feed rechazado o malformado es visibilidad perdida en el canal donde ahora está la mayor parte del dinero.
Sáltate la ingeniería de ERN
LabelGrid genera feeds ERN 3.8.2 y 4.3 válidos y los mantiene al día a medida que cambian los requisitos de las DSP. Prueba gratuita de 7 días.
Ver planes¿Qué debes buscar en un servicio de generación de feeds DDEX?
Si vas a elegir un proveedor para generar feeds en lugar de construir el tuyo, esta es la lista de comprobación que importa.
| Criterio | Cómo es lo bueno |
|---|---|
| Varias versiones de ERN | Tanto 3.8.2 como 4.3.x, seleccionadas por DSP, no una talla única. |
| Validación previa a la entrega | Comprobaciones de esquema y de perfil por DSP que detectan errores antes de la entrega, no tras el rechazo. |
| Mantenimiento de especificaciones | El proveedor sigue los cambios de perfil de las DSP para que tus feeds no se rompan en silencio. |
| Transcodificación de audio | Archivos codificados a la especificación de cada plataforma como parte del pipeline. |
| Retiradas y actualizaciones | Correcciones, cambios de territorio y retiradas gestionados como mensajes de seguimiento adecuados. |
| Acceso por API | Entrega y estado programáticos, para que la generación de feeds pueda ejecutarse dentro de tus propios sistemas. |
| Soporte SOBO | Capacidad de entregar bajo tus propios contratos con las DSP si tienes acuerdos directos. |
Cómo entregar música mediante DDEX: una ruta paso a paso
- Decide construir o comprar. Mantener un motor ERN y seguir cada cambio de perfil de las DSP es ingeniería continua real. Para la mayoría de los sellos y distribuidores, usar un proveedor es la opción racional.
- Confirma la cobertura de versiones. Asegúrate de que el proveedor genera tanto ERN 3.8.2 como 4.3.x y enruta la versión correcta a cada DSP.
- Prepara metadatos limpios. ISRC y UPC correctos, líneas de copyright correctas y portadas a especificación. Una entrada limpia es lo que pasa la validación.
- Valida antes de entregar. Pasa el feed por las comprobaciones de esquema y por DSP. Corrige lo marcado antes de enviar nada.
- Entrega y confirma. Envía a cada DSP y vigila los acuses de recibo. Sigue qué plataformas han aceptado el lanzamiento.
- Mantén el catálogo. Envía correcciones, nuevos territorios y retiradas como mensajes de seguimiento, y vigila los feeds cuando cambien las especificaciones de las DSP.
LabelGrid encaja en esta ruta con generación completa de feeds DDEX en ERN 3.8.2, 4.3.0, 4.3.1 y 4.3.2, validación previa a la entrega, transcodificación de audio y entrega a todas las DSP principales. Para los equipos que quieren ejecutarlo de forma programática, el mismo pipeline está disponible a través de la API REST de LabelGrid con un sandbox y documentación pública. Como proveedor Spotify Preferred y miembro de Merlin Network, LabelGrid mantiene los feeds al día a medida que evolucionan los requisitos de las plataformas.
Generación de feeds DDEX: la conclusión
La generación de feeds DDEX convierte un lanzamiento en un mensaje ERN estandarizado, el NewReleaseMessage que lleva los recursos, los datos del lanzamiento y las condiciones del acuerdo, que las DSP ingieren de forma automática. Las dos versiones activas son ERN 3.8.2 (la más desplegada) y 4.3.x (recomendada, más pequeña, lista para audio espacial), y un buen proveedor habla ambas, valida antes de entregar y sigue los cambios de especificación de las DSP. Construir tu propio motor es una carga de mantenimiento continua; para casi todo el mundo, un proveedor que gestiona la generación, la validación y la entrega es la mejor opción. LabelGrid gestiona la entrega DDEX para sellos y distribuidores en las cuatro versiones de ERN admitidas, con acceso por API y SOBO para catálogos con acuerdos directos.
Preguntas frecuentes
¿Qué es un feed DDEX?
Un feed DDEX es un mensaje XML estandarizado, normalmente un ERN NewReleaseMessage, que describe un lanzamiento musical y cómo deben ponerlo a disposición las DSP. Lleva los recursos de audio e imagen, los metadatos del lanzamiento y las condiciones del acuerdo (territorios, calendario, plataformas) en un único paquete que la DSP puede ingerir de forma automática.
¿Cuál es la diferencia entre ERN 3.8.2 y ERN 4.3?
ERN 3.8.2 es la versión más desplegada y repite datos como los títulos en los bloques de territorio. ERN 4.3.x es la versión recomendada por DDEX: deduplica los colaboradores en una PartyList, solo envía datos territoriales donde difieren, añade un composite TrackRelease ligero y admite de forma nativa el audio espacial como Dolby Atmos. LabelGrid admite ambas.
¿Necesito generar los feeds DDEX yo mismo?
No. La mayoría de los sellos y distribuidores usan un proveedor que genera y valida los feeds ERN y los entrega a las DSP. Construir tu propio motor significa escribir XML ERN válido, validar contra el perfil de cada DSP y seguir cada cambio de especificación a lo largo del tiempo. Eso es ingeniería continua que solo compensa a escala de major.
¿Es LabelGrid miembro de DDEX?
No. LabelGrid no es miembro del consorcio DDEX, y la membresía de DDEX no es necesaria para implementar el estándar. LabelGrid implementa DDEX ERN y admite las versiones 3.8.2, 4.3.0, 4.3.1 y 4.3.2 tanto para entrega como para importación.
¿Qué es SOBO en la entrega DDEX?
SOBO significa «sent on behalf of» (enviado en nombre de). Es una directiva de DDEX que especifica que el licenciante de un lanzamiento es el cliente, no el distribuidor. Permite que un sello o distribuidor que tiene sus propios contratos directos con las DSP entregue a través de una plataforma como LabelGrid manteniendo intactas la relación directa y las condiciones de regalías.
¿Qué versión de ERN debería usar un catálogo nuevo?
DDEX recomienda ERN 4.3.x para nuevas implementaciones porque es más pequeña, sin duplicados, y admite audio espacial y créditos más ricos. En la práctica, muchas DSP aún aceptan ERN 3.8.2, así que un buen proveedor enruta la versión correcta a cada destino. LabelGrid lo gestiona de forma automática en las cuatro versiones admitidas.
