Music Metadata Cable Equivalents
One tool for one task
For a long time, professionals have been using specialized tools, one tool for one task, in just about any profession. Cheaper multi-purpose tools are for amateurs and simple tasks.
A smartphone, a great representative of a multi-purpose tool, can replace video and photo cameras, audio recorders, can simulate various musical instruments and do zillion other tasks. But it really does only one thing really well. It notifies. (I will leave argumentation why smartphones descend from pagers, not phones for another time.)
One may type an SMS on a smartphone, but for serious typing, one needs a keyboard. Preferably a real, mechanical one. One can record audio with a smartphone alone, but having a good microphone will raise the quality, and using an interface with good preamps will make it even better. And for professional recording, one will probably want to use a studio with many specialized tools.
The exactly same logic applies to metadata. If one is registering works professionally, with intention that the works would yield money, then it makes little sense to use a tool where registrations, or musical metadata in general, are an afterthought.
If one is a publishing company, without being a label, then a narrowly specialized tool that handles registrations and royalty distribution is all that is needed.
If one has to handle publishing (musical work) and label (recording) side of things, then a tool that integrates authors’ and neighbouring rights registrations and royalty distribution might be the right thing.
For production music companies, that do all of that and still need to pitch and sell their music, in theory at least, it would make sense to have a set of integrated modular tools. At the moment, such a modular system does not exist. One really needs to use two or maybe even three tools. But it is safe to presume that things will be changing in this area as well.
Ideally, the life of metadata should start far earlier and be integrated in the music production stack, not be an afterthought. Deeper this deliberation goes, it is less about tools and more about modularity and integration. Basically cable equivalents. And this is the main issue. There are no integration (data exchange) standards that make sense. CWR, EBR or any DDEX formats are quite useless for this.
Why CWR & DDEX are bad
DDEX has this licence issue that deserves a long rant, but technically it is not bad and not too old. It provides normalized data. While that results in smaller files, it also means that in order to finish an import process of a single work, one has to import all of writers, publishers, artists, etc., in the file.
In audio terms, this would mean extremely large latency. Not in milliseconds or even seconds, more like minutes.
CWR has a very low latency. But the underlying EDI format is from seventies, contemporary developers have no idea what EDI is. There are other issues with it as well, but this one is enough to dismiss it.
Both these standards go through a Brexit-like process. It takes forever to not reach any meaningful conclusion. But somehow, this is the will of the people. Or so, at least, claim those who are paid by majors to “represent” ordinary people.
What would work
It is my deep belief that so badly needed integration standards can not arise from theoretical consideration of people who have been creating CWR and DDEX. They must come from people who actually have to connect different services.
I would add “recently”, but that really does not mean anything definitive. For me, it would mean “in the last year”. But even if it was done exclusively by people who have done it, in any project that is used by any business entity, at least once in this millenium, that would be a great move forward.