This will probably be the final release for version 4, and I believe that it is probably the most stable WavPack to date.
Because of some of the fixes here, I recommend everyone using WavPack should eventually migrate to this version.
- Unicode suppport on Windows console
- new option --pre-quantize to truncate high-resolution files to a reasonable depth (e.g., 20 bits) for better compression
(this was created by the author of Reaper to save space on large recording projects) - fixed several "fuzz test" failures for multichannel files reported on GitHub
- fixed LargeAddressAware problem reported on HA (https://hydrogenaud.io/index.php/topic,110241.0.html)
- fixed Debian bug #793320 (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=793320) (executable stack)
- added a seeking test to the wvtest suite
- faster X86 and X64 assembly code for mono packing
- repack blocks after possible arithmetic overflows
- several smaller fixes and portability improvements
I have built and tested the source on the following platforms:
- MS Visual Studio 2008 (64-bit Windows 7, 32-bit Windows XP)
- Cygwin on Windows (32-bit and 64-bit)
- Mac (OS X Yosemite 10.10.5, 32-bit and 64-bit arch)
- Linux Mint Qiana (32-bit and 64-bit)
- FreeBSD 10.1 (32-bit and 64-bit, requires Clang 3.5+)
- Raspbian 4.1.17
Many thanks to everyone at HA who has reported bugs, contributed builds, made suggestions, and just
generally supported this project over the years...your efforts are greatly appreciated!
Linux Distribution (http://www.wavpack.com/wavpack-4.80.0-rc.tar.bz2)
Windows 32-bit binaries (http://www.wavpack.com/wavpack-4.80.0-rc-x86.zip)
Windows 64-bit binaries (http://www.wavpack.com/wavpack-4.80.0-rc-x64.zip)
Mac OS X i386 & X86_64 fat binaries (http://www.wavpack.com/wavpack-4.80.0-rc-mac.zip)
Works well here on Linux x64.
Thanks for keeping WavPack alive.
Thanks for testing it out and giving feedback! I will certainly continue to develop and support WavPack as long as people are using it, and I hope to get started on Wavpack 5.0 very soon.
Anyone else have any luck with this...good or bad?
I tried to build WavPack-master with MSVC2015, and it complains about unused variable:
..\cli\win32_unicode_support.c(156): warning C4101: 'actual' : unreferenced local variable
Other than that, no problems. Compiled executables work fine.
I ran the win64 binary through some basic tests on a Windows 10 machine -- seems perfectly stable; performance is on par with the current stable version. The compressed output matches between versions, which I would expect based upon my settings and input file. Admittedly, I hadn't ever hit any of the bugs being fixed in this release, so I can't speak to those.
I tried to build WavPack-master with MSVC2015, and it complains about unused variable:
..\cli\win32_unicode_support.c(156): warning C4101: 'actual' : unreferenced local variable
Other than that, no problems. Compiled executables work fine.
Thanks! Fixed in master...
I ran the win64 binary through some basic tests on a Windows 10 machine -- seems perfectly stable; performance is on par with the current stable version. The compressed output matches between versions, which I would expect based upon my settings and input file. Admittedly, I hadn't ever hit any of the bugs being fixed in this release, so I can't speak to those.
Thanks for the testing! All the “bugs” that were fixed were things that I suspect have never been encountered in the wild (well, except for the LargeAddressAware issue). They were either things that were uncovered during fuzz testing (which are important to fix because they are potential security vulnerabilities) or arithmetic overflows that could only be triggered by pathological audio crafted to do so. The danger of these kinds of fixes is that I could always unintentionally break something else, which is why testing like what you've done (just your normal workflow) is so useful.
Works fine with my settings on manjaro-xfce 15.12 (64 bit) and Windows 8.1 (64 bit) both, as usual many thanks David, still the most versatile lossless codec around.
According to http://www.wavpack.com/changelog.txt 4.80.0 was released at March 28, 2016:
-------------------------------
Release 4.80.0 - March 28, 2016
-------------------------------
WavPack Library Source Code - 4.80.0
wavpack.exe (command-line encoder) - 4.80.0
wvunpack.exe (command-line decoder) - 4.80.0
wvgain.exe (command-line ReplayGain scanner) - 4.80.0
-----------------------------------------------------
added: full Unicode support on Windows platform
added: new option --pre-quantize to truncate high-resolution files
to a reasonable depth (e.g., 20-bit) for better compression
fixed: Debian bug #793320 (executable stack)
fixed: LargeAddressAware problem reported on HA
fixed: several "fuzz test" failures reported on GitHub
fixed: repack blocks after possible arithmetic overflows
improved: faster assembly code for mono packing
improved: portability for various platforms
wvtest.exe (command-line libwavpack test suite) - 4.80.0
--------------------------------------------------------
added: exhaustive test for WavpackSeekSample() API
in_wv.dll (winamp plugin) - 2.8.0.1
CoreWavPack DirectShow Filters - 1.3.0.0
AmioWavpack.amio (Adobe Audition Plugins) - 1.5
cool_wv4.flt (CoolEdit / Audition filter) - 2.14
------------------------------------------------
updated: see 4.80.0 library changes
Works fine with my settings on manjaro-xfce 15.12 (64 bit) and Windows 8.1 (64 bit) both, as usual many thanks David, still the most versatile lossless codec around.
Thanks DARcode...I appreciate it!
According to http://www.wavpack.com/changelog.txt 4.80.0 was released at March 28, 2016:
I also posted here (https://hydrogenaud.io/index.php/topic,111545.0.html), and attached alternate mingw executables, but it doesn't seem like too many people saw it there.
Just to add another data point, I've hammered at it all evening, and it works brilliantly on Windows 10, latest Insider Build 14316. In fact, I've just gone ahead and replaced the old version with v4.80.0. WavPack is a work of genius. I'm glad you're still working on it.
I haven't had any of the issues fixed by this release, but so far, after having cross-encoded about a dozen of albums (
using foobar2000) and bit-compared the result with the original, everything is absolutely OK.
Thank you
@bryant for WavPack: the best lossless codec for me.
At least one developer caring about a proper implementation of compressed 32 bits audio files for DAWs.
Hope a remark like this doesn't get deleted -again- because I don't blindly praise other lossless implementations without real improvements since years ;)
So thank you so much, really appreciated.
It's amazing, I can get up to 50% compression at 32 bits with 6 channel files at the fastest setting possible ready to be further edited at some point. No more giant sized wavs for editing. And you also got channel decorrelation for any setting, not only stereo. It simply surpasses any other implementation.
Btw Audition has your plugins to support the format but Izotope still relies in useless flac for editing purposes; should I contact them to get more attention about your code or could it be implemented via plugin?
WavPack 4.80.0 added to Gentoo repo (https://packages.gentoo.org/packages/media-sound/wavpack).
Btw Audition has your plugins to support the format but Izotope still relies in useless flac for editing purposes; should I contact them to get more attention about your code or could it be implemented via plugin?
Adobe provides an SDK which allowed me to write the plugins for Audition. I Googled around a little and did not find such an SDK for iZotope, so this would be something that they would have to create, and it would make some sense if they handle 32-bit audio (either integer or float). Of course, as you can guess, they would probably have to have customers ask for it because it's not a trivial amount of work (especially if they've never even heard of WavPack).
WavPack 4.80.0 added to Gentoo repo (https://packages.gentoo.org/packages/media-sound/wavpack).
Very cool...thanks for "bugging" them! :)
Btw Audition has your plugins to support the format but Izotope still relies in useless flac for editing purposes; should I contact them to get more attention about your code or could it be implemented via plugin?
Adobe provides an SDK which allowed me to write the plugins for Audition. I Googled around a little and did not find such an SDK for iZotope, so this would be something that they would have to create, and it would make some sense if they handle 32-bit audio (either integer or float). Of course, as you can guess, they would probably have to have customers ask for it because it's not a trivial amount of work (especially if they've never even heard of WavPack).
Of course, the idea is to save my projects to WavPack instead of using Wav (all processing in any Steinberg sofware is float 32 bit) for further use later. It saves huge amounts of space for audio editing.
Will send them a mail, you are right about no SDK. I hope they find the support relevant since there is currently no other codec available out there capable of compressed 32 bits float audio; it's this or Wav.
Btw I have been looking for a way to extract the MD5sum and would like to now if there is a way to only get that field using
-x "Field" = extract specified tag field only to stdout (no audio decode)
the same than CUESHEET. I know you can use -s or -f but I'm looking only for the MD5sum as "field" (not the rest). And the other options would decode the file and verify it.
The idea is to get something similar to "metaflac.exe --show-md5sum" which extracts the stored md5sum to stdout.
Btw I have been looking for a way to extract the MD5sum and would like to now if there is a way to only get that field using
-x "Field" = extract specified tag field only to stdout (no audio decode)
The problem here is that MD5 sum is
not a tag field. It's a technical info such as bitrate or number of channels or samplerate.
I know that's why I asked about it, a possible exception, using that command line option as shortcut to a technical field.
The main thing is not treating it like a tag though -if that makes things more confusing-, an alternate/new command line option to get only he MD5 is equally fine.
EDIT:
It probably makes more sense and would be simpler if the -f option gets an extra argument so it only displays the desired field instead of dumping all info to stdout.
wvunpack -f "Field" infile[.wv]|- outfile[.wav]
1. sampling rate
2. bit-depth (1-32)
3. format ("int" or "float")
4. number of channels
5. channel mask (in hex because it's a mask, always prefixed with "0x")
6. number of samples (missing if unknown)
7. md5sum (technically is hex, but not prefixed with "0x", might be missing)
8. encoder version (basically this will always be 4, but there are some old files out there, could be 5 one day)
9. encoding mode (in hex because it's a bitfield, always prefixed with "0x")
10. filename (if available)
In "Field" you would put the number or a keyword for those fields, and then a 0 or -1 (or omitting the argument) to display all fields delimited by semicolons like it currently works.
That way you maintain compatibility with any previous usage, you get the current behavior by default and also the possibility to get MD5 sum or any other single technical field as needed. What do you think?
Adding an optional numeric parameter to -f would be pretty simple and clean, I think. That way "-f7" would output just the MD5. I'll investigate that.
Adding an optional numeric parameter to -f would be pretty simple and clean, I think. That way "-f7" would output just the MD5. I'll investigate that.
I have implemented this in the latest alpha version described in this thread (https://hydrogenaud.io/index.php/topic,111822.0.html).
Thank you, will test the alpha and report any errors.
At least one developer caring about a proper implementation of compressed 32 bits audio files for DAWs.
This is of interest to me as well, if I may ask about it. I know that FL Studio supports WavPack, can anything be expected on the Ableton Live front as well? Thanks for the answer and cheers for the project.
I think Ableton falls into the same category as Izotope in that there is no public SDK/API available for a 3rd party to add support for WavPack.
It looks like there was an unofficial SDK developed at one time, but it's dead. This is something Ableton would have to do, after being bugged about it, of course... :)
Yeah, I thought as much. I guess this turns it into a sort of chicken/egg scenario and lowers the chances of it happening considerably. People who have WavPack libraries might/will not jump over to Ableton because of this lack of support and people who use Ableton probably don't care much about the lack of WavPack support. Hence nothing gets done in this regard. Anyhow, excuse my aside and thanks again for the clarification.
Yep, people like us need to contact those developers asking for WavPack support.
Btw I don't work with Ableton but Izotope has a plugin named "Connect" which lets me import the raw audio directly from other programs (and then back to them), like Audition or ProTools. Some of them already have WavPack support so you can use them as intermediate hosts while processing to open WavPack files. I'm sure there are other solutions out there doing similar things; maybe useful for someone else ;)
Small compiler issue (VS2013)
wavpack_local.h
was:
static __inline int count_bits (uint32_t av) { long res; return _BitScanReverse (&res, av) ? (int)(res + 1) : 0; }
needs to be (so can compile):
static __inline int count_bits (uint32_t av) { unsigned long res; return _BitScanReverse (&res, av) ? (int)(res + 1) : 0; }
https://msdn.microsoft.com/en-us/library/fbxyd7zd.aspx
Thanks, Spoon, I appreciate it!
I'm currently working in a branch, but I'll get this into master as soon as I merge back.
-David