Skip to main content

Topic: WavPack 4.70.0 Released (Read 40632 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.
  • bryant
  • [*][*][*][*][*]
  • Developer (Donating)
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

  • bryant
  • [*][*][*][*][*]
  • Developer (Donating)
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... 

  • Case
  • [*][*][*][*][*]
  • Developer (Donating)
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
  • Last Edit: 28 October, 2013, 04:24:53 PM by Case

  • bb10
  • [*][*][*]
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.

  • lvqcl
  • [*][*][*][*][*]
  • Developer
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)

  • Brazil2
  • [*][*][*]
WavPack 4.70.0 Released
Reply #30
GCC 4.82 compiles
gcc 4.82 32-bit
gcc 4.82 64-bit

Please, would you share these GCC builds ?

  • Case
  • [*][*][*][*][*]
  • Developer (Donating)
WavPack 4.70.0 Released
Reply #31
Here you go: [ Specified attachment is not available ]

  • Brazil2
  • [*][*][*]
WavPack 4.70.0 Released
Reply #32
Thanks a lot

  • bryant
  • [*][*][*][*][*]
  • Developer (Donating)
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... 

  • eahm
  • [*][*][*][*][*]
WavPack 4.70.0 Released
Reply #34
I think I'm starting to understand why Xiph lets other people provide their binaries... 

Ah!

  • Heliologue
  • [*][*][*]
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.

  • eahm
  • [*][*][*][*][*]
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?
  • Last Edit: 30 October, 2013, 12:06:23 AM by eahm

  • Brazil2
  • [*][*][*]
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.

  • bryant
  • [*][*][*][*][*]
  • Developer (Donating)
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.

  • nu774
  • [*][*][*][*][*]
  • Developer
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:
[ Specified attachment is not available ]

  • bryant
  • [*][*][*][*][*]
  • Developer (Donating)
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. 

  • DARcode
  • [*][*][*][*][*]
  • Members (Donating)
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 4.80.0 -b384hx6cmv/qaac 2.58 -V 100

  • soiaf
  • [*][*]
  • Members (Donating)
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

  • bat_guano
  • [*]
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.
  • Last Edit: 08 November, 2013, 08:08:29 AM by bat_guano

  • bryant
  • [*][*][*][*][*]
  • Developer (Donating)
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... 

  • bryant
  • [*][*][*][*][*]
  • Developer (Donating)
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! 

  • bat_guano
  • [*]
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

  • nu774
  • [*][*][*][*][*]
  • Developer
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.