FFmpeg authors have removed the libwavpack encoder, in favor of their internal Wavpack encoder.
[libwavpack encoder] supports less sample formats than the native encoder, is less efficient
than the native encoder and is also slower and pretty much remains untested.
libwavpack also isn't being fuzzed, which given that we plug the parameters
without any sanitizing them looks concerning.
I have not verified their claims, but I am skeptical given their past track record of promoting their internal encoders even when they are clearly inferior.
Does anybody know :
- If their encoder give the same bit exact output than libwavpack ?
- Is it also faster for single thread performance ? I remember for decoding, it was faster by aggressively multi threading (https://hydrogenaud.io/index.php?topic=114245.msg941148#msg941148)
When I first saw this mentioned on their mailing list I did some investigation because what they were saying really didn't make sense. Like how could it be faster and more flexible than the reference encoder, especially when it doesn't have the ASM optimizations? And unlike some of their encoders (and the WavPack decoder) it is not a rewrite; it's basically a copy of the libwavpack encoder with reformatting and a little refactoring.
A quick test showed that their native encoder is slower than libwavpack as used by the WavPack command-line encoder, and it doesn't do any multithreading or anything to run faster. That was as expected.
However, when I looked closer at their libwavpack interface code, I understand what they're talking about. It only uses the libwavpack encoder at 32-bit integer audio, regardless of the source format! That causes libwavpack to go through all kinds of hoops scanning the audio, which will slow it down significantly. And worse, the resulting WavPack audio files will be reported as 32-bit (I didn't verify that but it didn't seem like anything else could happen from the code I saw). And it didn't look like the multichannel configuration was done correctly either. Obviously I now agree with them that's there's no reason to use that configuration.
I considered offering to help them to improve that code so that libwavpack would be a viable alternative, but life is too short to spend time trying to submit patches to FFmpeg unless absolutely necessary, and their encoder works fine (since it's basically a copy of my code). It won't generate bit-identical output for several reasons, but the most obvious is that it doesn't have any of the WavPack 5.0 additions, like block checksums. But the decoded audio will be identical.
That's unfortunate, as FFmpeg is ubiquitous and having a suboptimal encoder going around misrepresents this brilliant CODEC.
FFmpeg wavpack Encoder is not suboptimal in any way.
The wrapper encoder was suboptimal in any sense.
Wasn't it mostly down to the libwavpack frontend in FFmpeg being limited to always encoding 32 bit samples?