Hydrogenaudio Forums

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)

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

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.

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?

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).

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

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?

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.

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 ;)