International Standard Musical Work Code handling with Common Works Registration 3.0

/media/_versions/images/iswc_full.png

CWR 3.0: Requests for Confirmation/Allocation of ISWCs, made in Django Music Publisher 19.7

ISWC issuing has been a major problem in music rights for quite some time. ISRC, the recording identifier, is issued by labels themselves, and there is no delay, while ISWC is issued by a central authority through collecting societies, which took weeks.

As a consequence, the metadata for the works was never ready and therefore not meaningfully referenced in the metadata for recordings, as a reference without a unique identifier is next to worthless. It is enough to check any public music database to see that performing artists are mostly included in the metadata, while writers are mostly not.

CWR 2.x specification did, in fact, contain two ways for societies to send ISWCs to publishers, but neither was used. With 3.0, a major change is introduced.

How does it work now?

Two new transaction types have been introduced. ISR, depicted above, is an ISWC request. It is extremely simple. It includes only basic data about the work and the writers. ISR can be included in registration (SUB) files, or in dedicated ISR files.

It does not matter whether the work already has ISWC issued or not, the right one will be sent in the response. There are some additional mechanisms that should help to get rid of duplicate ISWCs, but that is beyond the scope of this article.

Is it too simple?

The obvious concern (well, to me at least) is whether the work title and the writers (name and IPI number) with capacities/roles are enough to uniquely define a work. I have seen a lot of fishy “publishing deals” where a new work was registered with different publishing shares, though it was really the same one.

Seems like a brave move by CISAC. The prefix-the-title approach will still work for production music, but not for commercial music. It will make matching-and-merging process simpler and safer, but only if ISWC issuing will be fast. Like same day fast.

Still, the publishers, and even more the societies, will have to engage in massive unlearning. It will be hard for some to accept that 2+2 now can only be 4.

The need for speed

Besides the already explained process of incorporating work metadata in recording metadata, there is another reason why the speed is crucial. Societies and sub-publishers get partial registrations, e.g. half of the shares from one publisher, half from another. They need to recognize that this is the same work, merge the data and, if there is a conflict, report it back.

This is far easier if ISWCs are present. Actually, one can read between the lines of CWR 2.x specification that obtaining ISWC was to be done by the society before the work is actually registered. Only in this context, that specification would make any sense. However, this did not happen.

So, let us presume that a sub-publisher gets work metadata from a client. They can actually send all the works in a CWR 3.0 ISR request, get valid ISWC numbers and then simply match and merge based on them.

Please note that at the time this article was written, this is all hypothetical. But one can hope.