Why isn't WavPack more popular?

[Mnyb]

And even more compression is not needed , it would be single digit percent better , why with today's storage.

Flac can do multichannel but not DSD , but DSD is useless anyway just convert to multichannel pcm and then pack as flac .

Here i dont know how work intensive is wavpack to uncompress ? Flac is made so that the compression is the most computer intensive part , uncompress for playback demands less resources ?

 

[Mnyb]

Embedded hardware support is great for flac , most streamers and whatnots can do it ?

 

[ZolaIII]

30 to 50% bandwidth saving (CD to higher quality) for offering perceptual same quality (hybrid lossy high quality WavPack vs flac) is a lot especially if you are a provider.

 

[ThatM1key]

There is a difference between the OGG media container and Vorbis the audio codec.

I know there is.

And even more compression is not needed , it would be single digit percent better , why with today's storage.

Flac can do multichannel but not DSD , but DSD is useless anyway just convert to multichannel pcm and then pack as flac .

Here i dont know how work intensive is wavpack to uncompress ? Flac is made so that the compression is the most computer intensive part , uncompress for playback demands less resources ?

(2L) Hoff: Innocence DSD 64 Stereo:
DSF: 200MB
WV DSD: 88MB
FLAC 24/44.1: 41MB

(2L) Hoff: Innocence DSD 64 Multi:
DSF: 650MB
WV DSD: 262MB
FLAC 24/44.1: 110MB

I guess you could but is it lossy technically when you go from DSD to PCM. But then again most DSD is DXD

 

[AnalogSteph]

Originally because WavPack was a symmetric codec that is it was as hard to decode as to encode.

Where as FLAC has always been asymmetric that is to say it's very computationally easy to decode but hard to encode.

WavPack now has an asymmetric mode but I'm not sure how it compares.

I just did some some comparisons using the latest Foobar2000 encoder pack from 2022-02-02 (didn't spot the asymmetric option though, maybe I'd have to update Foobar 1.5.7 as well). CPU is an i7-11700 (x2 tau boost, PL1/2 65 / 224 W, actual turbo clock seen 4.7 GHz).
FLAC 1.3.4 -5: encode ~460x, decode 1375x
WavPack 5.4.0 normal: encode ~290x, decode 373x
WavPack 5.4.0 fast: encode ~335x, decode 504x
File sizes for 48:52 worth of 44.1 kHz, 24 bit stereo audio were pretty much identical for FLAC -5 vs. WavPack normal, 561 MB in this case. Source audio was all in one file, so just one encoding thread, same on the decoding side.

This seems to align with official published results (with my machine being about twice as fast as a C2Q T9600 for this particular workload), except that FLAC decoding is even faster. It seems hard to make the case for WavPack if FLAC is faster even on the encoding side, unless you absolutely need on of its niche advantages.

Incidentally computational requirements is why Apple created ALAC they needed something relatively easy to encode for a fair compression ratio because they were doing it in real-time for Airplay 1 on low end hardware. None of the existing formats met their requirements so they invented a new one.

Interesting. Clearly much different objectives than FLAC, where the rationale was only having to encode once on fast hardware and saving computing power decoding on what might be mobile devices.

 

[bennetng]

WavPack has been asymmetric for a long time, including version 4.x which did not support DSD.

Monkey's Audio for example, has far slower decoding speed than WavPack, but was pretty popular in the 2000s.

Actually, I've been using WavPack for a long time, only jumped into flac due to flacCL, encoding speed was stupidly fast even on a Radeon HD5750 purchased in 2010. The same CPU (i3-540) in the same PC at the time was much slower in comparison.

For the lossy segment, Opus decodes much slower than for example AAC too.

Anyway, people should not use a format's popularity to determine it is good or not, otherwise things like JPEG should have been dead for a long time.

A WavPack related thread that some may find interesting:

32-bit floating-point (WAV) files "in the wild"

32-bit floating-point (WAV) files "in the wild"

hydrogenaud.io

 

[ZolaIII]

@bennetng interesting enough as it's old thread from time when FP rounding back caused integer overflows (fixed in IEE 754 revision later) but it also nedded some fixing on hardware FPU side. It whose and I don't know if it's still a case on ARM that it use integer written implementation (as originally it used it from the beginning). Unfortunately official public documentation is outdated and bad.
Anyway neither implementation nor computing requirement is a problem.

 

[mansr]

Incidentally computational requirements is why Apple created ALAC they needed something relatively easy to encode for a fair compression ratio because they were doing it in real-time for Airplay 1 on low end hardware. None of the existing formats met their requirements so they invented a new one.

Incidentally, ALAC is nearly identical to FLAC. The bitstream format is a little different, as are some mostly arbitrary constants, but the decoding process is essentially the same for both. Since FLAC predates ALAC by several years, they could easily have used that, but then anyone would have been able to play the files without using Apple hardware/software.

 

[threni]

Embedded hardware support is great for flac , most streamers and whatnots can do it ?

Yep. It was in Android from the start. I have no use for huge single files + cue as one of my use cases is copying files between devices, deleting them when I've heard them etc. Making compilations etc. If I rip a CD to a single file + cue I have a script to split them into the individual files. Unlike some formats, FLAC can handle this gaplessly (well, unless you're using something lame like VLC).
And I remember APE lol! The Opera of the audio world - why pay for something that's not better than the free alternatives? Converting APE to FLAC - another script that's handy to have laying around!

 

[bennetng]

WavPack is updated to version 5.5.0.

One moment, please...

One interesting thing is the website's introductory paragraph was modified according to some recommendations from a FLAC developer, because FLAC is not always possible to do this:

In the default lossless mode WavPack acts just like a 7-Zip compressor for audio files, including the preservation of all the headers and metadata, so the restored files are identical to the original.

The origin of the recommendations:

WavPack 5.5.0 Release Candidate

WavPack 5.5.0 Release Candidate

hydrogenaud.io