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.8.x is released (Read 8931 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

WavPack 5.8.x is released

WavPack 5.8.1 was released yesterday, containing various optimizations.

Changes:

Quote
added: if present, use multiple cores by default (cli programs only)
added: option --no-threads to force single-threading (cli programs)
fixed: noise issue in hybrid mode (low bitrate / high sample rate)
improved: all new DNS algorithm for better hybrid mode quality
improved: "extra" option with multithreading and hybrid modes
added: TSOC (Composer Sort) added to handled ID3v2 tags
added: --no-overwrite command-line option to wvunpack
fixed: handling of 24+ channels (CoolEdit / Audition)
fixed: encoding raw audio from pipes (Windows only)
fixed: handling of unpacked samples in WAV files
fixed: rare command-line option parsing issue
audiophile // flac & wavpack, mostly // using too many audio players

Re: WavPack 5.8.x is released

Reply #1 –
Nice one,  Thanks David.

Re: WavPack 5.8.x is released

Reply #2 –
Oh, that's only for Mac and BSDs. Windows binaries stay the same, 5.8.0
TAPE LOADING ERROR

Re: WavPack 5.8.x is released

Reply #3 –
They seem to be identical:

Quote
This dot release replaces 5.8.0 that was missing a couple CMake files in the tarball and the multicore detection did not compile on MacOS and other BSDs. Because the Windows executables were not affected I will not be updating them.
audiophile // flac & wavpack, mostly // using too many audio players

Re: WavPack 5.8.x is released

Reply #4 –
Quote from: tuxman on
They seem to be identical:

Code: [Select]
2a18fd0823fc6bb2736874d5dcad3d0c496858536c6e3fbf5411754328a59a78  wavpack-5.8.0-dll.zip  https://github.com/dbry/WavPack/releases/download/5.8.0/wavpack-5.8.0-dll.zip  2025-01-27T23:56:27+00:00
bbb29d1478dfaab80a6ea868deb575a82414c5d79cbec91cdc1044c358945168  wavpack-5.8.0-x64.zip  https://github.com/dbry/WavPack/releases/download/5.8.0/wavpack-5.8.0-x64.zip  2025-01-27T23:56:02+00:00
e78588e3f49a7b619bf1bc6cb86efd58094398614c707f82102b76c5c21d8cb6  wavpack-5.8.0-x86.zip  https://github.com/dbry/WavPack/releases/download/5.8.0/wavpack-5.8.0-x86.zip  2025-01-27T23:55:44+00:00
2a18fd0823fc6bb2736874d5dcad3d0c496858536c6e3fbf5411754328a59a78  wavpack-5.8.0-dll.zip  https://github.com/dbry/WavPack/releases/download/5.8.1/wavpack-5.8.0-dll.zip  2025-01-27T23:56:27+00:00
bbb29d1478dfaab80a6ea868deb575a82414c5d79cbec91cdc1044c358945168  wavpack-5.8.0-x64.zip  https://github.com/dbry/WavPack/releases/download/5.8.1/wavpack-5.8.0-x64.zip  2025-01-27T23:56:02+00:00
e78588e3f49a7b619bf1bc6cb86efd58094398614c707f82102b76c5c21d8cb6  wavpack-5.8.0-x86.zip  https://github.com/dbry/WavPack/releases/download/5.8.1/wavpack-5.8.0-x86.zip  2025-01-27T23:55:44+00:00

Re: WavPack 5.8.x is released

Reply #5 –
Sorry, that wasn't worded properly. By ‘identical’ I mean: 5.8.1 for macOS corresponds to 5.8.0 for Windows.
audiophile // flac & wavpack, mostly // using too many audio players

Re: WavPack 5.8.x is released

Reply #6 –
Developers of encoders that spawn one instance per thread, will have to be aware that they should use "--no-threads" if they upgrade. Let's see how that works out. I don't know how many applications do access the executable rather than the library.

(Myself I need to un-learn that "--no-overwrite" was only for encoding, as that is no longer true. But I never "learned" it, only got reminded by the error messages.)

Re: WavPack 5.8.x is released

Reply #7 –
I'm definitely not happy about such big behavior change. It means WavPack can't be safely upgraded in foobar2000's Free Encoder Pack as it will ruin multi file encoding performance. The converter parameters also can't be hardcoded to use new --no-threads option as it will error out and prevent old wavpack from working entirely.

Re: WavPack 5.8.x is released

Reply #8 –
It seems you can, by using the "WinXP" compiles.

@bryant , you write that those "are not recommended for recent versions of Windows for obvious reasons."; any there any other reasons to recommend against them than the loss of multi-threading functionality? Or could it be considered a "compatibility build" that can be used as drop-in replacement for both this and that use.

The WinXP build also knows about --threads and ignores it, so if I use it as drop-in replacement, it will compress, not breaking more compatibility than it has to:
warning: --threads not enabled, ignoring option!
Edit: One can get out Windows version information of course, but maybe the time cost of doing so when the user asks for --threads is too much? (Hm: Spawn one, call ver, see if it is to be ignored ...?)

Re: WavPack 5.8.x is released

Reply #9 –
Quote from: Case on
I'm definitely not happy about such big behavior change. It means WavPack can't be safely upgraded in foobar2000's Free Encoder Pack as it will ruin multi file encoding performance. The converter parameters also can't be hardcoded to use new --no-threads option as it will error out and prevent old wavpack from working entirely.
Hi Case. Yeah, I understand your concerns. However, I think that it’s not as bad as you think it might be, and there are a few simple solutions.

First, as @Porcus  mentions, I created an official “winXP” version (both 32-bit and 64-bit) that has all the threading stuff removed (that’s the only difference, built in Autotools with –disable-threads). I did this because XP doesn’t have the condition variables I use, and of course I have to make the multithreading stuff optional in the build because of other old OSes. You guys could just use that.

And to answer Porcus' question, I thought of checking the Windows version and it's probably possible, but the way it works now the executable won't even load because it tries to link to the condition variable handling code in the Windows DLL, even if it's not going to use them.

Alternatively, you could also add “--threads=1” to the options. That would work in this version and in 5.7.0. Obviously in 5.6.0 and before it would fail, but that’s probably becoming rare.

And even if you had to have this run with threading (or someone uses the official threaded version) I don’t think the performance hit would be that great. I only use a max of 4 worker threads in the “auto detect mode” and I have found that the performance hit of running that on a 1-core CPU is very small. Here are the results on Linux comparing the use of the "--no-threads" option with forcing the process to a single core (which I imagine is close to the situation of not having any available cores):

Code: [Select]
david@pop-os-hp15:~/Projects/WavPack$ time cli/wavpack -x3 goodnight.wav -o - > /dev/null

 WAVPACK  Hybrid Lossless Audio Compressor  linux-gnu Version 5.8.1
 Copyright (c) 1998 - 2025 David Bryant.  All Rights Reserved.

packed goodnight.wav in 6.54 secs (lossless, 44.39%)                                

real	0m6.558s
user	0m19.873s
sys	0m0.979s
david@pop-os-hp15:~/Projects/WavPack$ time cli/wavpack -x3 --no-threads goodnight.wav -o - > /dev/null

 WAVPACK  Hybrid Lossless Audio Compressor  linux-gnu Version 5.8.1
 Copyright (c) 1998 - 2025 David Bryant.  All Rights Reserved.

packed goodnight.wav in 17.25 secs (lossless, 44.39%)                                

real	0m17.267s
user	0m16.675s
sys	0m0.584s
david@pop-os-hp15:~/Projects/WavPack$ time taskset 0x1 cli/wavpack -x3 goodnight.wav -o - > /dev/null

 WAVPACK  Hybrid Lossless Audio Compressor  linux-gnu Version 5.8.1
 Copyright (c) 1998 - 2025 David Bryant.  All Rights Reserved.

packed goodnight.wav in 17.92 secs (lossless, 44.39%)                                

real	0m17.947s
user	0m17.085s
sys	0m0.853s

Now, a caveat with that is that in modes below -x3 I do more work in the multithreaded case to compensate for the lack of previous frame context, and that would be wasted in a sense (although it sometimes improves compression). But again, we’re not talking about that much (maybe 50% max) and if the performance becomes a problem then the user could simply choose a faster mode.

What do you think?

edit: I should add that I have been running this with Foobar2000 without issue (even the previous version adding "--threads"). However, because it's either a VM on a laptop or a very old dual-core machine, I have no way to make repeatable performance measurements.

edit: Another possibility, thanks to @Porcus , is simply renaming the executable you distribute to wavpack{--no-threads}.exe. But I think just using the WinXP version is cleaner.

Re: WavPack 5.8.x is released

Reply #10 –
So, suggestion: change no executables, only the text, take down the "not recommended" and instead recommend it for situations where multi-threading is unwanted, like if spawned by an application that manages threading by itself?

(And: if the application calls "wavpack.exe", the renaming trick won't help.)

Re: WavPack 5.8.x is released

Reply #11 –
Quote from: Porcus on
So, suggestion: change no executables, only the text, take down the "not recommended" and instead recommend it for situations where multi-threading is unwanted, like if spawned by an application that manages threading by itself?
Okay, good suggestion. Done.

Re: WavPack 5.8.x is released

Reply #12 –
I don't know how I missed that XP version retains the old behavior. Using that build is a perfect solution, especially as I don't want to drop XP support unless necessary. And letting foobar2000 handle threading offers a clear and measurable performance benefit.

PS: the Windows binary download links don't work on wavpack.com.

Re: WavPack 5.8.x is released

Reply #13 –
Quote from: Case on
I don't know how I missed that XP version retains the old behavior. Using that build is a perfect solution, especially as I don't want to drop XP support unless necessary. And letting foobar2000 handle threading offers a clear and measurable performance benefit.

PS: the Windows binary download links don't work on wavpack.com.
Oh, I thought Foobar2000 gave up on XP long ago, but I see now older versions are still available.

Thanks for the heads-up on the download links (it makes sense that they would change when I edited the release version).

I also updated the WinXP versions there from 5.6.0 (which was the last time I generated an XP version, although that time it was because I updated to a Visual Studio that would not target XP).

Re: WavPack 5.8.x is released

Reply #14 –
fb2k updated its "final" XP-compatible version 1.5.x to an "even more final" as late as last May, as per the news on https://www.foobar2000.org . And there are people who are happy about whatever they have that works, and for sudden want the Free Encoder Pack.
Which claims to support fb2k back to 1.1.14, even - and I'd bet it is a good thing to have only one to maintain. Maybe it isn't necessary to use the FLAC for MS-DOS build  :))

Quote from: Case on
I don't know how I missed that XP version retains the old behavior.
Some swiney snout highlighted the problem and not the solution ... Swiney snout's excuse is that the text did emphasize that it was not recommended, I kinda didn't think over it as a "solution" to anything but some emergency situation - and besides, HA had a similar discussion for flac.
Anyway, good that the WinXP-friendly version has everything else.

Re: WavPack 5.8.x is released

Reply #15 –
Thanks, David @bryant‍ , on such enduring, unwavering work.
• Listen to the music, not the media it's on
• The older, the 'lossier'

Re: WavPack 5.8.x is released

Reply #17 –
Hello David, 

Are static shaping settings like s1 also changed like DNS, or same as previous versions ?

Re: WavPack 5.8.x is released

Reply #18 –
Quote from: shadowking on
Hello David, 

Are static shaping settings like s1 also changed like DNS, or same as previous versions ?
Hi Shadowking,

The static shaping option has not changed and specifying any value will disable the new DNS, just like before.

However, there were changes (hopefully improvements) in the higher "extra" levels with hybrid/lossy mode, so the results will not be identical to the previous version.

Re: WavPack 5.8.x is released

Reply #19 –
Hi David,
many thanks for improving Wavpack.
All artifacts noticed last spring are gone with this version like with the experimental version you released few months ago.
I don't have time to test the encoder but I'm already using it for all new encoding.

I only made a very basic bitrate comparison between 5.70 and 5.80 on two albums—which is totally meaningless but I don't have anything else to offer now. Here are the results:

  • On one 24/96 album, 5.80 hybrid was more efficient (947 MB vs 949 MB with -c4hx6) but the lossy part was slightly bigger (320 vs 317 MB). Lossy bitrate: 806 kbps (5.80) vs 801 kbps (5.70).
  • On an extremely quiet and noise-free piano music, with -c4.5hx6: 5.80 was not as efficient bitrate-wise: 148 MB (144 MB + 4.01 MB correction) vs 140 MB (138 MB + 1.34 MB correction). Bitrate is ~270 kbps for both lossless and lossy version.
Funny fact, two lossy files are already bit-to-bit identical to lossless at this setting with version 5.70 (but none with 5.80 at the same setting).

Speed is good, similar to previous version (haven't check precisely).
Noise level for lossy is objectively lower with new version on the few files I tried.

Thanks!
Wavpack Hybrid: one encoder for all scenarios
WavPack -c4.5hx6 (44100Hz & 48000Hz) ≈ 390 kbps + correction file
WavPack -c4hx6 (96000Hz) ≈ 800 kbps + correction file
WavPack -h (SACD & DSD) ≈ 2400 kbps at 2.8224 MHz

Re: WavPack 5.8.x is released

Reply #20 –
Without correction file or when not using dns, lossy bitrate is lowered by 3%

Re: WavPack 5.8.x is released

Reply #21 –
@guruboolez @shadowking Thanks to both of you for your testing!

In my own testing I have seen the compression in hybrid lossless (using the new DNS) drop by about 1% (based on the original size) with 5.8 compared to 5.7. The reason for this is the new DNS tends to react faster and sometimes generates very small frames, which hurts compression (and specifically the lossy bitrate). Also, the more aggressive noise-shaping causes the noise values displayed with the -n option to get a little worse (usually less than a dB).

I don’t like this, obviously, but my assumption is that there is overall improved subjective quality. I have specific samples that sound better, including Guru’s original samples that resulted in the very obvious noise at low bitrates.

At some point I may try different limits for how short frames can get with the new DNS, but for now I’m happy that quality and safety has improved.