RIAA Releases Watermarking Payload Specification

The RIAA has released a specification for a watermark payload to be inserted into music files.  It intends this specfication to be a voluntary standard to be adopted by record labels, service providers, and other participants in the digital music value chain.

The spec calls for a payload of 108 bits of data, which falls within the limitations of most practical watermarking schemes.  The bits are divided into three independent parts called layers.  The first layer contains flags to indicate parental advisory, copyright status, and whether the content is pre-release.

The second layer contains identifiers for the content owner, the content itself, and the distribution channel (e.g., a retailer).   These three identfiers, when put together, constitute a globally unique ID for content 52 bits in length — allowing (in theory) for several quadrillion different identifiers.

The third layer is currently undefined; the RIAA contemplates future use of Layer 3 for transaction IDs, such as for identifying individual downloads.

If watermarking is going to be adopted to scale in the media industry, then standards are very necessary.  In broad terms, two things need to be standardized: insertion and detection algorithms, and data payloads.  Standardizing on algorithms is unlikely.  Several vendors have proprietary techniques which are their “secret sauce” and whose effectiveness depends on the application.

But payload standardization benefits all watermarking vendors.  Payload standardization would facilitate communication and interoperability among the various entities that have to insert, detect, or share data, including content owners, aggregators, retailers, content delivery networks, software vendors, and even consumer device makers.

The RIAA’s proposed payload standard is useful for many different applications.  It’s not a content protection scheme per se, as the failed SDMI Level I standard was back ten years ago, though it does contain bits that could be read by consumer devices for the purpose of copyright enforcement.

The primary purpose of the standard is to help identify content.  Content identification is not only application-neutral but can also enable various new types of applications for watermarking, such as contextual advertising, content marketing, digital asset management, and monetization of transformational content uses; see the white paper I wrote last year for more on this.

The release of this spec should be a great help in pushing the music industry towards adoption of watermarking for a variety of purposes.  Its publication should also help to defuse concerns about privacy or hidden agendas — something that the Digital Watermarking Alliance, a trade association for watermarking technology vendors, has been trying to accomplish over the last couple of years.

14 comments

  1. No. Insertion & detection need not be standardized. All you need are keys & perceptual models. & last it was attempted, yes, SDMI, that was taken off the agenda.

    Think about it, how else can artists prevail if they cannot independently sign their digital works? Was compression standardized? Ahem.

    Kerckhoff’s Law, plain and simple, assume the pirates KNOW the watermarking codec! & btw, did SDMI really go away … Cough, cough, cough

  2. First of all, perceptual models are at the heart of the “secret sauce” that watermarking vendors will not be willing to standardize. It’s certainly possible for the music industry to try an SDMI-like approach again (in a way that satisfies antitrust concern), but as I said, it’s highly unlikely given the failure of that initiative.

    Secondly, I think you are confusing different applications of watermarking. Using watermarks to securely embed an artist’s identity is not the same thing as using them for proactive content protection as SDMI tried to do. In the former case, what do you mean by artists “prevailing,” and how does watermarking their identity into their content enable them to do that? And what does this have to do with compression?

  3. Let say 8 bits for the first layer, 52 for the second one. 48 bits remain for tracing the dishonest users who illegally re-distribute their files on P2P networks. IMHO, this is not enough. No anti-collusion code fits within this payload. By mixing their personalized versions of a tune (what is called a collusion), I’m afraid that the pirates will be safe.

  4. Interesting comment. What is a “personalized version of a tune?” Are you referring to something like a mashup or just something where a few bits got twiddled (the way you would try to fool a fingerprinting algorithm)?

  5. Collusion happens where several pirates buy the same content, and mix the versions they get to forge a pirated copy which can’t be traced back to one of them.
    There are usually three possibilities:
    1) If the embedded bits coding the transaction ID are hidden sequentially (for instance a bit per second), the attackers forge a pirated copy picking chunks from the different versions they received.
    2) If these bits are spread all over the content, they use signal processing algorithms to mix the versions (like averaging sample by sample)
    3) and of course, they can degrade the content adding noise, compressing it at a lower bit-rate, etc.

    Of course the watermarking is robut so that 3) alone is useless, but I am not sure that this is the case with 1), 2) or any combination of the three kinds. Conclusion: the number of ways for making a collusion is almost infinite.

  6. Thanks for the explanation. This all hinges on the degree to which the record labels are actually going to use transactional watermarking as an anti-piracy tactic, as opposed to using it for other purposes (e.g. marketing and contextual advertising) and as opposed to not using transactional watermarking at all. It’s certainly a factor that they ought to be taking into consideration (if they aren’t already) when comparing the efficacy of transactional watermarking for anti-piracy with that of DRM.

  7. There is another solution: let’s standardise metadata for digital watermarking e.g. like Dublin Core standard for CD. It seems to be much simpler to embed unique ID (as a not standard and free for watermarking vendors) and assign ID to metadata (http://www.youtube.com/watch?v=Jv1LpAKXIO4).
    Because digital watermarking is not a cryptography (who did write?, any hint? paper?)
    I strongly do not recommend revealing any digital watermarking algorithm details.
    Of course in my opinion, Kerckhoff’s Law should be taking into consideration during digital watermarking algorithm developing process but it is not an explanation I should reveal any algorithms details.
    I think that is still possible to choose of the one, mature digital watermarking standard without revealing embedder and extractor details. Just let’s share algorithms (executable files) with users let’s give them possibility to choose the best one.

  8. Tomasz,

    Actually this is exactly what the RIAA is trying to do – to standardize on the metadata and to leave it to watermarking vendors to implement their own proprietary algorithms. You are correct, the vendors don’t reveal details of their algorithms.

  9. Bill,

    I think that digital watermark ID is not the same as metadata content.
    In particular, the ID payload and the metadata payload can be different. Of course, it is possible to allocate ID to the metadata content. In this case the can observe the huge “gain” of the data payload.

  10. Tomasz,

    Those of us who have worked on content identifier standards tend to view IDs as tantamount to metadata. The usual practice is to use an ID number as an index to a database that contains metadata. The music industry has identifier standards like ISRC that facilitate this. It would be impossible to fit useful metadata in a typical audio watermark payload size, such as the 108 bytes used in the RIAA standard. ID standards like ISRC are designed to be used as watermark payloads for just these reasons.

  11. Thus, is this case to be more precise should we still write “watermark payload”? A lot of people would consider that it is possible to embed such high data payload (108 bits of data).

    May I digress for a moment? I have notice there is a new technology named Hidden Link Technology (HLT) based on digital watermarking (https://mydrmspace.com/hlt/)

    Is it new quality in the Internet advertisement or hidden message distribution?

  12. “Because digital watermarking is not a cryptography (who did write?, any hint? paper?)”

    It is there:

    http://www.irisa.fr/temics/publis/2006/42830001.pdf

  13. Yes, this is the right answer. Thus, if we can’t share the new ideas of digital watermarking algorithms implemented in DRM systems we will never choose the one, optimal method. Furthermore, every DRM system developer will claim that his watermarking algorithm is the best solution. Till now, the well known trade-off between robustness, data payload and transparency seems to be unsolved task.
    Does we really want to have? The winner is the only one and probably there is a unnamed winner right now, but what a pity we will never know his/her name. Any solutions? Top 10 list, international digital watermarking championships, global rank of the algorithm popularity, Internet watermarking platform driven by users and developers? etc.

  14. popicok · ·

    Whats to stop people using Audacity set to record “Stereo Output Bus” which nearly all even basic ‘on board’ sound chips allow these days. People are using the likes of we7 and Spotify with Audacity in this way. Careful line up and tweaked level control gives you a very good quality copy.

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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: