audiowmark is an Open Source (GPL) solution for audio watermarking.

A sound file is read by the software, and a 128-bit message is stored in a watermark in the output sound file. For human listeners, the files typically sound the same.

However, the 128-bit message can be retrieved from the output sound file. Our tests show, that even if the file is converted to mp3 or ogg (with bitrate 128 kbit/s or higher), the watermark usually can be retrieved without problems. The process of retrieving the message does not need the original audio file (blind decoding).

Internally, audiowmark is using the patchwork algorithm to hide the data in the spectrum of the audio file. The signal is split into 1024 sample frames. For each frame, some pseoudo-randomly selected amplitudes of the frequency bands of a 1024-value FFTs are increased or decreased slightly, which can be detected later. The algorithm used here is inspired by

audiowmark is open source software available under the GPLv3 or later license.

Copyright © 2018-2020 Stefan Westerfeld

This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with this program. If not, see http://www.gnu.org/licenses/.

To add a watermark to the soundfile in.wav with a 128-bit message (which is specified as hex-string):

If you want to use audiowmark in any serious application, please read the section Recommendations for the Watermarking Payload on how to generate the 128-bit message. Typically these bits should be a hash or HMAC of some sort.

The most important options for adding a watermark are:

--key <filename>

Use watermarking key from file <filename> (see Watermark Key).

--strength <s>

Set the watermarking strength (see Watermark Strength).

To get the 128-bit message from the watermarked file, use:

The output of audiowmark get is designed to be machine readable. Each line that starts with pattern contains one decoded message. The fields are seperated by one or more space characters. The first field is a timestamp indicating the position of the data block. The second field is the decoded message. For most purposes this is all you need to know.

The software was designed under the assumption that the message is a hash or HMAC of some sort. Before you start using audiowmark in any serious application, please read the section Recommendations for the Watermarking Payload. You - the user - should be able to decide whether a message is correct or not. To do this, on watermarking song files, you could create a database entry for each message you embedded in a watermark. During retrieval, you should perform a database lookup for each pattern audiowmark get outputs. If the message is not found, then you should assume that a decoding error occurred. In our example each pattern was decoded correctly, because the watermark was not damaged at all, but if you for instance use lossy compression (with a low bitrate), it may happen that only some of the decoded patterns are correct. Or none, if the watermark was damaged too much.

The third field is the sync score (higher is better). The synchronization algorithm tries to find valid data blocks in the audio file, that become candidates for decoding.

The fourth field is the decoding error (lower is better). During message decoding, we use convolutional codes for error correction, to make the watermarking more robust.

The fifth field is the block type. There are two types of data blocks, A blocks and B blocks. A single data block can be decoded alone, as it contains a complete message. However, if during watermark detection an A block followed by a B block was found, these two can be decoded together (then this field will be AB), resulting in even higher error correction capacity than one block alone would have.

To improve the error correction capacity even further, the all pattern combines all data blocks that are available. The combined decoded message will often be the most reliable result (meaning that even if all other patterns were incorrect, this could still be right).

The most important options for getting a watermark are:

--key <filename>

Use watermarking key from file <filename> (see Watermark Key).

--strength <s>

Set the watermarking strength (see Watermark Strength).

--detect-speed

--detect-speed-patient

Detect and correct replay speed difference (see Speed Detection).

--json <file>

Write results to <file> in machine readable JSON format.

Since the software is Open Source, a watermarking key should be used to ensure that the message bits cannot be retrieved by somebody else (which would also allow removing the watermark without loss of quality). The watermark key controls all pseudo-random parameters of the algorithm. This means that it determines which frequency bands are increased or decreased to store a 0 bit or a 1 bit. Without the key, it is impossible to decode the message bits from the audio file alone.

Our watermarking key is a 128-bit AES key. A key can be generated using

and can be used for the add/get commands as follows:

The watermark strength parameter affects how much the watermarking algorithm modifies the input signal. A stronger watermark is more audible, but also more robust against modifications. The default strength is 10. A watermark with that strength is recoverable after mp3/ogg encoding with 128kbit/s or higher. In our informal listening tests, this setting also has a very good subjective quality.

A higher strength (for instance 15) would be helpful for instance if robustness against multiple conversions or conversions to low bit rates (i.e. 64kbit/s) is desired.

A lower strength (for instance 6) makes the watermark less audible, but also less robust. Strengths below 5 are not recommended. To set the strength, the same value has to be passed during both, generation and retrieving the watermark. Fractional strengths (like 7.5) are possible.

Although audiowmark does not specify what the 128-bit message stored in the watermark should be, it was designed under the assumption that the message should be a hash or HMAC of some sort.

Lets look at a typical use case. We have a song called Dreams by an artist called Alice. A user called John Smith downloads a watermarked copy.

Later, we find this file somewhere on the internet. Typically we want to answer the questions:

• is this one of the files we previously watermarked?

• what song/artist is this?

• which user shared it?

When the user downloads a watermarked copy, we construct a string that contains all information we need to answer our questions, for example like this:

To obtain the 128-bit message, we can hash this string, for instance by using the first 128 bits of a SHA-256 hash like this:

This 128-bit message can be used as watermark:

At this point, we should also create a database entry consisting of the hash value $MSG and the corresponding string $STRING.

The shell commands for creating the hash are listed here to provide a simplified example. Fields (like the song title) can contain the characters ' and |, so these cases need to be dealt with.

If we find a watermarked copy of the song on the net, the first step is to detect the watermark message using

The second step is to perform a database lookup for each result returned by audiowmark. If we find a matching entry in our database, this is one of the files we previously watermarked.

As a last step, we can use the string stored in the database, which contains the song/artist and the user that shared it.

The advantages of using a hash as message are:

1. Although audiowmark sometimes produces false positives, this doesn’t matter, because it is extremely unlikely that a false positive will match an existing database entry.

2. Even if a few bit errors occur, it is extremely unlikely that a song watermarked for user A will be attributed to user B, simply because all hash bits depend on the user. So this is a much better payload than storing a user ID, artist ID and song ID in the message bits directly.

3. It is easy to extend, because we can add any fields we need to the hash string. For instance, if we want to store the name of the album, we can simply add it to the string.

4. If the hash matches exactly, it is really hard to deny that it was this user who shared the song. How else could all 128 bits of the hash match the message bits decoded by audiowmark?

If a watermarked audio signal is played back a little faster or slower than the original speed, watermark detection will fail. This could happen by accident if the digital watermark was converted to an analog signal and back and the original speed was not (exactly) preserved. It could also be done intentionally as an attack to avoid the watermark from being detected.

In order to be able to find the watermark in these cases, audiowmark can try to figure out the speed difference to the original audio signal and correct the replay speed before detecting the watermark. The search range for the replay speed is approximately [0.8..1.25].

Example: add a watermark to in.wav and increase the replay speed by 5% using sox.

Without speed detection, we get no results. With speed detection the speed difference is detected and corrected so we get results.

The speed detection algorithm is not enabled by default because it is relatively slow (total cpu time required) and needs a lot of memory. However the search is automatically run in parallel using many threads on systems with many cpu cores. So on good hardware it makes sense to always enable this option to be robust to replay speed attacks.

There are two versions of the speed detection algorithm, --detect-speed and --detect-speed-patient. The difference is that the patient version takes more cpu time to detect the speed, but produces more accurate results.

By default, the watermark will store a 128-bit message. In this mode, we recommend using a 128bit hash (or HMAC) as payload. No error checking is performed, the user needs to test patterns that the watermarker decodes to ensure that they really are one of the expected patterns, not a decoding error.

As an alternative, an experimental short payload option is available, for very short payloads (12, 16 or 20 bits). It is enabled using the --short <bits> command line option, for instance for 16 bits:

Internally, a larger set of bits is sent to ensure that decoded short patterns are really valid, so in this mode, error checking is performed after decoding, and only valid patterns are reported.

Besides error checking, the advantage of a short payload is that fewer bits need to be sent, so decoding will more likely to be successful on shorter clips.

For video files, videowmark can be used to add a watermark to the audio track of video files. To add a watermark, use

To detect a watermark, use

The key and strength can be set using the command line options

--key <filename>

Use watermarking key from file <filename> (see Watermark Key).

--strength <s>

Set the watermarking strength (see Watermark Strength).

Videos can be watermarked on-the-fly using HTTP Live Streaming.

Usually, an input file is read, watermarked and an output file is written. This means that it takes some time before the watermarked file can be used.

An alternative is to output the watermarked file as stream to stdout. One use case is sending the watermarked file to a user via network while the watermarker is still working on the rest of the file. Here is an example how to watermark a wav file to stdout:

In this case the file in.wav is read, watermarked, and the output is sent to stdout. The "play -" can start playing the watermarked stream while the rest of the file is being watermarked.

If - is used as output, the output is a valid .wav file, so the programs running after audiowmark will be able to determine sample rate, number of channels, bit depth, encoding and so on from the wav header.

Note that all input formats supported by audiowmark can be used in this way, for instance flac/mp3:

Similar to the output, the audiowmark input can be a stream. In this case, the input must be a valid .wav file. The watermarker will be able to start watermarking the input stream before all data is available. An example would be:

It is possible to do both, input from stream and output as stream.

Streaming input is also supported for watermark detection.

So far, all streams described here are essentially wav streams, which means that the wav header allows audiowmark to determine sample rate, number of channels, bit depth, encoding and so forth from the stream itself, and the a wav header is written for the program after audiowmark, so that this can figure out the parameters of the stream.

There are two cases where this is problematic. The first case is if the full length of the stream is not known at the time processing starts. Then a wav header cannot be used, as the wav file contains the length of the stream. The second case is that the program before or after audiowmark doesn’t support wav headers.

For these two cases, raw streams are available. The idea is to set all information that is needed like sample rate, number of channels,…​ manually. Then, headerless data can be processed from stdin and/or sent to stdout.

--input-format raw

--output-format raw

--format raw

These can be used to set the input format or output format to raw. The last version sets both, input and output format to raw.

--raw-rate <rate>

This should be used to set the sample rate. The input sample rate and the output sample rate will always be the same (no resampling is done by the watermarker). There is no default for the sampling rate, so this parameter must always be specified for raw streams.

--raw-input-bits <bits>

--raw-output-bits <bits>

--raw-bits <bits>

The options can be used to set the input number of bits, the output number of bits or both. The number of bits can either be 16 or 24. The default number of bits is 16.

--raw-input-endian <endian>

--raw-output-endian <endian>

--raw-endian <endian>

These options can be used to set the input/output endianness or both. The <endian> parameter can either be little or big. The default endianness is little.

--raw-input-encoding <encoding>

--raw-output-encoding <encoding>

--raw-encoding <encoding>

These options can be used to set the input/output encoding or both. The <encoding> parameter can either be signed or unsigned. The default encoding is signed.

--raw-channels <channels>

This can be used to set the number of channels. Note that the number of input channels and the number of output channels must always be the same. The watermarker has been designed and tested for stereo files, so the number of channels should really be 2. This is also the default.

--output-format rf64

Regular wav files are limited to 4GB in size. By using this option, audiowmark will write RF64 wave files, which do not have this size limit. This is not the default because not all programs might be able to read RF64 wave files.

--q, --quiet

Disable all information messages generated by audiomark.

--strict

This option will enable strict error checking, which may in some situations make audiowmark return an error, where it could continue.

Introduction for HLS

HLS Requirements

$ ./configure --with-ffmpeg

Preparing HLS segments

$ ffmpeg -i video.mp4 -f hls -master_pl_name replay.m3u8 -c:a aac -ab 192k \
  -var_stream_map "a:0,agroup:aud v:0,agroup:aud" \
  -hls_playlist_type vod -hls_list_size 0 -hls_time 10 vs%v/out.m3u8

$ audiowmark hls-prepare vs0 vs0prep out.m3u8 video.mp4
AAC Bitrate:  195641 (detected)
Segments:     18
Time:         2:53

Watermarking HLS segments

$ audiowmark hls-add vs0prep/out5.ts send5.ts 0123456789abcdef0011223344556677
Message:      0123456789abcdef0011223344556677
Strength:     10

Time:         0:15
Sample Rate:  44100
Channels:     2
Data Blocks:  0
AAC Bitrate:  195641

$ [...] | audiowmark hls-add - - 0123456789abcdef0011223344556677 | [...]
[...]

Stable releases are available from http://uplex.de/audiowmark

The steps to compile the source code are:

If you build from git (which doesn’t include configure), the first step is ./autogen.sh. In this case, you need to ensure that (besides the dependencies listed below) the autoconf-archive package is installed.

If you compile from source, audiowmark needs the following libraries:

• libfftw3

• libsndfile

• libgcrypt

• libzita-resampler

• libmpg123

If you want to build with HTTP Live Streaming support, see also HLS Requirements.

audiowmark needs the single prevision variant of fftw3.

If you are building fftw3 from source, use the --enable-float configure parameter to build it, e.g.::

or, when building from git

You should be able to execute audiowmark via Docker. Example that outputs the usage message: