Skip to main content
Topic: WavPack 4.70.0 Released (Read 43575 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

WavPack 4.70.0 Released

Some of the changes:

See the homepage or go directly to download.

WavPack 4.70.0 Released

Reply #1
Finally! 

Will test and implement the changes in caudec ASAP.

WavPack 4.70.0 Released

Reply #2
Thanks for your hard work.

I can't believe they took down my joke post.

WavPack 4.70.0 Released

Reply #3
Updated my fork of Cog to this, working perfectly.


WavPack 4.70.0 Released

Reply #5
Thank you!
loquor mee menti: factus de materia, cinis elementi...

WavPack 4.70.0 Released

Reply #6
Thank you David
wavpack 4.8 -b256hx6c

WavPack 4.70.0 Released

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


WavPack 4.70.0 Released

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

WavPack 4.70.0 Released

Reply #10
Thnx for the new release

WavPack 4.70.0 Released

Reply #11
Even if 64bit executable doesn't run fast, 64bit DLL might be useful for apparent reason.

WavPack 4.70.0 Released

Reply #12
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:

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

WavPack 4.70.0 Released

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

WavPack 4.70.0 Released

Reply #14
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:

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

WavPack 4.70.0 Released

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

WavPack 4.70.0 Released

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

WavPack 4.70.0 Released

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

WavPack 4.70.0 Released

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

WavPack 4.70.0 Released

Reply #19
(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.

WavPack 4.70.0 Released

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

WavPack 4.70.0 Released

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

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.

WavPack 4.70.0 Released

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

 

WavPack 4.70.0 Released

Reply #24
CPU: Core i7 2630QM
Norah Jones - 12. Nightingale [4:12] (24-bit 6ch WAV) -h -x2 option:

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

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

 
SimplePortal 1.0.0 RC1 © 2008-2020