Wavpack Support

Wavpack has better compression and lower overhead than flac, is it possible we’ll see support for wavpack import/export? Thanks!

That’s fairly recent, although in my experience Wavpack typically encodes faster, decodes slower than flac. It’s probably a comparison of 44.1khz 16-bit files. When moving to 24-bit and up to 96khz/192khz (the samples I tend to use are 96khz 24-bit) Wavpack’s compression is revealed as far superior. I’d suggest trying to encode a test wav file, and compare. Tested this with Wavpack 4.50 and Flac 1.2.1b, using a 24-bit 96khz drum loop I recorded:

Wav: 18.6MB (19 584 736 bytes)
Flac: 8.60MB (9 018 163 bytes)
Wavpack: 4.28MB (4 497 956 bytes)

Using default settings for both, encoding at 96khz 24-bit.

Interestingly, while Renoise loads in the 24-bit 96khz wav file fine, it takes an amazing amount of time to load the flac sample.

Just bought renoise and it would be great if it could support WavPack :)
Are there any news on this?


If it’s encoding/decoding is faster than .flac, I’ll give a +1

Flac encodes better.
There is a common compression-ratio figure where WavPak and Flac compress equally well but WavPack is for sure faster.

Actually wavpack encodes faster with slightly better compression (with 16bit files).
As zeekay already said, when you are using higher bitdepth there is a major difference (for details: http://www.hydrogenaudio.org/forums/index…64933&st=0)) and this is my main interest.

Besides compression and speed efficency don’t forget about general tool and format support.

I don’t know how far spread or exotic wavepack is.
But almost every DAW I know supports FLAC.

A bit more efficiency wouldn’t justify lack of format support.

It’s the same as with ZIP files -> there are hundreds of better formats, but ZIP is
the best compromise.

In my experience so far, WavPack has shown superior compression ratios to FLAC, hands down. My unscientific observation is that it also encodes faster. But there is a different reason why I wish Renoise would support WavPack.

All samples recorded in Renoise’s sample editor default to 32-bit, which FLAC inherently cannot compress. WavPack can compress 32-bit float/int audio files, although I admit I have no idea what the compression ratio would look like. Either way, it’s a hassle to have to convert my new samples to 24-bit before saving them as .flac files to get any space-saving benefit, especially when I’m doing buckets of new samples at a time.

But just to be clear, while the official FLAC decoder reports an error and quits when processing a 32-bit FLAC file (say, made in Renoise), some other decoders will read it just fine.

Most free audio software that I use supports it, but outside of that I can’t say. And Reaper supports it, which is all I care about. :>

The Flac encoder in Renoise does support compressing 32 bit (for those thinking that Renoise embedded the official FLAC format), the adjustments have been specially added for the purpose and also the changes to this support has been submitted to the FLAC development team.
Whether they want to embrace the support is up to them.
So you don’t need to be afraid that samples in Renoise songfiles are converted to 16 in order to have them compressed as FLAC because they will not be converted.
Though, it might be that some third party FLAC decoders outside Renoise are unable to decompress 32-bit compressed FLAC files.

Wow! That’s a noble effort – thanks for clarifying that, vV.

But it’s the official flac.exe that won’t decode floating-point samples (32-bit ints should be ok). That’s the sad part… but of course, I’m ignorant to the mechanics of audio compression, and surely there’s important information that I don’t have or understand.

The problem is that the bit type of the sample in the FLAC header is only a 7-bit type which allows room for only a 15 different type definitions of bit-rates.
IMHO they made that a bit too restricting causing there be no room for other bit-types.
There is a “reserved” flag mode in that bit-key, but i have no idea what they use it for.
Let’s just say that one should never choose restricting bit-ranges for possibilities, you will strand in the future.