New White Paper: Watermarking Technology and Blockchains in the Music Industry

I have published a white paper that explores the combination of blockchain technology and digital audio watermarks for improving rights management and royalty processing in the music industry. Watermarking Technology and Blockchains in the Music Industry is available in the Whitepapers/Presentations section. This white paper was supported by the watermarking technology company Digimarc.

I’ve been involved in the Open Music Initiative (OMI) and otherwise participating in the dialog around using blockchain technology to improve the reliability, scalability, and security of rights and royalty management processes — which a recent poll suggested are the most promising area for blockchains in music. In particular, the open, lightweight, secure, and distributed properties of blockchains can help succeed where previous projects involving huge monolithic databases have failed.

I noticed a couple of things in my travels that led me to the ideas in this white paper.  When used for music, blockchains seem destined — for the foreseeable future, anyway — to contain transaction data and metadata only, not the actual content. There are a number of reasons for this, not least of which is the practicality of retrofitting blockchain-based solutions on existing and highly popular music distribution channels.  But then links need to exist between the transactions denoted on blockchains and those music files, links that are ideally as secure and trustworthy as blockchain data itself.

It struck me that this aspect of blockchain-based solutions for music (and other types of digital content) was not being addressed very much. The question of how data in blockchain nodes can identify music files with sufficient precision and non-ambiguity for rights and royalty management purposes is an important one.

Some people have suggested using traditional hash functions, like SHA-1 or MD5. These are excellent at unique identification, and hash values are inextricably “bound” to the content because the content itself is used to calculate them. But they are inadequate: two (or more) files may be identical for rights management purposes, yet even one flipped bit in the content results in different hash values, while conversely, you can’t use whatever identifier schemes you want; there’s only one possible identifier for each unique piece of content.

Others have suggested acoustic fingerprints, which are fancy versions of hash values that assign the same value to all files that sound the same (regardless of codec, bit rate, etc.). Those solve the problem of multiple files that should be treated identically for rights and royalty purposes in certain cases. But sometimes they backfire: fingerprints are very good for telling which recordings embody a given composition, but they aren’t as good for identifying which specific recordings they are. For example, I’ve seen cases where fingerprints fail to differentiate between original recordings and remasters.

Hash values and fingerprints may be more worthwhile for other types of content, such as digital visual artworks, which are typically limited to single (or a very small number of) copies of each work.

Header metadata, such as ID3 tags in MP3 files? They can support any identifier or metadata scheme desired; for example, they can be used to differentiate among identical sound recordings intended for different distribution channels (subscription streaming, ad-supported streaming, permanent download, tethered download, ringtone, etc.). But they have no security by themselves — they are trivially easy to alter or delete — and often don’t survive transfers or conversions such as transcoding. Header metadata can be made secure by imposing DRM-like encryption schemes on digital music files. While movie studios sometimes use this for sending content to post-production houses, it won’t fly in the music industry, and certainly not for files distributed to consumers.

Watermarks — data embedded imperceptibly in digital audio files — turn out to be the best possible ways of linking those files with relevant blockchain transactions. Well-designed watermarks are robust to conversions and transformations (including digital-analog-digital conversion, sampling, downsampling, etc.); they can embody whatever identifiers are needed; they can’t be removed or altered without perceptibly marring the content itself; and they don’t impede or restrict any usages of the files. And like header metadata, multiple files that embody the same content can have different identifiers for different purposes.

The white paper explains all this in more detail. It also includes a primer on the world of rights and royalties for music compositions and recordings, to put the industry issues in context. It mentions several of today’s interesting blockchain-related initiatives, such as the OMI, dotBlockchain Music Project, and various startups. The main intent of the white paper is to promote dialog within today’s very active and talented music/blockchain community.

Watermarking and blockchains won’t solve every rights and royalties-related problem in the music industry. For example, they won’t fix the classic “garbage in/garbage out” data problem. But as the white paper shows, the combination of the two technologies should have a lot to offer.

Thanks again to the good folks at Digimarc for their support.



  1. Reblogged this on stevemerola and commented:
    This may be a solution…

  2. It’s not very clear who embeds the watermark. Is it a trusted third party? As for the watermark decoder, it must be widely accessible like contained in music software players. Does this raise an issue wrt to security? It should be easy to remove a watermark when one knows how it is detected.

  3. The watermark can be embedded by anyone who uses a tool from the provider of the watermarking scheme. The provider is in effect a trusted third party. For example, let’s say you’re a record label and you’re watermarking your MP3 music files with a combination of a standard identifier (say, an ISRC) and an indicator of the DSP you’re licensing the file to (say, Apple Music). You would provide the tool with the data you want to embed in the file. The tool would send the data off to the watermarking vendor, which would in effect do the following: store the data in a table, return an identifier for the tool to embed in the file as a payload, and do the embedding. Then whenever someone wants to detect the watermark, it would find the payload, send it to the watermarking vendor, and get the original data (ISRC plus indicator of the DSP) in return.

    So yes, the embedder is a trusted third party that exposes its scheme through the embedding tool (and possibly through APIs that enable others to create their own tools or integrate with their own workflows). Similarly, the vendor would make extractor (what you call “decoder”) tools or APIs available. The vendor could use an authentication scheme for access to the tool or API calls to ensure that only those who have credentials could extract the watermark, assuming the application were something that required this level of security (such as protecting any PII).

    As for your comment “It should be easy to remove a watermark when one knows how it is detected,” that’s not true if the watermark is designed well. There’s a difference between retrieving the payload and actually removing the watermark from the file. With a well-designed watermark, it’s impossible to remove the watermark without marring the file (e.g., disturbing the sound quality) because the original signal is convolved with the payload through one-way functions and/or functions that require knowledge of cryptographic keys to be able to reverse.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: