DDEX 4.3 vs 3.8.2: What's the Difference?
The practical differences between DDEX ERN 4.3 and ERN 3.8.2: message structure, UGC clips, immersive audio, enrichment standards, and what each version means for labels and distributors.
ERN 3.8.2 and ERN 4.3 are two versions of the same DDEX standard: the Electronic Release Notification, the message format distributors use to deliver releases to DSPs. 3.8.2 is the long-standing workhorse that much of the industry still runs on; 4.3 is the modern redesign, restructured around a single release per message, with first-class support for UGC clips, immersive audio, and the MEAD and PIE enrichment standards. Both are in active use, which is why serious distribution platforms speak both.
If you want the basics of DDEX first, start with what is DDEX music distribution. This post is the version comparison.
The short comparison
| ERN 3.8.2 | ERN 4.3 | |
|---|---|---|
| Role | Long-standing workhorse version | Current-generation redesign |
| Message structure | Album and all track releases described in one heavily nested message | Restructured around a single release, with clearer separation of resources, releases and deals |
| UGC clips | Not modeled | First-class clip support for UGC and social platforms |
| Immersive and hi-res audio | Limited | Improved support for immersive formats and richer audio technical metadata |
| Enrichment | Editorial data crammed into the ERN itself, or sent off-standard | Designed to work alongside MEAD (editorial and marketing data) and PIE (party data) |
| Adoption | Still required by many DSP integrations | Increasingly preferred for newer integrations |
What ERN 3.8.2 is
ERN 3.8.2 is the version of the DDEX release notification that a large share of the industry’s DSP integrations were built on. A 3.8.2 message is a single, heavily nested XML file that describes the resources (audio, artwork), the releases (the album and each track), and the deals (who may sell or stream what, where, and from when) all together.
It works, at very large scale, every day. Its limits are structural: the nesting makes messages hard to validate and easy to get subtly wrong, multiple release descriptions in one file invite inconsistency, and concepts the modern industry cares about (UGC clips, immersive audio editions, rich editorial data) have no natural home in it.
What ERN 4.3 adds
The ERN 4.x family is a redesign, not a patch. The changes that matter in practice:
- One release per message, cleaner structure. Resources, release and deals are clearly separated, which makes messages easier to generate, validate and debug. Fewer moving parts per message means fewer silent inconsistencies.
- Clips as first-class citizens. ERN 4.3 models short-form clips properly, which is how catalog gets authorized for UGC and social use without side-channel spreadsheets.
- Immersive and technical audio metadata. Modern editions (immersive mixes, hi-res masters) are describable in-band rather than bolted on.
- Designed for enrichment. ERN 4.3 works alongside MEAD (Media Enrichment and Description: moods, focus tracks, marketing copy) and PIE (Party Identification and Enrichment: richer artist and contributor data). Editorial data gets its own standard instead of being crammed into the delivery message.
What this means for labels and distributors
Here is the practical point: the ERN version is your platform’s problem, not yours. DSPs adopt versions on their own schedules, so the real world is mixed: some integrations require 3.8.2, others prefer 4.x, and the answer changes as stores upgrade. A label should never have to re-author its catalog for a message format.
What you should verify before signing with any distribution platform:
- Does it speak both? If a platform only handles one version, some part of the DSP landscape is being served through a workaround.
- Is the version chosen per DSP? The correct behavior is a per-DSP protocol map, maintained on the platform side, invisible to you.
- Is DDEX native or a translation layer? Infrastructure that stores catalog in its own format and translates to DDEX at the edge tends to lose data in corners. DDEX-native systems do not.
How limbo/ handles it
limbo/ is DDEX-native end-to-end: ERN 3.8.2 and 4.3, chosen per DSP from a protocol map we maintain, generated from the same catalog data. Quality control validates every message against each store’s requirements before it ships, which is a large part of why delivery takes hours, not weeks. If you are building on top of distribution, the same catalog is available through the limbo/ API.
