Registration of Musical Works

Before we start covering this topic, let us acknowledge a simple fact. The actual registration processes in various collective management organizations, dealing with rights of authors and publishers of musical works, are quite similar. The underlying legal framework are very different. The remainder of this article will not use terms “claim” and “licencing”, acknowledging that in some legal frameworks and contexts, they would be more appropriate than “registration”. In this article, we use this term in the context of registering musical works with collective management organizations: collective societies, performance rights organisations, etc.

The topic of registrations is touched upon in many of our videos, including this one from our Music Publishing 101 series.

The context of this article is very clear. We are talking about using music catalogue software in general, and criteria for choosing the right one. In this article, we are focused on batch registrations. There are really two parts to this process:

Generation and Parsing of CWR

What is really in focus in this article is the former: generation and parsing of CWR files. Well, not just CWR files, a comprehensive music catalogue software should be able to generate and parse several other formats as well, but CWR is at the top of the list. And being able to create registrations in CWR format and, just as importantly, parse acknowledgments in the same format, is the difference between actual catalogue management solutions and wannabees.

An ever-increasing number of music catalogue solutions claim to be generating and/or parsing CWR, but this is simply not true. They would be just wasting your time and money. While affordability is a relative term, total validation is not. The costs of incomplete validation is the single largest cost in a music catalogue software.

Let me explain this claim.

Data Validation on Input

When a CWR file is delivered to a CMO, it undergoes a validation process. This process has two distinctive steps. The first one is a technical validation of the CWR file itself. The second is comparing the data in the CWR file with the data in CMO’s database.

The former first checks if the file itself is well-formed, if the file and group headers and trailers are present and the number of transactions (work registrations) is the right one, if the order of records within each transactions is correct, etc. Not all software claiming to be exporting CWR gets this right. But most do.

Then the data in each transaction (work registration) is validated. Field-level validation checks whether all checksums are OK, no text contains invalid characters, etc. Most solutions out there fail here, although field-level validation is simple to program. Record-level validation checks if data in every record makes sense as a whole. For example, if a work is marked as library work, then the library name must be present. If it is marked as made for film, then library name not required, but the title of the film is. And then the transaction-level validation comes in. If work is original work, then writers can only have roles “Composer”, “Lyricist” or “Composer and Lyricist”. If it is a modification, then it must have at least one of the other roles.

It is complicated. And it is important that the catalogue software performs all these checks during the input (or import) and warns the user when something is not right. Otherwise, bad data will get into the system and faulty CWR files will go out. They may even be accepted in some CMOs, while rejected in others. (A long and very complicated story.) Then someone will have to deal with the issues manually, figure out what is wrong and fix it. And try again. And again… and this is why the cost of incomplete validation is huge. Because people have to manually fix errors that software should have prevented in the first place.

Processing Acknowledgements

CWR is a two-way protocol. Publishers send registrations, societies send acknowledgements. A music catalogue management software must be able to process them and import the relevant data.

The idea behind the acknowledgement has always been to return the data from a society database, not just mirror the data that was sent in the registration. Not all societies implemented it that way. Therefore the options differ from one society to the next.

With some, all one gets is the status of the registration, sometimes not even in CWR format. However, such societies are rare. In most, one gets a properly formatted CWR acknowledgement with their work ID and status of the registration.

The status is very important. If a registration was not accepted for a work, you probably want to act. Their ID is also important, as many societies do not send your work ID in their royalty statements. The third crucial information is ISWC. It is not always present, and different societies deliver it in different ways. However, it is of utmost importance to get it back into your software before you export the data and send it to anyone else, most notably sub-publishers.

You may choose to import more, but importing society work IDs, statuses and ISWCs from acknowledgement files is a bare minimum.

Automated File Exchange

There are two options, it can be integrated into the software, or not. At the moment, we have chosen not to, because we have encountered silent failures in our tests. FileZilla seems to be working fine for all our clients. But, if you are delivering dozens of files to multiple societies every week, then this may be really important for you.

Next

In the next article, we'll compare different software types broadly fitting into "Music Catalogue Management" category.