IPB

Welcome Guest ( Log In | Register )

3 Pages V  < 1 2 3 >  
Reply to this topicStart new topic
WavPack 4.70.0 Released
bryant
post Oct 28 2013, 19:43
Post #26


WavPack Developer


Group: Developer (Donating)
Posts: 1287
Joined: 3-January 02
From: San Francisco CA
Member No.: 900



QUOTE (lamedude @ Oct 27 2013, 05:45) *
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... smile.gif

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
Go to the top of the page
+Quote Post
bryant
post Oct 28 2013, 20:25
Post #27


WavPack Developer


Group: Developer (Donating)
Posts: 1287
Joined: 3-January 02
From: San Francisco CA
Member No.: 900



QUOTE (skamp @ Oct 26 2013, 01:21) *
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... smile.gif
Go to the top of the page
+Quote Post
Case
post Oct 28 2013, 20:52
Post #28





Group: Developer (Donating)
Posts: 2137
Joined: 19-October 01
From: Finland
Member No.: 322



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


This post has been edited by Case: Oct 28 2013, 21:24
Go to the top of the page
+Quote Post
bb10
post Oct 28 2013, 21:29
Post #29





Group: Members
Posts: 169
Joined: 8-November 06
Member No.: 37341



QUOTE (bryant @ Oct 28 2013, 19:43) *
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. smile.gif
Go to the top of the page
+Quote Post
lvqcl
post Oct 28 2013, 22:27
Post #30





Group: Developer
Posts: 3219
Joined: 2-December 07
Member No.: 49183



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)
Go to the top of the page
+Quote Post
Brazil2
post Oct 29 2013, 13:30
Post #31





Group: Members
Posts: 121
Joined: 9-May 10
Member No.: 80499



QUOTE (Case @ Oct 28 2013, 20:52) *
GCC 4.82 compiles
gcc 4.82 32-bit
gcc 4.82 64-bit

Please, would you share these GCC builds ?
Go to the top of the page
+Quote Post
Case
post Oct 29 2013, 17:32
Post #32





Group: Developer (Donating)
Posts: 2137
Joined: 19-October 01
From: Finland
Member No.: 322



Here you go: Attached File  wavpack-gcc.zip ( 209.46K ) Number of downloads: 95
Go to the top of the page
+Quote Post
Brazil2
post Oct 29 2013, 17:46
Post #33





Group: Members
Posts: 121
Joined: 9-May 10
Member No.: 80499



Thanks a lot smile.gif
Go to the top of the page
+Quote Post
bryant
post Oct 29 2013, 23:31
Post #34


WavPack Developer


Group: Developer (Donating)
Posts: 1287
Joined: 3-January 02
From: San Francisco CA
Member No.: 900



Thanks for the binaries and all the testing, guys!

I think I'm starting to understand why Xiph lets other people provide their binaries... smile.gif
Go to the top of the page
+Quote Post
eahm
post Oct 30 2013, 00:14
Post #35





Group: Members
Posts: 886
Joined: 11-February 12
Member No.: 97076



QUOTE (bryant @ Oct 29 2013, 15:31) *
I think I'm starting to understand why Xiph lets other people provide their binaries... smile.gif

Ah!
Go to the top of the page
+Quote Post
Heliologue
post Oct 30 2013, 04:51
Post #36





Group: Members
Posts: 100
Joined: 17-September 06
Member No.: 35303



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.
Go to the top of the page
+Quote Post
eahm
post Oct 30 2013, 05:05
Post #37





Group: Members
Posts: 886
Joined: 11-February 12
Member No.: 97076



QUOTE (Heliologue @ Oct 29 2013, 20:51) *
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?

This post has been edited by eahm: Oct 30 2013, 05:06
Go to the top of the page
+Quote Post
Brazil2
post Oct 30 2013, 07:27
Post #38





Group: Members
Posts: 121
Joined: 9-May 10
Member No.: 80499



QUOTE (eahm @ Oct 30 2013, 05:05) *
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.
Go to the top of the page
+Quote Post
bryant
post Oct 31 2013, 00:17
Post #39


WavPack Developer


Group: Developer (Donating)
Posts: 1287
Joined: 3-January 02
From: San Francisco CA
Member No.: 900



QUOTE (Heliologue @ Oct 29 2013, 20:51) *
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.
Go to the top of the page
+Quote Post
nu774
post Oct 31 2013, 02:11
Post #40





Group: Developer
Posts: 477
Joined: 22-November 10
From: Japan
Member No.: 85902



QUOTE (bryant @ Oct 31 2013, 08:17) *
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:
Attached File  wavpack_vc10proj.tar.gz ( 5.54K ) Number of downloads: 56
Go to the top of the page
+Quote Post
bryant
post Oct 31 2013, 03:18
Post #41


WavPack Developer


Group: Developer (Donating)
Posts: 1287
Joined: 3-January 02
From: San Francisco CA
Member No.: 900



QUOTE (nu774 @ Oct 30 2013, 18:11) *
QUOTE (bryant @ Oct 31 2013, 08:17) *
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. smile.gif
Go to the top of the page
+Quote Post
DARcode
post Oct 31 2013, 07:43
Post #42





Group: Members (Donating)
Posts: 679
Joined: 10-January 05
From: Italy
Member No.: 18968



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.70.0 -b384hx6cmv/qaac 2.32 -V 100
Go to the top of the page
+Quote Post
soiaf
post Nov 3 2013, 18:48
Post #43





Group: Members (Donating)
Posts: 73
Joined: 13-May 05
From: Dublin, Ireland
Member No.: 22024



Congrats David on releasing 4.70. It's really great seeing a new version out there with some nice new features. Well done!
Go to the top of the page
+Quote Post
Mr_Rabid_Teddybe...
post Nov 8 2013, 08:21
Post #44





Group: Members
Posts: 1197
Joined: 3-September 03
From: Bergen, Norway
Member No.: 8667



Thanks for this! cool.gif

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
Go to the top of the page
+Quote Post
bat_guano
post Nov 8 2013, 13:41
Post #45





Group: Members
Posts: 15
Joined: 7-January 13
Member No.: 105656



QUOTE (bryant @ Oct 21 2013, 01:42) *
[*] 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.
cool.gif

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.

This post has been edited by bat_guano: Nov 8 2013, 14:08
Go to the top of the page
+Quote Post
bryant
post Nov 8 2013, 18:29
Post #46


WavPack Developer


Group: Developer (Donating)
Posts: 1287
Joined: 3-January 02
From: San Francisco CA
Member No.: 900



QUOTE (Mr_Rabid_Teddybear @ Nov 8 2013, 00:21) *
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... smile.gif
Go to the top of the page
+Quote Post
bryant
post Nov 8 2013, 18:43
Post #47


WavPack Developer


Group: Developer (Donating)
Posts: 1287
Joined: 3-January 02
From: San Francisco CA
Member No.: 900



QUOTE (bat_guano @ Nov 8 2013, 05:41) *
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! smile.gif
Go to the top of the page
+Quote Post
bat_guano
post Nov 8 2013, 19:39
Post #48





Group: Members
Posts: 15
Joined: 7-January 13
Member No.: 105656



QUOTE (bryant @ Nov 8 2013, 18:43) *
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.
smile.gif
Go to the top of the page
+Quote Post
Mr_Rabid_Teddybe...
post Nov 9 2013, 02:03
Post #49





Group: Members
Posts: 1197
Joined: 3-September 03
From: Bergen, Norway
Member No.: 8667



--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
Go to the top of the page
+Quote Post
nu774
post Nov 9 2013, 02:21
Post #50





Group: Developer
Posts: 477
Joined: 22-November 10
From: Japan
Member No.: 85902



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.
Go to the top of the page
+Quote Post

3 Pages V  < 1 2 3 >
Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 23rd April 2014 - 18:56