Issues Building on Windows 10 and High CPU Usage with Detect-Speed

[coder121214]

I successfully got audiowmark working on my MacBook Air, but when I ran the detect-speed function, the CPU usage jumped to over 300%, and the call didn’t work as expected. Now, I’ve been trying to build it on Windows 10, but I haven’t been able to get it working at all. The build process throws errors throughout the make stage, and setting up libzita-resampler has been particularly difficult, which I suspect might be causing the get command not to work.

I’ve tried several troubleshooting steps, but I’m mainly looking to see if someone can confirm whether the detect-speed feature works as expected. Additionally, has anyone else encountered issues with the recent push when building on Windows?

Any help or suggestions would be greatly appreciated!

[tim-janik]

I am running audiowmark on Linux, so I cannot really help with Mac/Windows issues, you're best off filing those in a separate issue, listing the steps you have taken and the errors you encountered.

As for --detect-speed, Audiowmark tries to overcome a number of different attacks / distortion cases.
A lot of those cases (e.g. MP3 artefacts) are taken care of by the redundancy in the convolutional codes it uses and the --strength setting to increase robustness.
But, what the redundancy and increased strength doesn't help with are modifications in the replay speed. E.g. pitch shifting. It can however search for the watermark signal within a certain range (I forgot if that's 5% or 10%) of replay speed alterations. The search is fairly costly (think of it in terms of having to resample over and over to different speeds and starting the search all over), and can be more or less exhaustive. That's why there are the slow --detect-speed and the slower yet --detect-speed-patient detection modes. You probably only need to use those options, if you encounter a signal that you suspect has your watermark on it and you suspect slight to moderate speed alterations.

As outlined, the audio signal searches for a watermark signal at different speeds. Since those searches can be carried out mostly independent of each other, and since it is a quite computationally intensive process, Audiowmark uses a threadpool and distributes the work load across a number of threads, which the system usually distributes onto the available CPU cores, up to std::thread::hardware_concurrency. So a high load increase is to be expected while the search runs.

Just be reminded that --detect-speed is useful for pitch shifting. If you just struggle to get the watermark signal across lossy audio codecs like MP3/Vorbis, --detect-speed will not help. Increase the watermarking strength instead or test with a higher bitrate (64kbit/s should normally work) if lossy transfer is the problem.

[coder121214]

Thanks for the thorough response! It definitely helps me understand how the --detect-speed feature works and when it’s best to use it. I’ll focus more on adjusting the watermark strength for lossy codecs.

Just to confirm, does the --detect-speed call work as expected on your build? I’d really appreciate knowing before I dive deeper into it.

Thanks again!

Best,
Adam

[tim-janik]

Thanks for the thorough response! It definitely helps me understand how the --detect-speed feature works and when it’s best to use it. I’ll focus more on adjusting the watermark strength for lossy codecs.

Just to confirm, does the --detect-speed call work as expected on your build? I’d really appreciate knowing before I dive deeper into it.

If you are asking wether speed detection works at all, sure:

sox marked.wav o.wav speed 1.25
audiowmark get --detect-speed-patient o.wav
pattern   all 0123456789abcdef0123456789abcdef 1.404 0.026 SPEED

[coder121214]

It sounds like you used the speed detection feature to adjust for changes in the audio. Would this functionality still work if you took a watermarked audio file, altered its speed using an online tool, and then processed the downloaded file through the software? In other words, could the software still detect the watermark after the file has been modified externally?

[tim-janik]

Using sox is an external modification to the workings of Audiowmark.
The watermark is embedded in the audio signal, depending on the degree of distortion of your "online tool" it may or may not be recoverable from the resulting audio, also consider increasing strength.
Why don't you give it a try and report back here?