We’ve been spending a lot of time poking around the back end of the music industry lately. Not as artists. Not as distributors. Something else entirely.
We can’t really tell you much about what we’re building yet. What we can say is that we’re exploring a new idea in music. Before we could even start thinking about the product side of things, we had to understand how the music business actually moves its data around.
If you have ever searched for a song and found five versions of it, each slightly different, with the album name changing or the cover art missing or the artist listed as “Various” even though you know exactly who it is, then you've already experienced what happens when metadata gets weird.
And if you want to build anything in this space, anything that handles music in a way that feels reliable and fair, you are going to end up here. Reading specs. Staring at spreadsheets. Asking basic questions such as, “Who’s the artist on this track?” and getting five different answers depending on which field you’re looking at.
Welcome to the world of music metadata.
What Is DDEX and Why Is It So Hard to Wrap Your Head Around?
Digital Data Exchange (DDEX) is an international standards-setting organization that formed in 2006 to develop standards between companies communicating information along the digital supply chain.
While DDEX is the formal name of the organization, the acronym is also the name of the standard that company introduced. The standard exists so that people sending music out into the world can describe it in a way that the platforms on the other end will actually understand.
DDEX has one spec for new releases, another for metadata enhancements, and a few more for licensing, sales reporting, and other necessities of online commerce. As with any good standard, there are different versions of DDEX. Some platforms keep up with the newest one. Some are a few years behind. Some are not following it all that closely.
The spec itself is long and technical. The examples it provides are raw XML (Extensible Markup Language), packed with tags and nested elements. There are no diagrams. No visual map. No helpful “here’s how this connects to that” kind of guidance.
What you get is a giant tree of metadata, but that tree is hard to see all at once. Every branch leads to three more. Sometimes they just stop and leave you wondering if some data is missing or if that is simply the end of the branch.
You can stare at two files describing the exact same album and find that they look nothing alike. Both might be technically valid. Both might be completely different.
This is about the point where we realized we were going to be here for a while.
The Many Ways of Describing the Same Record
Pretty early on, we figured it would help to look at some real-world examples. We wanted to understand how many different ways the same artist, album, and track information show up across catalogs on different music services.
The answer turned out to be a lot. Here are just a few of the highlights.
Seems like this song should be simple. There’s the original single. There’s the album version. Then there are the 1999 and 2007 remasters. Plus the 40th Anniversary Edition. And the German version. There are live versions recorded during different tours. Some of these live versions are labeled clearly with date and city or venue. Some just say “live” with no further information. Some have different ISRCs. Some share the same one. The artist credits sometimes include collaborators, sometimes not. Sometimes the song title includes quotation marks (as it appeared on the original vinyl LP back in 1977), sometimes it does not.
And then, just to make things weirder, there’s the Philip Glass “Heroes Symphony,” which is a reinterpretation of the Bowie song cycle. Depending on where the metadata came from, this might show up next to the Bowie tracks or in a completely separate place.
Queen — “Bohemian Rhapsody” and the Soundtrack Problem
The Bohemian Rhapsody soundtrack is a great example of how messy credits can get when you mix studio recordings, live versions, and film performances.
The soundtrack album includes the original Queen tracks, but also has live recordings from different shows, plus versions that feature actors from the movie. Sometimes the credits reflect that accurately. Sometimes they do not. Depending on which distributor provided the metadata, these credits may be missing altogether or placed in different fields.
We also found cases where the same recording has multiple ISRCs depending on which edition it came from. Or sometimes the same ISRC is used across different versions that clearly are not identical.
So How Do You Design for This?
At this point, we were still just investigating – we had no product with a defined User Interface. No mockups. No screens to look at. Just this question hanging over us: how do you navigate this level of variation when you are trying to build something that feels right for the music fan on the other end? As Head of Design, I’m here to make sure our end users don’t have to even think about it, but for that to happen, it has to make sense to us first.
The DDEX spec provides fields such as Main Artist, Featured Artist, Remixer, Producer, Composer, Lyricist, and so on. Those seem like they should cover most situations. The problem is that there’s no enforcement as to how these fields should be used. Some distributors fill them in carefully. Others leave them blank. Some jam extra information into whatever field seems convenient.
Take “One Dance” by Drake. The track officially features Wizkid and Kyla. But depending on the metadata source, Kyla might show up in the featured artist field, or as the one of main artists.
The spec allows for these possibilities, but it does not provide any guidance on how to handle them. It certainly does not help you figure out what a listener would expect to see.
What We’ve Learned So Far
DDEX is not the enemy here. The fact that a standard exists at all is pretty impressive, considering how chaotic the music ecosystem can be. But what we learned, the hard way, is that the standard alone is not enough. It’s one thing to define a spec on paper. It’s another thing entirely to see how that spec actually gets used by the dozens of companies that have to interact with it every day.
Optional fields often stay blank. Artist names collide across different versions of the same song. Metadata that seems like it should be identical across platforms turns out to be anything but.
And if the metadata is wrong, or just inconsistent, the product feels broken. Even if the design is beautiful. Even if the technology works perfectly. Bad data makes the experience feel unreliable before the user can even tell you why.
We are still at work on this. Still reading specs. Still pulling apart XML files. Still bumping into edge cases we hadn’t even imagined yet.
We can’t tell you where this is going. But we can say that if you’re going to build anything that touches music, you’re going to need to respect the metadata.
Because it is not going to respect you back.