Last time, I discussed the need to automate and standardize rights and royalty transaction processing in today’s music market.  At the heart of that market is streaming plays on on-demand services.  As the latest RIAA revenue figures have shown, on-demand streaming is now the second-largest source of recorded music industry revenue and should overtake downloads as number one sometime this year or next.

Standards for ways of reporting streaming plays so that everyone gets paid are necessary for efficiency and fairness.  There are many players in the royalty-processing game, and music service providers (DSPs) would like to be able to feed them information in a single format, not one for each processor — in the manner of ONIX for books, as I explained previously.

ONIX is a standard for supply-chain information in the book industry; it’s not really a standard for rights and royalties reporting.  The analogous standard in music is DDEX (Digital Data Exchange), a family of standards that are in wide use for certain types of music supply-chain information exchanges, such as sales reporting and labels’ notifications of new releases.  Yet last week, YouTube took a step that moves DDEX firmly into the world of streaming rights and royalties processing: it announced the release of an open-source implementation of the DDEX Digital Sales Report Format (DSRF), along with tools to validate the syntax of DSRF files.

Although this may not sound very momentous, it is — for two reasons.  First, YouTube is the 800 pound gorilla of on-demand streaming; its audience strictly for music listening is several times that of all other on-demand streaming services (Spotify, Apple Music, Deezer, Rhapsody, Tidal, etc.) combined.  YouTube’s adoption of DSRF and offer of open-source code to support it (and validate files) virtually ensure that royalty processors (Consolidated Independent, Kobalt, Songtrust, etc.) will use it for streaming plays. Second, YouTube’s adoption of a format originally designed for retail sales (e.g., of downloads) puts all doubts to rest over its applicability for use with the types of streaming models that YouTube supports (e.g., ad-supported on-demand streaming to mobile devices).

An interesting question to consider is whether or how DSRF can be used in the blockchain-based rights transaction solutions that we’ve been discussing here.  DDEX standards are based on message protocols (“choreographies”), where all the message types and their respective timings (e.g. message type Y responds to message type X) are defined.  In contrast, a blockchain is a distributed database that records all transactions.  As such, it eschews message choreographies, or it records transactions once the choreographies have been completed, or somewhere in between (it records transactions at some point during a possibly modified message choreography).

In either situation, it’s conceivable that the DSRF format itself could be used in blockchain transactions, given that its size is reasonable.*  That means that blockchains could be used alongside DSRF to ensure transparency and accountability, either instead of or beyond what the DDEX protocols already offer. In any case, it will be interesting to see if the various blockchain-for-music startups — none of which made any mention of DDEX at the recent Music 4.5 conferences — will adopt it in their solutions instead of trying to create their own standards for rights and royalty data.

*YouTube chose to adopt the flat-file version of DSRF instead of the XML version. Although this flies in the face of conventional practice regarding data exchange standards, the flat files are probably considerably smaller than their XML-based equivalents.