Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: WavPack 5.7.0 Release (Read 2436 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

WavPack 5.7.0 Release

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


Re: WavPack 5.7.0 Release

Reply #2
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.

Re: WavPack 5.7.0 Release

Reply #3
I wonder, given how FLAC builds differ in speed, ... @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?
Is troll-adiposity coming from feederism?
With 24bit music you can listen to silence much louder!

Re: WavPack 5.7.0 Release

Reply #4
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.

Re: WavPack 5.7.0 Release

Reply #5
Good development. A quick test about Multithread.
Code: [Select]
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.

500% ↑↑↑

Reply #6
Multithreading gains everywhere - even on the lower, I mean cooler end of the CPU scale8)


Re: WavPack 5.7.0 Release

Reply #7
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.