WavPack sourcecode released under the BSD software license:
http://www.wavpack.com (http://www.wavpack.com)
Thank you David Bryant.
Win32 binaries of WavPack 3.97a available from my others page. (http://homepage.ntlworld.com/jfe1205/others.html)
This is great news.
WavPack sourcecode released under the BSD software license:
Cool, maybe now I can find and fix that 'infinite newlines' bug I have with it on NT so I can finally update the FLAC comparison page.
Oh yeah, and see how WavPack works
Josh
... so I can finally update the FLAC comparison page.
Great! When you update the comparisons Josh, would you consider adding an "audiobook" track for comparison? I find FLAC is generally able to give a compression ratio around 0.2230 for spoken-word encoding, whereas WavePack's rate hovers around 0.2550. Not a huge difference, but it means FLAC saves 12-13 Mb/hour....
- M.
I want to thank all of you for your support.
Unfortunately, a couple of developers were not so happy with the WavPack sources because I used a bunch of static variables which make multithreading difficult. Well, I was afraid that eliminating them would hurt performance, but I was quite surprised when I found that it did no such thing. So, I have posted a replacement set of sources that should be completely thread-safe.
Also, I have compressed the self-extraction stub using UPX (thanks to john33 and Roberto for the idea) so now the overhead for that is only 26K per file.
3.97b binaries (ICL6 compiles) posted at my 'Others' page at Mirror 1.
Cool, maybe now I can find and fix that 'infinite newlines' bug I have with it on NT so I can finally update the FLAC comparison page.
OK, finally got around to this (took me a couple of hours to get it to build). For me the problem appears to be caused by the code that shows the progress on the window title (display_progress()). If I remove that guy, problem solved. I have no idea why.
The data points I have:
3.91 binaries: both wavpack.exe and wvunpack.exe had the problem
3.96 binaries: only wvunpack.exe had the problem
3.97a compiled from stock sources: only wvunpack.exe had the problem
Bryant, hope you're watching!
Oh yeah, and see how WavPack works
The code is very interesting. I have not delved too deep but it looks like a novel method. It seems it would be hard to prove that nothing in there is patented though. But such is the way in the U.S.A.
After running my big batch o' tests, the compression in the 'high' mode has improved a lot: in between MAC 3.96 "normal" and flac 1.0.4 "-5". The encoding time is about the same as FLAC but decode time is twice as long as FLAC.
The normal mode is 50% faster than flac -5 and about as fast decoding, with about 1% better compression.
I will have the full results on the comparison page when 1.0.5 comes out. After that, Bryant, if you're conducive to the idea it might be fun to try a WavPack+FLAC hybrid.
Josh