Compressed files are larger than uncompressed 2019-10-23 18:44:09 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.
Re: Compressed files are larger than uncompressed Reply #1 – 2019-10-23 23:50:45 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.
Re: Compressed files are larger than uncompressed Reply #2 – 2019-10-27 02:30:32 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.
Re: Compressed files are larger than uncompressed Reply #3 – 2019-10-27 04:48:16 Thanks! I specifically used a floating point sample is also because Wavpack supports it so I can't just use something else like flac.
Re: Compressed files are larger than uncompressed Reply #4 – 2019-10-27 17:49:27 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.