Audiowmark

Falls du über eine Suchmaschine hierhergekommen bist: Dieses Dokument dient nur als Begleitmaterial und Zusammenfassung eines mündlichen Vortrags

Informationen und Links

Kommandozeilen-Software von Stefan Westerfeld, entwickelt zum Einbetten von Audio-Wasserzeichen in die Audiodaten einer Musikdatei. Eine 128-Bit-Nachricht wird fast unhörbar und direkt in der Wellenform gespeichert und kann auch wieder ausgelesen werden. Zudem besteht die Möglichkeit, sie geheim zu verschlüsseln. Der Prozess ist unabhängig vom Dateiformat, der Kompression und der Wiedergabeart, also Datei, Streaming usw. Zum Auslesen der Nachricht ist die Originaldatei nicht erforderlich.

"Ticking all the boxes" für Open-Source-Software: GPL, Verschlüsselungsmethode ist bekannt und einsehbar, basiert nur auf einem privaten Schlüssel (oder unverschlüsselt).

Hier geht es nur um die praktische Anwendung, nicht um die technischen Hintergründe.

Die Einsatzmöglichkeiten werden weiter unten erläutert, aber vorab der Hauptzweck: primär DRM und Authentifizierung. Man kann individuelle Informationen (z.B. Kundennummern) in den Audiodaten selbst speichern, ohne dass sie erkennbar und entfernbar sind, so zumindest das implizite Versprechen des Autors.

Nicht in diesem Vortrag

Es gibt auch 'videowmark', ein ähnliches Tool für Videos, das hier jedoch nicht behandelt wird.

128-Bit-String – 32 Zeichen in Hexadezimaler Form

Woher bekommt man diesen?

Als Hash. Die ersten 128 Bits eines SHA-256-Hashes (Kurze Frage: Wissen alle, was ein Hash ist? Wissen alle, was Hex 0-9A-F bedeutet?)

echo -n "OSAMC:BlackStorm:Download312" | sha256sum | head -c 32
b751e47bb131d84e6b67a3348c781d43
# head -c 32, weil es Hex ist: ein Hexwert ist 4 Bit. Also 128 Bit / 4 Bit = 32 Zeichen
# Audiowmark empfiehlt eine Datenbank anzulegen, da man Hashwerte nicht zurückentwickeln kann

Oder 16 ASCII-Zeichen in Hexadezimaler Schreibweise:

echo -n "osamc:blkstm:312" | xxd -p -u
6F73616D633A626C6B73746D3A333132
# Rückgängig machen: echo -n "6F73616D633A626C6B73746D3A333132" | xxd -p -r

ine UUID, die zufälligerweise ebenfalls 128 Bit lang ist.

uuidgen | tr -d '-'
# 76fc5abe80f840729375fc4dc15e604d

Oder 32 Zeichen, die zufällig alle Hexwerte 0-9A-F sind, aber bereits semantisch lesbar:

affe2222fefe1111affe2222fefe1111

Um einen ausgelesenen String schnell mit dem eigenen zu vergleichen:

[ "affe2222fefe1111affe2222fefe1111" = "affe2222fefe1111affe2222fefe1111" ]; echo $?   # Ergebnis 0 bedeutet, dass es der gleiche String ist.

Beispiel 1: Unverschlüsselt in einer WAV-Datei

Das Hinzufügen und Auslesen eines Wasserzeichens in einer unverschlüsselten WAV-Datei:

audiowmark add blackstorm.wav wm-blackstorm.wav b751e47bb131d84e6b67a3348c781d43

audiowmark get blackstorm.wav
# Leer

audiowmark get wm-blackstorm.wav

Der Befehl "get" extrahiert die Nachricht aus der Audiodatei. Das Auffinden einer Nachricht, obwohl keine vorhanden ist (oder eine falsche Nachricht), ist möglich, muss aber zu Ihrer privaten, geheimen Datenbank passen. Laut den Entwicklern ist dies selten genug, um statistisch vernachlässigbar zu sein.

--detect-speed hilft gegen Konvertierungsfehler (z.B. digital-analog-digital-Kette mit Geschwindigkeitsänderungen). Laut Handbuch kann dies auch beabsichtigt sein, um das Wasserzeichen zu verschleiern.
--detect-speed ist langsam und benötigt mehr RAM, daher ist es nicht die Standardeinstellung. Es unterstützt Multithreading.
--detect-speed-patient ist noch effektiver, erfordert aber höheren Ressourcenverbrauch. Wenn Letzterer keine Rolle spielt, ist dies die bevorzugte Methode.

audiowmark get --detect-speed-patient wm-blackstorm.wav

Es werden mehrere Nachrichten zurückgegeben, als Redundanz gegen Korruption und Kompression. Das dritte Feld ist der "Sync Score", je höher, desto besser. Das vierte Feld ist "Decoding Error", niedriger ist besser. Danach folgt der Blocktyp. Allein A ist in Ordnung, AB ist besser.

Am Ende erscheint ein "All" als Zusammenfassung, die man mit einem anderen Programm verarbeiten kann, z.B. in eine Datenbank einpflegen.

Beispiel 2: Verschlüsselung

Um zu verhindern, dass jeder mit Audiowmark die Nachricht auslesen kann bzw. um zu verhindern, dass festgestellt werden kann, ob ein Wasserzeichen vorhanden ist, wird eine interne Verschlüsselungsmethode bereitgestellt. Die Sicherheit dieser Methode wurde nicht überprüft.

audiowark gen-key osamc-music-distributor.key  # Speichert den Schlüssel in einer Datei
# Schlüssel 88913063e57c946b37bf6ea8ce842d32

audiowmark add --key osamc-music-distributor.key blackstorm.wav wmk-blackstorm.wav b751e47bb131d84e6b67a3348c781d43
audiowark get --detect-speed-patient wmk-blackstorm.wav
# Leer
audiowmark get --detect-speed-patient --key osamc-music-distributor.key wmk-blackstorm.wav

Beispiel 3: Kompression

Das Wasserzeichen bleibt auch nach der Kompression der Audiodatei erhalten:

opusenc wmk-blackstorm.wav wmk-blackstorm.opus
sox wmk-blackstorm.wav wmk-blackstorm.mp3

audiowmark get --detect-speed-patient --key osamc-music-distributor.key wmk-blackstorm.mp3
audiowmark get --detect-speed-patient --key osamc-music-distributor.key wmk-blackstorm.opus

Beispiel 4: Analog als Stream mit Pipes

"Worst case": Eine verschlüsselte MP3-Version wird über Handy-Lautsprecher abgespielt und mit einem internen Laptopmikrofon aufgenommen.

Eigentlich war geplant, dies mit einem selbstgebauten Stream zu tun, aber es gab Probleme mit den Eingabeoptionen (--input-format raw). Jack_capture sollte funktionieren, aber es gab Probleme mit meinem Pipewire-Setup. Also wurde Audacity verwendet...

Da es sich um eine analoge Übertragung handelt, wird --detect-speed verwendet.

Weitere Experiment-Ideen

Sehr kurze Lieder, weniger als 10 Sekunden. Eventuell den --short Modus verwenden, siehe README.
Die Musik in einem YouTube-Video einbetten und versuchen, sie daraus wieder herauszuhören. Eventuell den Stream mit einem virtuellen Systemmikrofon (JACK/Pipewire) abhören, um das Audio nicht herunterladen zu müssen.

Die entscheidende Frage

Ist das Wasserzeichen hörbar bzw. beeinträchtigt es die Audioqualität?

Hier können nur subjektive Eindrücke eine Antwort geben. Die README behauptet, dass die Qualität nicht beeinträchtigt wird, aber das ist nicht sicher. In diesem Beispielstück war zumindest nichts direkt hörbar. Es könnte jedoch sinnvoll sein, dies an einer reinen Sinuswelle zu testen.

Es ist definitiv möglich, die Musikqualität zu verschlechtern. So gibt es z.B. einen --strength-Flag, der mit Werten über 10 (Standard) zu schlechterer Qualität führt. Je höher die "strength", desto robuster gegen Audio-Kompression. 10 reicht für 128 kbit/s MP3. Für das Setzen und Auslesen der Nachricht muss derselbe strength-Wert verwendet werden, dieser sollte also notiert werden.

Einsatzmöglichkeiten

Frage ans Publikum: Wofür könnte dies nützlich sein, abgesehen von einem technischen Kuriosum? Gibt es Anforderungen, die nicht besser durch ein explizites paralleles Signal abgedeckt werden könnten (siehe Metadaten und Verkehrsinfo für Autoradios)?

Gutartiger DRM: Urheberrechtsnachweis, um sein Copyleft durchzusetzen.
Bösartiger DRM: Musikplayer verweigert das Abspielen, falls die Datei nicht korrekt signiert ist. Anwalt wird automatisch informiert.
Automatisierung: "Ihr Download wird vorbereitet" und dann wird die Kundennummer in die Audiodatei eingebettet.
Novelty: "Limitierte, signierte digitale Auflage mit Seriennummer."
Patreon-Reward: Dein Name in der Musik als Audiowmark!

Sollte man es also verwenden oder nicht? Hier sind Pro und Contra...

Experimente:

In ein Video einbetten und auf youtube hochladen. Dann das ganze mit youtube-dl runterladen und schauen.
Über Lautsprecher abspielen und sich das anhören: Raum und/oder Handy-Lautsprecher und Laptop-Mikrofon