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 4.70.0 Released (Read 56795 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

WavPack 4.70.0 Released

Reply #25
32bit ICC & 64bit ICC w/MMX and alt def of apply_weight.
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 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

WavPack 4.70.0 Released

Reply #26
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).

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

WavPack 4.70.0 Released

Reply #27
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.

Code: [Select]
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

WavPack 4.70.0 Released

Reply #28
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.

WavPack 4.70.0 Released

Reply #29
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)


WavPack 4.70.0 Released

Reply #31
Here you go: [attachment=7692:wavpack-gcc.zip]

WavPack 4.70.0 Released

Reply #32
Thanks a lot

WavPack 4.70.0 Released

Reply #33
Thanks for the binaries and all the testing, guys!

I think I'm starting to understand why Xiph lets other people provide their binaries... 


WavPack 4.70.0 Released

Reply #35
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.

WavPack 4.70.0 Released

Reply #36
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?

 

WavPack 4.70.0 Released

Reply #37
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.

WavPack 4.70.0 Released

Reply #38
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.

WavPack 4.70.0 Released

Reply #39
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]

WavPack 4.70.0 Released

Reply #40
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. 

WavPack 4.70.0 Released

Reply #41
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.
WavPack 5.6.0 -b384hx6cmv / qaac64 2.80 -V 100

WavPack 4.70.0 Released

Reply #42
Congrats David on releasing 4.70. It's really great seeing a new version out there with some nice new features. Well done!

WavPack 4.70.0 Released

Reply #43
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....

"ONLY THOSE WHO ATTEMPT THE IMPOSSIBLE WILL ACHIEVE THE ABSURD"
        - Oceania Association of Autonomous Astronauts

WavPack 4.70.0 Released

Reply #44
  • 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
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.

WavPack 4.70.0 Released

Reply #45
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... 

WavPack 4.70.0 Released

Reply #46
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

Yes, I was aware of this and it has been fixed in Git (although not exactly like you have here). Thanks!

Quote
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! 

WavPack 4.70.0 Released

Reply #47
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.

WavPack 4.70.0 Released

Reply #48
--enable man I think needs something along this:

xsltproc
docbook-xml
docbook-xsl

...or smilar depending on your distro / OS

"ONLY THOSE WHO ATTEMPT THE IMPOSSIBLE WILL ACHIEVE THE ABSURD"
        - Oceania Association of Autonomous Astronauts

WavPack 4.70.0 Released

Reply #49
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.