https://github.com/dbry/WavPack/releases/tag/5.7.0
---------------------------------
Release 5.7.0 - February 29, 2024
---------------------------------
WavPack Library Source Code - 5.7.0
wavpack.exe (command-line encoder) - 5.7.0
wvunpack.exe (command-line decoder) - 5.7.0
wvgain.exe (command-line ReplayGain scanner) - 5.7.0
wvtag.exe (command-line tagging utility) - 5.7.0
cool_wv4.flt (Cool Edit / Audition filter) - 4.2
----------------------------------------------------
added: multithreaded encoding and decoding to libwavpack (optional)
added: option to specify multithreading in CLI programs (--threads)
added: multithreading support to Cool Edit filter (always enabled)
added: support for ID3v2.4 when importing tags (--import-id3)
added: optional bitrate specification to wavpack -c option
added: Windows native threads in wvtest, builds with MSVC
added: recognize WAV files with new fourcc of 'BW64'
For more changes see https://github.com/dbry/WavPack/blob/master/NEWS
Now it is also on https://www.wavpack.com/index.html and ready to be HomeBrew'ed: https://formulae.brew.sh/formula/wavpack
I wonder, given how FLAC builds differ in speed (https://hydrogenaud.io/index.php/topic,123025.msg1029768.html#msg1029768), ...
@Wombat ,
@john33 , is it sufficiently easy to build with different compilers?
Ah, I had just about drafted a post. Oh well... :)
The only thing I'd like to add is many thanks to the HA community for the continued encouragement and specifically to
@bennetng for the idea on improving compression of 32-integer files and
@Porcus for ideas on just about everything!
As I mention of the GitHub page I switched to MinGW builds because they were consistently faster than MSVC. However, this was only on the order of 10% or so, and on the very heavy encoding modes (-x4-6) there was essentially no improvement. And this makes sense because that's overwhelmingly the invariant hand-coded MMX. So I imagine that there will be differences between compilers, but probably not on the scale seen with FLAC.
I wonder, given how FLAC builds differ in speed (https://hydrogenaud.io/index.php/topic,123025.msg1029768.html#msg1029768), ... @Wombat , @john33 , is it sufficiently easy to build with different compilers?
I can't guarantee anything for these binaries because it is my first compile for WavPack.
I simply used the additional flags for the gcc compiller i use for flac.
For flac some recommended additional flags did nothing and i left them out so for WavPack there may be better flags.
It is an AVX2 build, gcc 13.2.0 and not really faster on my first simple test.
When bryant dislikes the idea of offering unofficial builds the admins shall delete this, please.
Besides this i fear running out of attachement space. Where can i check this?
wavpack.com should be updated in a way that all sub-pages use the same font size, now the manual section alone has a different font size.
Good development. A quick test about Multithread.
AMD Ryzen 3700x (8 core, 16 thread)
Single Part Wav: 2,577,542,764 bytes
WAVPACK Normal Thread-1: 34.84 s, 30.45 s, 1,617,702,120 bytes // wavpack.exe --threads=1 input output
WAVPACK Normal Thread-12: 9.22 s, 5.88 s, 1,617,400,684 bytes // wavpack.exe --threads=12 input output
WAVPACK Fast Thread-1: 29.01 s, 26.29 s, 1,652,567,206 bytes // wavpack.exe --threads=1 -f input output
WAVPACK Fast Thread-12: 7.74 s, 5.55 s, 1,652,389,896 bytes // wavpack.exe --threads=12 -f input output
MOD edit: Data not related to WavPack removed. Topic is announcing a new version of WavPack. This is not a codec comparison thread.
Multithreading gains everywhere - even on the lower, I mean cooler end of the CPU scale (https://cryptpad.fr/sheet/#/2/sheet/view/ifQttm-776+BWzdAZ8cTUuSCpaB88QBwyJoxJpKF7N0/embed/). 8)
As I mention of the GitHub page I switched to MinGW builds because they were consistently faster than MSVC. However, this was only on the order of 10% or so, and on the very heavy encoding modes (-x4-6) there was essentially no improvement. And this makes sense because that's overwhelmingly the invariant hand-coded MMX. So I imagine that there will be differences between compilers, but probably not on the scale seen with FLAC.
5.7.0 is faster than 5.5.0 here as well. Maybe not a full ten percent.
Very small speed differences between builds. The official build does better on the higher -x settings, but not much more than a percent. With -x1 and with no -x at all, the Wombat build may be just as much faster, at most.
A belated yay for David and a great new WavPack release!