<li>--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.
<li>--detect-speed ist langsam und benötigt mehr RAM, daher ist es nicht die Standardeinstellung. Es unterstützt Multithreading.
<li>--detect-speed-patient ist noch effektiver, erfordert aber höheren Ressourcenverbrauch. Wenn Letzterer keine Rolle spielt, ist dies die bevorzugte Methode.
<p>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.</p>
<p>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.</p>
<pre>
audiowark gen-key osamc-music-distributor.key # Speichert den Schlüssel in einer Datei
<p>"Worst case": Eine verschlüsselte MP3-Version wird über Handy-Lautsprecher abgespielt und mit einem internen Laptopmikrofon aufgenommen.</p>
<p>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...</p>
<li>Sehr kurze Lieder, weniger als 10 Sekunden. Eventuell den --short Modus verwenden, siehe README.
<li>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.
<p>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.</p>
<p>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.</p>
<p>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)?</p>
