It is a test signal but I think I should report my findings anyway. Apart from "Extra High", all compressed files are larger than uncompressed.
Lossless compression of floating point isn't particularly easy, and requires the additional processing feature turned on to produce a smaller file. At least WavPack supports floating point, unlike most lossless codecs.
Thanks for the sample; I will add it to my test corpus!
There are a few things going on with this sample. The first is that because the right channel is silent, the default mode of joint stereo really hurts the compression, so just adding -j0 improves things a lot (and with no slower performance). And, of course, since any -x mode does a joint-stereo check, that also fixes the problem (although it hurts performance some).
The right channel is a pure 3 kHz sine and the compression there is greatly helped with the higher -x modes (4-6).
More generally, I decided early on to not have a special case check for inflation (negative compression) where I would switch to a “verbatim” mode with minimal overhead. With integer PCM the maximum inflation is only a few percent and it just didn't seem worth the extra complexity. In hindsight it would have been nice for 32-bit float data because the maximum inflation is higher (as you see here, and I have seen over 20% for pathological cases).
BTW, I also noticed that the maximum inflation can be high with DSD audio, and so I did implement a “verbatim” mode for that.
Thanks! I specifically used a floating point sample is also because Wavpack supports it so I can't just use something else like flac.
During my sojourn into float16 audio I seem to remember that there was a "store floats as integers" option, possibly undocumented, in WavPack - again from memory it worked well with fp16.
I may need to revisit this now that bfloat16 is coming - effectively a "shortened" float32, losing 16 mantissa bits.