Introduction to CWR

This is a practical introduction to Common Works Registration by a software architect with 10+ years of hands-on experience. If you are looking for a general/theoretical introduction, written by a ‘PR expert’, tough luck.

What is CWR

CWR is NOT ‘a common or standard format for the registration and revision of musical works.’, as the official User Manual states. Or, at least, not in the usual definitions of terms ‘common’, ‘standard’, or ‘format’. I would put it more correctly: CWR is something absolutely necessary in contemporary music publishing business.

Not a standard

CWR, today, unless stated otherwise, refers to the CWR Version 2.1 Revision 7. Most societies claim that that is what they implement. But, although the functional specification clearly states that ‘All alphabetic characters will be presented in upper case’, virtually all societies (PROs) use mixed case in their acknowledgment files. That is just one of many examples that refute CWR being a standard.

Not a common something

The same functional specification states a significant number of fields to be mandatory in some societies and completely meaningless in others. Many societies have since implemented their own rules that are not even in the specification. The only common thing is that everyone seems to have problems with it.

Not a well defined format

Well, this is pretty obvious to any contemporary software developer and would be too technical to go into with non-developers. Yes, I can stretch my definition of the ‘file format’ to include CWR. Or any ill-written high-school essay.

Something absolutely necessary

It is used virtually everywhere by now, if you want to handle large number of registrations, there is absolutely no alternative, you have to use CWR version 2.1 revision 7, being what it is, not what specifications say. Yes, there is a purely theoretical Version 2.2, still completely useless.

If you are a developer or a project manager or in any way decision maker, do read the specs. Carefully. Even if you feel you don’t understand any of it. Delegating misunderstanding of the specs is why so many tools have been failing here. They are misleading documents covering a poorly conceived something. They are not understandable to techies any more than to you.

How to CWR

It is actually pretty simple. Create a file that will be accepted in the society you are sending it to. Make sure you can read the acknowledgment file, whatever their implementation of CWR is.

Yes, really. This works for me and my clients. I have tried pretty much every other approach. Nothing else seems to work, except doing what societies expect you to do. Some will tell you what they expect. In some cases explanations and expectations will match.

With time, one learns which societies do things well, which are supportive and how explanation from society A applies to issues in society B. (Society B claims it has no issues and will just keep sending you the Functional Specification.) And, after few years, you can be 99% sure that a file sent will not be rejected for technical (formatting) issues.

It may still be rejected because the data is bad, or because there is a conflict or some other reason that will somehow come back to the developer, sysadmin, or simply anyone who has shown some initiative in the past. Eventually, this may lead to people just stop trying and bounce registrations, acknowledgment files, PDFs around.

Having a visual validator does help a bit here. No, it does not detect all errors, but it is maintained and updated because it just wraps the development version of our proprietary Python library for CWR.

Common issues

There are three general categories of issues. A very important thing is to make all stakeholders understand which is which.

Issues with file format

As I said, you must make it the way receiving society expects. Period. Some societies want to make sure you can send “valid” CWR before they give you access. My tip would be to send as complicated file as you can make. It may take a bit longer to get first file in, but it will pay itself out in the long run.

You must be able to parse acknowledgment files and turn them into something readable, and hopefully understandable, to a typical office worker. Otherwise every issue will fall into this category.

Bad data

I have seen tons of CWR files. Most of errors in them was caused by bad data. There are many causes for this.

One reoccurring example is related to auto-formatting. Some tools turn hyphen (-) into the em dash (—) or en dash (–) and when this gets into a CWR file, a hell breaks loose. It adds a byte to the overall length of the row and all following fields are misaligned. The acknowledgment file is full of false errors are quite misleading. This is detectable, but most common tools that generate CWR do not support this. Of course, this applies to a wide range of characters.

But many data-related issues can only be detected by a society. And often it is not detected in all societies the file was sent to, which leads to complications in tracking acknowledgments and revisions.

The rules are simple here, validate your output in all ways imaginable and still be ready it will fail in some societies and pass in others.

Bad people

Now, the politically correct form is to call it ‘communication issues’. But for a long time success in this industry was linked to the ability to make your errors seem like someone else’s problems. As royalties kept falling, everyone got more aware of this and now people seem to be looking for a different kind of publishers. Caring ones with great supporting tools.

Walk away when you can, and when you can not, endure. There will be a lot of ‘endure’. You have been warned.


Is there a list of rules what actually works?

Yes, in the aforementioned proprietary library we have many of the real-world rules. I have been following the CWR files created by many publishing companies, at least two majors are quite good in technical things. As far as I know, there is nothing written in English that is comprehensive enough. Or any in open source software that I know of.

Why proprietary? Don’t you believe in open source?

There is a small, but great PHP library for CWR that is open source. I don’t know how many people use it, but there is only a single contributor. That library is well written and well documented and the author is extremely helpful.

Still, he got no help from open-sourcing it. I am not surprised, this industry in not ripe for open source stuff. If you disagree, join him in his efforts with APORIA-Works-Registration PHP lib.

Another tool I have found interesting, although I have not used it, is CWR Data Model API by WESO and related repositories in Python. I find it is more of an academic proof of concept and oriented towards societies, as much as the previous one is more oriented towards small publishers.

How can you help us?

We have a SaaS in development. It is being tested by few novel publishing and publishing-related companies. It is not publicly available yet.

We have a set of free tools. It actually makes very much sense to try some of them out, they are here for educational purposes. If you want to test our SaaS, show me that you are serious by testing the tools.

And we offer some CWR-related services.