What is new in CWR 3.0, compared to 2.x?

Now that CWR 3.0 specifications are out, here is a brief overview of changes, and to some extent, lack of changes.

EDI and FTP - back to the seventies

Maybe it would be better to start with what is old. It is still roughly based on EDI, a format from the seventies made for 300bps modems, though the specs don’t specify that any longer. The files are to be transmitted via FTP. Yes, another protocol from the seventies. Well, at least they are consistent when it comes to the decade, but not really on how it is to be used (to be covered in another article explaining to contemporary developers how things were done 40+ years ago).

Filename in the File

Another ingenuity is the fact that the file name is now contained in the header row of the file. Such an idea can only have someone who has done no programming work since multithreading was invented. Funilly, the transmission date (according to the specs: The date that this file was transmitted to all receiving entities.) is in the same header row. So, before it is even created, it must be known when the file was delivered.


The good news is that now they specify that the default “character set” (they mean “character encoding”) is Latin1. One can now also specify and use “other character sets”, but only nine 8-bit ones specified in the lookup tables. The change from 2.x is so significant that a move to UTF-8 would be more reasonable, but it did not happen.

CWR File Types

Now there are 6 defined CWR file types. There are still transaction groups, and in most cases, one file type can only hold one transaction type and therefore one group. Although there are more elegant ways to solve this, at least things are clearly defined here.

4-digit Submitter Codes

The submitter code is now in the file and it has been expanded to 4 digits. There are reasons why separating these codes from IPI name numbers makes sense, but this still limits the number of publishers to 1.6 million worldwide. While this may seem like a huge number, compared to the current number of senders, the fact is that there are free tools that do CWR registrations, which will lead to a significant increase in the use of batch registrations.

No more ‘New’ or ‘Revised’

The difference between NWR (new work registration) and REV (revision of existing work) is gone with new WRK (Work Details) transaction. This difference did not really make sense with multiple recipients, so the change is a welcome one. This change will force the societies (and other recipients) to rely more on Submitter Work Number. This was always the best approach, but not everyone followed it.

Registration Retraction

Finally, there is a way to unregister. However, a reason must be specified, and there are only three options. While the specification states that this functionality is to be used when “recently submitted WRK transaction was invalid (i.e. filed in error)”, these allowed reasons don’t really allow unregistering with the simplest and most common reason ever: human error.

ISWC Handling

There is a huge change in this area. This will be covered in a separate article. But, briefly. there was nothing wrong with how it was specified in 2.x, except that it did not work. The new approach circumvents the reasons for that previous failure, but the question remains: Will it work this time?

Licence Reporting

This is something completely new. Now CWR allows for exchanging data on licensed usages of a work. This will be fun to code. All existing solutions are hereby obsolete. A whole new ballgame!

No Ownership Shares

Ownership shares are gone. Gone. This is an interesting development because it really limits the usage of CWR 3.0 for data exchange among publishers. It also limits data validation when it comes to shares, which means errors will be caught later on, most likely resulting in more conflicts.

Territory-based affiliations

CWR now allows for affiliations to be territory-based. It was actually used before with repeating SPU rows, and this is a welcome change, as it will make the CWR file smaller, simpler and easier to process (and read).

Album Data is Gone

Funilly, in CWR 2.2, just recently, fields were added that provide more data about albums, only to be completely removed in 3.0. This is a welcome change, as album data is not relevant anymore, and this was resulting in repeating recording data (when the same recording was on multiple albums).

Work Code Cross Reference

A really really important new feature allows for the exchange of identifiers (work, recording, product, video).

Other changes

There are many other changes, only the most relevant ones have been mentioned.


CWR 3.0 is still a totally outdated format, with many flaws, but compared to the previous version, it is better. But, the most important thing is that it will stir things up and result in new solutions and, more importantly, new approaches.