Hi!
Am 30.03.22 um 07:14 schrieb Irina R:
> I am new to audio. How do people pirate audio these days? What's the
> main use case for which this software works best? I want to pitch it to
> people internally, but I am vague at this point.
I can't really answer how people pirate generally pirate audio these
days. But what I mainly tested during development is that the watermark
survives lossy compression to mp3/ogg with at least 128 kbit/s at
strength 10 (higher strength to handle lower bitrates/quality).
So the use case is something like: you send a watermarked mp3 to a user.
The user either redistributes is as-is (then we should be able to detect
the watermark). Or the user uses lossy compression to mp3/ogg and
redistributes the result (then we should be able to detect the watermark).
It will also work if the user only redistributes a shorter clip instead
of the whole track, where higher strength makes it possible to detect
the watermark on shorter clips.
> Is the watermark meant to be durable over play by speakers and then
> recording from a microphone? I had it work before, and now it isn't
> working even with strength 100. What are the optimal conditions under
> which it works?
It is nothing I tested during the initial development, but it seems
under good conditions, it will work. Of course it will depend on many
factors, such as strength, style of music, playback soundcard, speakers,
microphone, recording soundcard and the room used to do the recording.
I did a test using strength 20, playback with UA-25EX external audio
interface, high quality speakers and my Samsung Galaxy A50 to do the
recording, which I placed on the table in front of the speakers,
recorded as 160 kbit/s mp3 via app.
Of course this results in a mono only file, and if I side-by-side
compare original and recorded files, the recorded one sounds somewhat
crappy (far worse than what for instance 160kbit/s mp3 compression alone
would do).
On the original file, I get
$ audiowmark get test.wav
pattern 0:05 f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0 2.750 0.017 A
pattern 0:57 f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0 2.839 0.034 B
pattern 0:57 f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0 2.794 0.026 AB
pattern 1:49 f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0 2.856 0.025 A
pattern 2:40 f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0 2.721 0.026 B
pattern 2:40 f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0 2.788 0.026 AB
pattern all f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0 2.791 0.015
The watermark on the recorded file can be detected:
$ audiowmark get recorded.mp3
pattern 0:07 f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0 1.187 0.090 A
pattern 0:59 f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0 1.498 0.130 B
pattern 0:59 f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0 1.343 0.113 AB
pattern 1:51 f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0 1.531 0.109 A
pattern 2:42 f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0 1.407 0.107 B
pattern 2:42 f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0 1.469 0.108 AB
pattern all f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0 1.406 0.076
We can see that both, the sync bit score and the error correction values
are a lot worse than on the original file. Still, it doesn't look too
bad, with sync bits of about 1.4 (should be more than 0.7) and error
correction scores of about 0.11 (should be less than about 0.350).
Note that if we would pass "--strength 20" to "audiowmark get" to
normalize the sync bit to the strength the sync bits would be quite low,
so it seems better to not do that for the analog case. Omitting strength
in this way makes "audiowmark get" more permissive for the high strength
case, and is generally safe to do.
If you try to reproduce this and things don't work for you even for high
strength, one thing you could try is using the "--detect-speed" option
for "audiowmark get". This could help if the sample rate of the playback
device and recording device is a bit different. For me it doesn't
improve anything though.
Cu... Stefan
--
Stefan Westerfeld,
http://space.twc.de/~stefan