DDEX-feedgenerering

DDEX-feedgenerering är processen där ett musiksläpp och dess metadata omvandlas till ett standardiserat XML-meddelande som streamingplattformar kan läsa in automatiskt. Formatet är DDEX:s ERN (Electronic Release Notification), och det bär med sig allt en DSP behöver för att publicera ett släpp: titlar och artister, ISRC-koder, referenser till omslag och ljudfiler, plus de territorier och avtalsvillkor som gäller. När den feeden genereras rätt levereras din musik utan att något behöver matas in på nytt för hand.

Den här guiden förklarar vad ett ERN-meddelande innehåller, hur feedgenerering går till steg för steg, skillnaden mellan ERN 3.8.2 och 4.3, och hur du bedömer en leverantör som sköter det åt dig, inklusive var LabelGrid passar in.

Vad är DDEX och varför spelar det roll för distribution?

DDEX (Digital Data Exchange) är ett ideellt standardiseringsorgan, grundat 2006, som definierar XML-meddelandeformaten i den digitala musikleveranskedjan. Skivbolag, distributörer, DSP:er, förlag och insamlingsorganisationer använder dem för att utbyta data om releaser, rättigheter och försäljning automatiskt, utan att bygga en egen integration för varje partner (Om DDEX). För distribution är det ERN (Electronic Release Notification) som gäller: meddelandet som levererar en ny release, hänvisningar till dess ljud och omslag samt avtalsvillkoren till en DSP.

LabelGrid levererar releaser till DSP:er som DDEX ERN-meddelanden och stöder ERN 3.8.2, 4.3.0, 4.3.1 och 4.3.2. LabelGrid är inte medlem i DDEX, och medlemskap krävs inte för att tillämpa standarderna: vem som helst kan göra det med DDEX:s kostnadsfria implementeringslicens (DDEX:s standarder). Det knepiga, och den del de flesta skivbolag hellre slipper äga, är att generera giltiga ERN-feeder och hålla dem aktuella allt eftersom varje DSP:s krav förändras.

Vad är en DDEX ERN-feed?

En ERN-feed är ett XML-dokument som beskriver ett släpp och hur det ska göras tillgängligt. Kärnan i meddelandet är NewReleaseMessage, som samlar tre saker en DSP behöver: tillgångarna, släppet och villkoren.

• ResourceList innehåller ljudinspelningarna och eventuell video eller bilder, var och en med identifierare (ISRC för spår) och tekniska detaljer.
• ReleaseList är själva släppet: titel, artistnamn, skivbolagsnamn, UPC, genre och släppdatum.
• DealList anger de kommersiella villkoren, bland annat vilka territorier och plattformar som får släppet, tidpunkt och en eventuell förbeställningsperiod.

Skivbolag och distributörer skickar dessa meddelanden till DSP:er. DSP:n tolkar feeden och publicerar släppet enligt avtalsvillkoren (DDEX:s ERN-dokumentation). En borttagning, en metadatakorrigering eller ett nytt territorium blir vart och ett ett eget meddelande i samma format. Ett schemafel eller ett saknat obligatoriskt fält räcker för att leveransen ska avvisas, och därför är validering lika viktigt som själva genereringen.

Hur fungerar DDEX-feedgenerering?

Feedgenerering tar dina släppdata och producerar ett DSP-färdigt ERN-paket. Ett typiskt arbetsflöde ser ut så här:

1. Samla in metadatan. Fält för släpp och spår, medverkande, identifierare (ISRC, UPC), territorier och explicit-markeringar.
2. Referera tillgångarna. Ljudfiler transkodade till varje DSP:s specifikation och omslag som uppfyller storlekskraven (vanligtvis en kvadratisk master på 3000×3000 px) kopplas in som resurser.
3. Validera. Feeden kontrolleras mot DDEX-schemat och målets DSP-profil innan något skickas. Saknade copyright-rader, felaktiga ISRC-koder eller för litet omslag fångas upp här.
4. Generera ERN-XML:en. NewReleaseMessage byggs med rätt version (3.8.2 eller 4.3) för destinationen.
5. Leverera. Paketet skickas till varje DSP och en bekräftelse returneras.
6. Hantera uppdateringar. Korrigeringar, borttagningar och nya territorier skickas som uppföljande meddelanden kopplade till samma släpp.

Varför det inte är trivialt: under 2024 levererades ungefär 99 000 nya spår till streamingtjänster varje dag (Luminate 2024 Year-End Report). Ingen handskriver XML i den volymen. LabelGrid sköter DDEX-feedgenerering från början till slut: genererar och validerar ERN mot varje DSP:s aktuella profil och levererar till alla större plattformar, så att skivbolag och distributörer kan ägna sig åt att skicka släpp i stället för att bygga och underhålla en feedmotor.

ERN 3.8.2 vs ERN 4.3: vilken version använder DSP:erna?

Två ERN-generationer används fortfarande. ERN 3.8.2 lever kvar i befintliga DSP-integrationer, trots att DDEX:s stöd för alla ERN 3-versioner upphörde den 1 mars 2025. ERN 4.3.x är den aktuella generationen, och DDEX råder till att implementera den senaste versionen. De är inte utbytbara mot varandra. En feedmotor måste tala den version varje DSP förväntar sig.

Den praktiska slutsatsen: befintliga ERN 3-integrationer lever kvar eftersom en migrering från ERN 3 till 4 innebär att hela den territoriella datamodellen byggs om, då ERN 4 har tagit bort DetailsByTerritory-blocken. Nyare möjligheter, som fullt stöd för immersivt ljud och PartyList-deduplicering, kräver ERN 4. En leverantör värd att använda stödjer båda och väljer rätt version per destination. LabelGrid levererar i DDEX ERN 3.8.2, 4.3.0, 4.3.1 och 4.3.2. DDEX-import, som tar in dina egna ERN-leveranser i LabelGrid, finns i API-planerna och i Custom Distribution.

Det blir allt viktigare att få leveransen rätt. Streaming nådde 69,6 % av de globala intäkterna från inspelad musik 2025, med 837 miljoner betalande prenumeranter (IFPI Global Music Report 2026). En avvisad eller felaktig feed betyder förlorad synlighet på den kanal där merparten av pengarna numera finns.

Vad ska du leta efter i en tjänst för DDEX-feedgenerering?

Om du väljer en leverantör som genererar feeder åt dig i stället för att bygga din egen, är det här checklistan som spelar roll.

Så levererar du musik via DDEX: steg för steg

1. Bestäm dig: bygga eller köpa. Att underhålla en ERN-motor och hålla koll på varje ändring i DSP-profilerna är ett reellt och fortlöpande ingenjörsarbete. För de flesta skivbolag och distributörer är en leverantör det förnuftiga valet.
2. Bekräfta versionstäckningen. Se till att leverantören genererar både ERN 3.8.2 och 4.3.x och dirigerar rätt version till varje DSP.
3. Förbered ren metadata. Korrekta ISRC- och UPC-koder, rätt copyright-rader och omslag enligt specifikation. Ren indata är det som klarar valideringen.
4. Validera före leverans. Kör feeden genom schema- och per-DSP-kontroller. Åtgärda det som flaggas innan något skickas.
5. Leverera och bekräfta. Skicka till varje DSP och håll utkik efter bekräftelser. Följ upp vilka plattformar som har accepterat släppet.
6. Underhåll katalogen. Skicka korrigeringar, nya territorier och borttagningar som uppföljande meddelanden, och håll ett öga på feederna när DSP-specifikationerna ändras.

LabelGrid passar in i det här flödet med full DDEX-feedgenerering över ERN 3.8.2, 4.3.0, 4.3.1 och 4.3.2, validering före leverans, ljudtranskodning och leverans till alla större DSP:er. För team som vill köra det programmatiskt finns samma arbetsflöde tillgängligt via LabelGrids REST-API med en sandbox och öppen dokumentation. LabelGrid är Spotify Preferred Provider och medlem i Merlin Network. Feederna hålls aktuella i takt med att plattformarnas krav utvecklas.

DDEX-feedgenerering: summan av kardemumman

DDEX-feedgenerering omvandlar ett släpp till ett standardiserat ERN-meddelande, NewReleaseMessage som bär resurser, släppdata och avtalsvillkor, som DSP:er läser in automatiskt. De två versioner som fortfarande används är ERN 3.8.2 (äldre, DDEX:s stöd upphörde i mars 2025) och 4.3.x (aktuell, mindre, med fullt stöd för immersivt ljud), och en bra leverantör talar båda, validerar före leverans och bevakar ändringar i DSP-specifikationerna. Att bygga en egen motor är en ständig underhållsbörda. För nästan alla är en leverantör som tar hand om feeden från generering till leverans, validering inräknad, det bättre valet. LabelGrid sköter DDEX-leverans för skivbolag och distributörer över alla fyra ERN-versioner som stöds, med API-åtkomst och SOBO för kataloger med direkta avtal.