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.
Bill Rosenblatt
Azita Arvani
Bill Jones
6 Comments
July 13, 2009 at 4:17 pm
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
July 13, 2009 at 7:53 pm
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?
August 19, 2009 at 7:04 am
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.
August 19, 2009 at 7:17 am
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)?
August 19, 2009 at 7:41 am
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.
August 19, 2009 at 7:50 am
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.