Some of the changes:
- Many minor bug fixes (especially on non-Windows platforms)
- Transcoding from existing WavPack files (with tag copy)
- Option to verify WavPack file integrity on creation
- New plugins for Adobe Audition CS5.5, CS6, and CC
- Source code is now hosted on GitHub (https://github.com/dbry/WavPack)
- Complete list of changes (http://www.wavpack.com/changelog.txt)
See the homepage (http://www.wavpack.com/) or go directly to download (http://www.wavpack.com/downloads.html).
Finally!
Will test and implement the changes in caudec ASAP.
Thanks for your hard work.
I can't believe they took down my joke post.
Updated my fork of Cog to this, working perfectly.
Congrats, dude!
Thank you!
Thank you David
Thanks, everyone!
I can't believe they took down my joke post.
Haha, it's okay, I saw it...
Speaking of binaries, I have uploaded the VS 2008 x64 binaries here (http://www.wavpack.com/wavpack-4.70.0-x64.zip) in case people want to use them. As was discussed in the release candidate thread, they're faster in some cases but up to 10% slower with the "extra" modes, so I'm not sure it makes much sense and I don't want to confuse general users with them on my downloads page.
David
I can't believe they took down my joke post.
Haha, it's okay, I saw it...
Maybe they are too
Completely agree for the x64 part.
Although you probably missed the part from the 4.70.0 release candidate topic where bryant said that the x86_64 version is not much faster than, or sometimes even slightly slower than the x86 version.
Thnx for the new release
Even if 64bit executable doesn't run fast, 64bit DLL might be useful for apparent reason.
On my Core2 9300, 64-bit encoder is noticeably slower than 32-bit one for 24-bit WAV files. As far as I can see MSVS forbids MMX intrinsics for 64-bit code, and, from a comment in pack.c:
The MMX version is significantly faster when the sample data requires the full-resolution apply_weight macro.
When I reversed the definition of apply_weight (so it simply uses 64-bit arithmetics) 64-bit encoder became noticeably faster than now, 32-bit encoder with MMX disabled - slightly faster, 32-bit with MMX enabled - no difference.
Even if 64bit executable doesn't run fast, 64bit DLL might be useful for apparent reason.
Good point. I have added the x64 versions of the DLL and the LIB to that file.
On my Core2 9300, 64-bit encoder is noticeably slower than 32-bit one for 24-bit WAV files. As far as I can see MSVS forbids MMX intrinsics for 64-bit code, and, from a comment in pack.c:
The MMX version is significantly faster when the sample data requires the full-resolution apply_weight macro.
When I reversed the definition of apply_weight (so it simply uses 64-bit arithmetics) 64-bit encoder became noticeably faster than now, 32-bit encoder with MMX disabled - slightly faster, 32-bit with MMX enabled - no difference.
That's weird. On my system they're both somewhat
slower using the 64-bit math. Are you compiling with VS 2008? I noticed that VS 2010 has an all new compiler, although I haven't read anywhere that it generates significantly different code.
That's weird. On my system they're both somewhat slower using the 64-bit math. Are you compiling with VS 2008? I noticed that VS 2010 has an all new compiler, although I haven't read anywhere that it generates significantly different code.
MSVS 2010 and 2012. I compiled the sources, then changed "#if 1" to "#if 0" in the definition of apply_weight and compiled again. Encoding time was reduced from 43 sec to 35 sec (64-bit exe, 24-bit stereo WAV, -hh option).
MSVS 2010 and 2012. I compiled the sources, then changed "#if 1" to "#if 0" in the definition of apply_weight and compiled again. Encoding time was reduced from 43 sec to 35 sec (64-bit exe, 24-bit stereo WAV, -hh option).
Interesting. How do those compare to the official 64-bit version? If they're faster, I might like to get a copy of the binaries from you to compare myself. Might be worth upgrading to the new compiler sooner rather than later.
Interesting. How do those compare to the official 64-bit version?
Official 64-bit exe: 43 sec. to encode
If they're faster, I might like to get a copy of the binaries from you to compare myself.
[attachment=7687:exe.zip](
original folder: original code compiled with VS 2010;
modified folder: code with alternative definition of apply_weight, also compiled with VS2010).
Tiny gripe, I'm sorry I didn't catch it before: "wavpack --version" shouldn't exit with code 1 (or any code other than 0, i.e. "success"). No biggie.
(original folder: original code compiled with VS 2010; modified folder: code with alternative definition of apply_weight, also compiled with VS2010).
Thanks for these!
Well, I see the same thing with these as with mine: the modified 64-bit version is about 4-5% slower than the unmodified, with both -hh and -x4. Very weird, because it seems our CPUs don't seem that different. And for 64-bit, the compiler doesn't make any appreciable difference.
However, for the 32-bit version (which uses MMX) the new compiler makes about a 10% improvement for 24-bit data, and I notice that now 16-bit data is actually handled slower than 24-bit, which might mean I should reëxamine the decision to not use MMX for 16-bit data.
This all reminds me why I generally stopped beating my head against the wall for a few percentage points speed improvement and try to just concentrate on features...but there's obviously room for upgrading my compiler (I actually already did this with the 7.1 SDK, but haven't switched to it) and playing around with the available options. Thanks again for bringing this up.
Tiny gripe, I'm sorry I didn't catch it before: "wavpack --version" shouldn't exit with code 1 (or any code other than 0, i.e. "success"). No biggie.
Well, apart from you not catching it, that's totally my fault, and completely unintentional. I copy/pasted without thinking.
I'll fix it right away, and I also see that requesting the "help" display does the same thing. Thanks for letting me know.
I also see that requesting the "help" display does the same thing
Well, running "wavpack --help" should exit with code 0 (because that's a valid action), but running "wavpack" on its own, without any parameters, should exit with a non zero code, even if that displays a short help screen, because it's actually a "usage error". The exit code for that, btw, is 64, as far as I can tell (from /usr/include/sysexits.h (http://pastebin.com/dLn8Lk6e)).
Edit: and it would also make sense to output to STDOUT upon "sucess" (e.g. "wavpack --help"), and STDERR upon usage error (e.g. "wavpack" without any parameters). If anything, it would discourage people from trying to parse the output of an erroneous command (by redirecting STDERR to STDOUT), which is there merely for convenience and could change in the future. The distinction should be made that the valid command for printing the help screen is "wavpack --help", and no other.
Well, I see the same thing with these as with mine: the modified 64-bit version is about 4-5% slower than the unmodified, with both -hh and -x4. Very weird, because it seems our CPUs don't seem that different. And for 64-bit, the compiler doesn't make any appreciable difference.
This .zip file was downloaded 14 times. Maybe anybody else wants to test and post the results?
32bit ICC & 64bit ICC w/MMX and alt def of apply_weight (http://daman6009.home.comcast.net/wavpack.zip).
32&64bit w/o MMX was slower on 16bit but faster on 24bit. The apply weight mod is <1% slower on my i5-3330.
CPU: Core i7 2630QM
Norah Jones - 12. Nightingale [4:12] (
24-bit 6ch WAV) -h -x2 option:
X | run 1 | run 2 |
official 32 | 38.23s | 38.37s |
official 64 | 40.37s | 40.34s |
original 32 | 35.21s | 35.27s |
original 64 | 40.39s | 40.28s |
modified 32 | 36.59s | 36.34s |
modified 64 | 37.94s | 37.88s |
icc-mmx 32 | 37.76s | 37.77s |
icc-mmx 64 | 28.50s | 28.43s |
Norah Jones - 12. Nightingale [4:12] (
16-bit 6ch WAV) -h -x2 option:
X | run 1 | run 2 |
official 32 | 37.27s | 37.34s |
official 64 | 36.61s | 36.81s |
original 32 | 36.88s | 36.77s |
original 64 | 36.55s | 36.53s |
modified 32 | 38.54s | 38.62s |
modified 64 | 36.31s | 36.43s |
icc-mmx 32 | 42.49s | 42.60s |
icc-mmx 64 | 29.37s | 29.56s |
32bit ICC & 64bit ICC w/MMX and alt def of apply_weight (http://daman6009.home.comcast.net/wavpack.zip).
32&64bit w/o MMX was slower on 16bit but faster on 24bit. The apply weight mod is <1% slower on my i5-3330.
Thanks for these! I'm starting to have trouble keeping track of all my builds...
I still don't understand why MS decided to ditch x64 MMX on MSVC, especially when everyone else seems to have no trouble with it (gcc allows it too). I've Googled and found nothing except this article (http://chessprogramming.wikispaces.com/MMX) that implies that there was some early confusion at MS about how native x64 OSes might behave. Anyway, I wish ICC wasn't $700 or I'd give it a shot.
But two things stand out. First, those binaries are a lot bigger than the official ones. Are they debug builds? I have not used ICC at all, so I don't know if this bloat is normal...perhaps they include more runtimes?
The other thing is that bb10's tests show a
huge improvement for 64-bit executables! It's almost too good to be true...did you try the new -v option for make sure you were really getting valid output? BTW, thanks for running those tests.
David
Well, running "wavpack --help" should exit with code 0 (because that's a valid action), but running "wavpack" on its own, without any parameters, should exit with a non zero code, even if that displays a short help screen, because it's actually a "usage error". The exit code for that, btw, is 64, as far as I can tell (from /usr/include/sysexits.h (http://pastebin.com/dLn8Lk6e)).
Yes, this is how I set it up (other than the special error codes).
Thanks for the link to the error exit codes...I have never seen those. Doesn't seem to be an equivalent for Windows; a search revealed this fairly useless, and even slightly amusing, page (http://msdn.microsoft.com/en-us/library/ms194959%28v=vs.100%29.aspx)...
I ran some tests with the various versions and included GCC 4.82 compiles in the mix too. These results are from Core i7-4771. I ran each test twice and used fastest results of each. The parameters I used were the same bb10 used: -h -x2. The numbers are speed x realtime.
official 32-bit:
16-bit: 78,35212648x
24-bit: 77,01991355x
official 64-bit:
16-bit: 78,62632693x
24-bit: 63,22435532x
lvqcl original 32-bit:
16-bit: 78,14190364x
24-bit: 86,93761979x
lvqcl original 64-bit:
16-bit: 79,32029858x
24-bit: 63,45351647x
lvqcl modified 32-bit:
16-bit: 78,17297656x
24-bit: 86,952771x
lvqcl modified 64-bit:
16-bit: 78,65516379x
24-bit: 76,97832292x
intel 32-bit:
16-bit: 69,03704896x
24-bit: 89,67199856x
intel 64-bit:
16-bit: 98,29642284x
24-bit: 90,80626081x
gcc 4.82 32-bit:
16-bit: 77,13143698x
24-bit: 72,1682216x
gcc 4.82 64-bit:
16-bit: 79,48867848x
24-bit: 72,89575572x
The other thing is that bb10's tests show a huge improvement for 64-bit executables! It's almost too good to be true...did you try the new -v option for make sure you were really getting valid output? BTW, thanks for running those tests.
David
Yes, that's the first thing I did when I saw the speed. And you're welcome.
CPU: Intel i7 950; input: 24-bit stereo WAV; options: -hx2
(official) x32: 55.6 s
(official) x64: 79.5 s
(MSVS 2010) x32, both original and modified code: 47.6 s
(MSVS 2010) x64, original : 79.0 s
(MSVS 2010) x64, modified: 57.0 s
(MinGW GCC 4.82) 56.5 s (MMX enabled for both x32 and x64 and there's almost no difference between versions)
(Intel ICC 2013) x32: 42.5 s
(Intel ICC 2013) x64: 42.3 s (MMX enabled for both x32 and x64, and x64 is slightly faster than x32)
GCC 4.82 compiles
gcc 4.82 32-bit
gcc 4.82 64-bit
Please, would you share these GCC builds ?
Here you go: [attachment=7692:wavpack-gcc.zip]
Thanks a lot
Thanks for the binaries and all the testing, guys!
I think I'm starting to understand why Xiph lets other people provide their binaries...
I think I'm starting to understand why Xiph lets other people provide their binaries...
Ah!
I don't think it's unreasonable to provide a "reference" set of binaries and let sites like RareWares handle specialized compiles like ICL. This approach seems to work well enough for FLAC, but it doesn't look like RW has provided Wavpack binaries since 4.32.
I don't think it's unreasonable to provide a "reference" set of binaries and let sites like RareWares handle specialized compiles like ICL. This approach seems to work well enough for FLAC, but it doesn't look like RW has provided Wavpack binaries since 4.32.
If I remember correctly Case's FLAC compiles are faster than RareWares' ICLs. I have to double check this. Is there any reason we all should use ICL compiles? Or, are there other reasons to use different compiles other than compatibility and speed?
Is there any reason we all should use ICL compiles? Or, are there other reasons to use different compiles other than compatibility and speed?
Other speed comparisons have shown that one build is the fastest on X computer but for Y it's another build which is the faster one.
There is no rule of thumb, hardware (especially CPU) OS and drivers can make a big difference so use what is the best for you on your computer.
I don't think it's unreasonable to provide a "reference" set of binaries and let sites like RareWares handle specialized compiles like ICL. This approach seems to work well enough for FLAC, but it doesn't look like RW has provided Wavpack binaries since 4.32.
I obviously have no issue with binaries posted elsewhere, and in fact would like to see some Mac binaries up somewhere. I would appreciate giving them a "once-over" to make sure that nothing badly broken gets out there, and I think it would be nice if they were built with the official, unmodified sources.
BTW, I have given a "once-over" to all the binaries posted to this thread. The new transcoding and verify options make it very easy to do pretty thorough encode/decode testing with just the wavpack executable. This certainly would have caught the memcpy() and unsigned character bugs in the previous release.
I think it would be nice if they were built with the official, unmodified sources.
To tell the truth, qaac has been using modified wavpack header (not implementation) due to conflicting typedefs against standard stdint.h provided by MSVC >= 10 .
They introduced stdint.h at MSVC10 (but no inttypes.h), and now introduced inttypes.h at MSVC12. I sent pullreq on github repos.
As for building with MSVC >= 10, automatic upgrading of project files works but is not perfect.
It seems that MSBuild doesn't like the way current wavpack projects deal with custom linker output name.
Instead of specifying custom linker output name, setting "target name" and "target ext" seems to shut up warning about them:
[attachment=7693:wavpack_...proj.tar.gz]
I think it would be nice if they were built with the official, unmodified sources.
To tell the truth, qaac has been using modified wavpack header (not implementation) due to conflicting typedefs against standard stdint.h provided by MSVC >= 10 .
They introduced stdint.h at MSVC10 (but no inttypes.h), and now introduced inttypes.h at MSVC12. I sent pullreq on github repos.
Actually, I almost added something like "other than changes required to build", but I guess I figured that was redundant.
Thanks for the patches; I have applied them.
Better late than never: thanks a bunch David, it's always cool to get a new version of the great WavPack from a great guy.
Congrats David on releasing 4.70. It's really great seeing a new version out there with some nice new features. Well done!
Thanks for this!
BTW: I notice that the "doc" directory and foremost it's content are gone from the *nix tarball.....
Just my two cents; it could have stayed, some distros install that documentation too....
- Many minor bug fixes (especially on non-Windows platforms)
Hi bryant.
Maybe you know about this already.
In wavpack.pc change 'exec_prefix' to 'prefix' then it's OK (with Linux).
I didn't work this out myself, Doctor Google found it here ---> linky (http://code.google.com/p/qmmp/issues/detail?id=618)
Best wishes.
Edit
This caused me problems trying to compile easytag-2.1.8.
I used wavpack-4.70 from the wavpack.com website, I didn't know about the git.
Now I've compiled the git version, it is different.
It has failed to build for me "No rule to make target `wavpack.1', needed by `all-am'"
But no sweat, the modified wavpack-4.70 from the wavpack.com website provides the library I needed.
BTW: I notice that the "doc" directory and foremost it's content are gone from the *nix tarball.....
Just my two cents; it could have stayed, some distros install that documentation too....
Shoot...that was
not intentional.
I briefly thought about just dropping it in there right now, but I googled the md5sum of the tarball and it was all over the place...
Hi bryant.
Maybe you know about this already.
In wavpack.pc change 'exec_prefix' to 'prefix' then it's OK (with Linux).
I didn't work this out myself, Doctor Google found it here ---> linky (http://code.google.com/p/qmmp/issues/detail?id=618)
Yes, I was aware of this and it has been fixed in Git (although not exactly like you have here). Thanks!
Now I've compiled the git version, it is different.
It has failed to build for me "No rule to make target `wavpack.1', needed by `all-am'"
But no sweat, the modified wavpack-4.70 from the wavpack.com website provides the library I needed.
You can actually ignore that annoying error. It's just failing in the "man" directory because you did not specify --enable-man on the configure line (and if you
do specify --enable-man you might need some docbook stuff or that will fail). But it should have built everything already by then (although I'm not completely sure that "install" will work in that case).
Sorry for the mess, but glad you got what you needed!
it has been fixed in Git (although not exactly like you have here).
Yes it's fixed,
I have uninstalled wavpack and easytag.
And compiled wavpack from git using "--enable-man".
Then EasyTAG-2.1.8 built OK again with WavPack support.
Thanks.
--enable man I think needs something along this:
xsltproc
docbook-xml
docbook-xsl
...or smilar depending on your distro / OS
If I remember correctly, when I tried out of tree build (that is, running configure script from different directory), I was forced to run make distclean first, and it effectively removes the man file.
So, in SOME cases you may have to regenerate man pages using docbook things.
Some programs have configuration options like this:-
--disable-doc
--disable-docs
--disable-documentation
They are OK for when only a library is being compiled, no frills are needed.
(I have used libwavpack.a/libwavpack.la when building EasyTAG and FFmpeg)
Late thanks are due to David from me as hybrid WavPack, IMHO, is simply the bright light at the end of the tunnel that my then-ambiguous, hard-to-manage lossy-lossless collection had become, thanks to me having to care about only ONE single APE tag per audio file now - not two or three.
Thank you ever so much for the great work, David!
Thanks David. My old PC have rather small hard disk. The extra compression option always come in handy.
bryant, isn't this incorrect? From your website: "Hybrid mode now operates as low as 2.25 bits/sample (or 196 kbps for CD audio)". Shouldn't you say something like "near CD audio" or "mostly transparent to CD audio" or something similar?
2) "Foobar2000 Advanced Audio Player (native support w/ ReplayGain & Cuesheets)" = foobar2000?
3) "Easy CD-DA Extractor" = This one changed name: it is now EZ CD Audio Converter
bryant, isn't this incorrect? From your website: "Hybrid mode now operates as low as 2.25 bits/sample (or 196 kbps for CD audio)". Shouldn't you say something like "near CD audio" or "mostly transparent to CD audio" or something similar?
By "CD audio" I mean 16/44. I don't say anything like "CD
quality audio" (and in fact the quality is not very good at that minimum bitrate).
I could change the capital letter in foobar2000, but one could argue that I am just capitalizing the line (like above in the features), but I did miss "jetAudio"...
Thanks for the name change of Easy CD-DA Extractor...I'll definitely fix that one.
...and dBpoweramp
But, I think you can skip the capitalization when you have points. I have to double check.
Any plans to add wave64 support? I recently had to encode some and had to use foobar2000 which wrote unnecessary metadata.
Any plans to add wave64 support? I recently had to encode some and had to use foobar2000 which wrote unnecessary metadata.
Yes, that is actually the next item. I have already most of the work for this in a development branch, initially implementing the CAF format
I had one question though. Should I implement wave64 and/or rf64? Does anyone know if one or the other of these has become "standard", or are they both widely used?
Thanks!
Probably whatever foobar2000 supports
As far as I can tell, only Wave64 is in the Converter. It produces a file header beginning with "riff".
It does play back both though...
Thank you David！