IPB

Welcome Guest ( Log In | Register )

4 Pages V  < 1 2 3 4 >  
Reply to this topicStart new topic
WavPack 4.41 beta available, significantly faster on some systems
bryant
post Feb 28 2007, 06:11
Post #51


WavPack Developer


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



QUOTE (Synthetic Soul @ Feb 27 2007, 00:03) *
I don't really understand the MMX, SSE stuff; however would I be right in saying that, due to the integer arithmetic nature of WavPack, SSE code is pointless? Anything else up your sleeve?
Right. Because WavPack encoding is integer-only (and generally not parallelizable) there's little or nothing to be gained by SSE and his brothers. MMX should be able to make a nice improvement because the left and right channels can be done together, but because of some optimization available for 16-bit data that doesn't work with MMX, the MMX stuff only really helps with 24-bit (and float) data.

I did get an idea from one of the FLAC 1.1.4 improvements that might be applicable to WavPack and I'll give that a try. You never know when something's going to make a big difference...

QUOTE
Anyway, I'm sure all your users will agree, the extra benefit provided by this beta with no loss in compression is extremely welcome. Many thanks for your continued efforts. smile.gif
Ah, well it's my pleasure... smile.gif
Go to the top of the page
+Quote Post
DARcode
post Feb 28 2007, 15:21
Post #52





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



QUOTE (Synthetic Soul @ Feb 27 2007, 10:03) *
[...]Anyway, I'm sure all your users will agree, the extra benefit provided by this beta with no loss in compression is extremely welcome. Many thanks for your continued efforts. smile.gif
Definitely extremely welcome and surely worth thanking whole heartedly for.
Haven't begun re-encoding from 4.3x to 4.4x for better DAP support yet, so the added speed is greatly appreciated.


--------------------
WavPack 4.70.0 -b384hx6cmv/qaac 2.43 -V 100
Go to the top of the page
+Quote Post
DARcode
post Mar 5 2007, 15:48
Post #53





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



QUOTE (bryant @ Feb 28 2007, 07:11) *
[...]I did get an idea from one of the FLAC 1.1.4 improvements that might be applicable to WavPack and I'll give that a try. You never know when something's going to make a big difference...[...]
Are you going to try and include the above into the 4.41 changes or can we expect a separate release please?
Thanks a bunch once more for your time and brilliant work.


--------------------
WavPack 4.70.0 -b384hx6cmv/qaac 2.43 -V 100
Go to the top of the page
+Quote Post
bryant
post Mar 6 2007, 06:30
Post #54


WavPack Developer


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



QUOTE (DARcode @ Mar 5 2007, 06:48) *
QUOTE (bryant @ Feb 28 2007, 07:11) *
[...]I did get an idea from one of the FLAC 1.1.4 improvements that might be applicable to WavPack and I'll give that a try. You never know when something's going to make a big difference...[...]
Are you going to try and include the above into the 4.41 changes or can we expect a separate release please?
Thanks a bunch once more for your time and brilliant work.

I tried it the other day but wasn't able to make a big enough improvement for how ugly the change is. I'll work at a little more, but I'm not sure it's going to work out. sad.gif
Go to the top of the page
+Quote Post
bryant
post Mar 11 2007, 22:45
Post #55


WavPack Developer


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



I have created a second beta that I believe makes another worthwhile improvement in performance. This involves accessing the bitstream in 16-bit chunks instead of 8-bit chunks, so it should affect the faster modes more (at least on a percentage basis).

Like the first beta, it should be bit identical to 4.40.0 in all circumstances.

Thanks in advance for any testing... smile.gif

Here it is.
Go to the top of the page
+Quote Post
Madman2003
post Mar 12 2007, 00:05
Post #56





Group: Members
Posts: 132
Joined: 18-February 04
Member No.: 12104



Some sourcecode would be nice for us non-windows users.
Go to the top of the page
+Quote Post
Mangix
post Mar 12 2007, 00:06
Post #57





Group: Members
Posts: 591
Joined: 26-February 06
Member No.: 28077



the svn server is at http://svn.slomosnail.de/wavpack

grab subversion(if you don't already have it) and get it.
Go to the top of the page
+Quote Post
A_Man_Eating_Duc...
post Mar 12 2007, 02:56
Post #58





Group: Members
Posts: 940
Joined: 21-December 01
From: New Zealand
Member No.: 705



i'm just wondering if there is any harm having the --optimize-mono to be on by default?

This post has been edited by A_Man_Eating_Duck: Mar 12 2007, 02:57


--------------------
Who are you and how did you get in here ?
I'm a locksmith, I'm a locksmith.
Go to the top of the page
+Quote Post
Mangix
post Mar 12 2007, 04:08
Post #59





Group: Members
Posts: 591
Joined: 26-February 06
Member No.: 28077



IIRC, --optimize-mono only breaks compatability with any version of WavPack below 4.31
Go to the top of the page
+Quote Post
shadowking
post Mar 12 2007, 09:03
Post #60





Group: Members
Posts: 1527
Joined: 31-January 04
Member No.: 11664



--optimize-mono is also buggy in lossy mode - bitrate drops , though only on dual-mono content.


--------------------
Wavpack -b450s0.7
Go to the top of the page
+Quote Post
A_Man_Eating_Duc...
post Mar 12 2007, 09:35
Post #61





Group: Members
Posts: 940
Joined: 21-December 01
From: New Zealand
Member No.: 705



i did a quick comparison using the --optimize-mono switch and without it in lossless mode, and the file sizes are the same, this is on normal stereo audio.


--------------------
Who are you and how did you get in here ?
I'm a locksmith, I'm a locksmith.
Go to the top of the page
+Quote Post
shadowking
post Mar 12 2007, 09:39
Post #62





Group: Members
Posts: 1527
Joined: 31-January 04
Member No.: 11664



It only kicks in on dual-mono content or similar, so its safe to use in lossless if your player doesn't need < 4.31 decoder. From what I understand is that there is a new decoder that fixes this without the hack and will be used at some point in the future.. or maybe the --optimize hack will hardcoded instead ?

This post has been edited by shadowking: Mar 12 2007, 09:42


--------------------
Wavpack -b450s0.7
Go to the top of the page
+Quote Post
bryant
post Mar 12 2007, 20:21
Post #63


WavPack Developer


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



QUOTE (shadowking @ Mar 12 2007, 00:03) *
--optimize-mono is also buggy in lossy mode - bitrate drops , though only on dual-mono content.

Have you actually seen this lately? I thought I fixed it before I released 4.40 but I never mentioned it in the changelog because it (the bug) never made it into a real release.

Now that the DirectShow filter is based on the latest library, the only decoder that can't handle the new mode is the XMMS plugin that I provide. Once I figure out how to build that with the latest library I could make the --optimize-mono the default, with perhaps a new switch to turn it off (for maximum compatibility).

Unless you're using the XMMS plugin (or are encoding files for a large audience), it's perfectly safe to use all the time.
Go to the top of the page
+Quote Post
Madman2003
post Mar 12 2007, 23:25
Post #64





Group: Members
Posts: 132
Joined: 18-February 04
Member No.: 12104



Encoding speeds are amazing compared to flac, wavpack -hh seems much faster than flac -8 (order of 4 difference), decoding is about half the speed (only 40% difference with mode -h compared to the 100% difference of -hh). Good work, wavpack has the potential to beat flac. Keep up the good work.

This post has been edited by Madman2003: Mar 13 2007, 00:03
Go to the top of the page
+Quote Post
shadowking
post Mar 13 2007, 00:51
Post #65





Group: Members
Posts: 1527
Joined: 31-January 04
Member No.: 11664



QUOTE (bryant @ Mar 13 2007, 05:21) *
QUOTE (shadowking @ Mar 12 2007, 00:03) *

--optimize-mono is also buggy in lossy mode - bitrate drops , though only on dual-mono content.

Have you actually seen this lately? I thought I fixed it before I released 4.40 but I never mentioned it in the changelog because it (the bug) never made it into a real release.

Now that the DirectShow filter is based on the latest library, the only decoder that can't handle the new mode is the XMMS plugin that I provide. Once I figure out how to build that with the latest library I could make the --optimize-mono the default, with perhaps a new switch to turn it off (for maximum compatibility).

Unless you're using the XMMS plugin (or are encoding files for a large audience), it's perfectly safe to use all the time.


http://www.hydrogenaudio.org/forums/index....ost&id=2888

When encoding that sample with optimize-mono bitrate drops 60k or so. SNR is similar with or without the switch, but really should be much higher. If I add the missing 60k - i.e. change b320 to b380 I'll get what should be , I think..



WAVPACK Hybrid Lossless Audio Compressor Win32 Version 4.41.0-beta2
Copyright © 1998 - 2006 Conifer Software. All Rights Reserved.

ave noise = -59.18 dB, peak noise = -51.82 dB
created 001__08__Help_Me_Rhonda___Beach_Boys_cut___dual_mono.wv in 1.40 secs (lo
ssy, 301 kbps)


WAVPACK Hybrid Lossless Audio Compressor Win32 Version 4.41.0-beta2
Copyright © 1998 - 2006 Conifer Software. All Rights Reserved.

ave noise = -60.85 dB, peak noise = -53.20 dB
created 001__08__Help_Me_Rhonda___Beach_Boys_cut___dual_mono.wv in 1.40 secs (lo
ssy, 243 kbps)


--------------------
Wavpack -b450s0.7
Go to the top of the page
+Quote Post
bryant
post Mar 13 2007, 07:02
Post #66


WavPack Developer


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



QUOTE (shadowking @ Mar 12 2007, 15:51) *
When encoding that sample with optimize-mono bitrate drops 60k or so. SNR is similar with or without the switch, but really should be much higher. If I add the missing 60k - i.e. change b320 to b380 I'll get what should be , I think..

That's actually the intended behavior. In the original release that supported --mono-optimize, the bitrate would drop to about half the specified bitrate and the noise would go up significantly compared to the stereo encoding, which was obviously wrong. In the newer versions the target was to keep the noise constant and let the bitrate drop (but not as much as before).

My thinking was that a worst-case scenario for this would be a track that was basically pure mono, but with an occasional sample different (in one channel) by one LSB. In this case, most blocks would be encoded in the new special mono mode, but the blocks with the single sample difference would have to be encoded in the regular stereo mode. In this case I think the ideal situation would be to have the noise remain about the same, which would mean that the bitrate would jump up in the stereo blocks because the "mono" mode is more efficient (the whole reason it exists). I think the bitrate jumping around would not be an issue, but the noise jumping around might be audible (and if it wasn't audible then why waste bits to make it even lower in the "mono" blocks?)

This way I can say that the --optimize-mono option can reduce the bitrate (in either lossless or lossy mode) with tracks that contain mono audio, but should never have any audible effect in lossy mode.

David
Go to the top of the page
+Quote Post
Josef Pohm
post Mar 14 2007, 15:03
Post #67





Group: Members
Posts: 40
Joined: 2-April 06
Member No.: 29099



QUOTE (bryant @ Mar 11 2007, 23:45) *
I have created a second beta... Thanks in advance for any testing... smile.gif


Here is some evaluation of latest WavPack binaries conducted on my PIV Prescott 2.8ghz.
Ratio is calculated on my SetF.

CODE
|      | Ratio |    4.40.00   |   4.41.0b1   |   4.41.0b2   |

|  f   | 65,66 |  96,7  115,6 | 100,4  124,4 | 102,4  137,6 |
| fx1  | 65,24 |  59,9  116,1 |  64,2  123,2 |  65,0  137,6 |
| fx2  | 65,17 |  45,1  117,1 |  49,1  123,8 |  49,4  137,6 |
| fx3  | 65,13 |  27,8  117,1 |  31,1  125,6 |  31,2  138,3 |
| fx4  | 65,08 |  12,0  114,5 |  13,5  124,4 |  13,5  139,8 |
| fx5  | 65,07 |   9,7  115,0 |  10,9  123,8 |  10,9  139,0 |
| fx6  | 65,07 |   8,3  115,6 |   9,3  123,2 |   9,3  139,8 |

|      | 64,00 |  82,0   98,1 |  85,8  105,7 |  87,0  115,0 |
|  x1  | 63,56 |  44,4   95,9 |  49,5  102,0 |  50,1  110,6 |
|  x2  | 63,51 |  29,4   95,6 |  34,0  101,6 |  33,9  111,6 |
|  x3  | 63,52 |  15,9   95,6 |  19,0  102,0 |  18,7  112,6 |
|  x4  | 63,27 |   4,3   95,9 |   5,1  100,8 |   5,1  110,2 |
|  x5  | 63,25 |   3,0   95,6 |   3,5  100,0 |   3,5  109,7 |
|  x6  | 63,20 |   1,5   91,5 |   1,8  100,4 |   1,8  105,3 |

|  h   | 62,88 |  57,1   75,4 |  64,8   74,7 |  64,8   78,8 |
| hx1  | 62,78 |  30,0   76,5 |  34,7   78,3 |  34,4   83,1 |
| hx2  | 62,70 |  18,3   76,2 |  21,9   77,8 |  21,7   82,5 |
| hx3  | 62,66 |   9,2   76,2 |  11,4   77,8 |  11,3   82,3 |
| hx4  | 62,43 |   2,6   75,4 |   3,1   77,8 |   3,1   83,1 |
| hx5  | 62,39 |   1,9   76,2 |   2,3   78,3 |   2,3   82,8 |
| hx6  | 62,38 |   1,3   76,5 |   1,6   78,3 |   1,6   83,9 |

|  hh  | 62,47 |  49,7   60,9 |  52,5   62,7 |  53,0   65,8 |
| hhx1 | 62,28 |  22,2   61,2 |  26,6   61,8 |  26,7   64,8 |
| hhx2 | 62,22 |  12,9   61,8 |  15,8   61,9 |  15,8   65,0 |
| hhx3 | 62,17 |   6,3   60,9 |   7,9   61,8 |   7,9   65,0 |
| hhx4 | 62,01 |   1,7   62,2 |   2,0   61,5 |   2,0   65,3 |
| hhx5 | 61,96 |   1,0   62,1 |   1,2   61,8 |   1,2   65,5 |
| hhx6 | 61,96 |   0,7   62,4 |   0,9   61,8 |   0,9   66,0 |


A nice 16% encoding speed improvement and 12% decoding speed improvement, when going from 4.40 to 4.41b2.
Most encoding speed improvement is achieved with 4.41b1, most decoding speed improvement with 4.41b2.
Encoding speed improvement is slightly more focused on slower modes, while decoding speed improvement is the other way round.
Go to the top of the page
+Quote Post
shadowking
post Mar 14 2007, 15:51
Post #68





Group: Members
Posts: 1527
Joined: 31-January 04
Member No.: 11664



QUOTE (bryant @ Mar 13 2007, 16:02) *
QUOTE (shadowking @ Mar 12 2007, 15:51) *

When encoding that sample with optimize-mono bitrate drops 60k or so. SNR is similar with or without the switch, but really should be much higher. If I add the missing 60k - i.e. change b320 to b380 I'll get what should be , I think..

That's actually the intended behavior. In the original release that supported --mono-optimize, the bitrate would drop to about half the specified bitrate and the noise would go up significantly compared to the stereo encoding, which was obviously wrong. In the newer versions the target was to keep the noise constant and let the bitrate drop (but not as much as before).


This way I can say that the --optimize-mono option can reduce the bitrate (in either lossless or lossy mode) with tracks that contain mono audio, but should never have any audible effect in lossy mode.

David


Thanks for the explanation.


--------------------
Wavpack -b450s0.7
Go to the top of the page
+Quote Post
Martin H
post Mar 14 2007, 16:45
Post #69





Group: Members
Posts: 857
Joined: 5-March 05
From: Denmark
Member No.: 20365



1 image file ~ 11 tracks ~ 300MB | Intel Celeron 1.7GHz. :

CODE

D:\Temp>wavpack -h *.wav

WAVPACK Hybrid Lossless Audio Compressor Win32 Version 4.40.0
Copyright © 1998 - 2006 Conifer Software. All Rights Reserved.

created Evanescence - Fallen.wv in 129.54 secs (lossless, 32.76%)

D:\Temp>wavpack441b2 -h *.wav

WAVPACK Hybrid Lossless Audio Compressor Win32 Version 4.41.0-beta2
Copyright © 1998 - 2006 Conifer Software. All Rights Reserved.

created Evanescence - Fallen.wv in 118.27 secs (lossless, 32.76%)

D:\Temp>wvunpack *.wv

WVUNPACK Hybrid Lossless Audio Decompressor Win32 Version 4.40.0
Copyright © 1998 - 2006 Conifer Software. All Rights Reserved.

restored Evanescence - Fallen.wav in 91.87 secs (lossless, 32.76%)

D:\Temp>wvunpack441b2 *.wv

WVUNPACK Hybrid Lossless Audio Decompressor Win32 Version 4.41.0-beta2
Copyright © 1998 - 2006 Conifer Software. All Rights Reserved.

restored Evanescence - Fallen.wav in 80.67 secs (lossless, 32.76%)

Result :

WavPack v4.41b2 encoded the image file 11.27 seconds faster than v4.40.

WvUnpack v4.41b2 decoded the image file 11.20 seconds faster than v4.40.


Nice work, David - and many thanks for your continued efforts, my friend smile.gif
Go to the top of the page
+Quote Post
DARcode
post Mar 15 2007, 10:17
Post #70





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




Nice improvement indeed!
Many thanks, David!


--------------------
WavPack 4.70.0 -b384hx6cmv/qaac 2.43 -V 100
Go to the top of the page
+Quote Post
bryant
post Mar 15 2007, 18:08
Post #71


WavPack Developer


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



Thanks Josef, Martin, and DARcode for the tests! smile.gif

These numbers are very much in line with what I am seeing here and I think a new release is certainly justified at this point.
Go to the top of the page
+Quote Post
Mangix
post Mar 19 2007, 05:26
Post #72





Group: Members
Posts: 591
Joined: 26-February 06
Member No.: 28077



QUOTE (bryant @ Feb 27 2007, 22:11) *
Right. Because WavPack encoding is integer-only (and generally not parallelizable) there's little or nothing to be gained by SSE and his brothers. MMX should be able to make a nice improvement because the left and right channels can be done together, but because of some optimization available for 16-bit data that doesn't work with MMX, the MMX stuff only really helps with 24-bit (and float) data.

what about for PCM Float? SSE should be able to make a nice improvement there, shouldn't it?
Go to the top of the page
+Quote Post
bryant
post Mar 21 2007, 00:44
Post #73


WavPack Developer


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



QUOTE (Mangix @ Mar 18 2007, 21:26) *
QUOTE (bryant @ Feb 27 2007, 22:11) *

Right. Because WavPack encoding is integer-only (and generally not parallelizable) there's little or nothing to be gained by SSE and his brothers. MMX should be able to make a nice improvement because the left and right channels can be done together, but because of some optimization available for 16-bit data that doesn't work with MMX, the MMX stuff only really helps with 24-bit (and float) data.

what about for PCM Float? SSE should be able to make a nice improvement there, shouldn't it?

Well, no. WavPack actually uses no floating-point operations even when operating on IEEE float data. I did this to ensure lossless operation even with slight variations in rounding behavior and to allow integer-only platforms (like Rockbox) to play IEEE float files even without an FPU.
Go to the top of the page
+Quote Post
he-jo
post Mar 21 2007, 17:34
Post #74





Group: Members
Posts: 43
Joined: 1-April 06
Member No.: 29074



Hi David,

there has been an idea in my mind for a while, and now I'd like to ask you, if you think this would be possible smile.gif

As I read it from your docs, each block in the encoded data stream is independent from the previous one. So, if two blocks have the same parameters (which should be almost always the case in your current implementation - except for ľoptimize-mono), we could decorrelate them at once with SSE2 or AltiVec, couldn't we?


Regards,
Jo.


--------------------
Joachim Henke
http://j-o.users.sourceforge.net/
Go to the top of the page
+Quote Post
bryant
post Mar 22 2007, 13:15
Post #75


WavPack Developer


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



QUOTE (he-jo @ Mar 21 2007, 09:34) *
there has been an idea in my mind for a while, and now I'd like to ask you, if you think this would be possible smile.gif

As I read it from your docs, each block in the encoded data stream is independent from the previous one. So, if two blocks have the same parameters (which should be almost always the case in your current implementation - except for ľoptimize-mono), we could decorrelate them at once with SSE2 or AltiVec, couldn't we?

I'm not completely up to speed (so to speak) on SSE2 or AltiVec, but what you suggest sounds reasonable. Unless the user specifies a -x mode, all blocks will have exactly the same sequence of terms and deltas.

I have also thought that the existing MMX code could also be used for 24-bit mono data by doing multiple blocks in parallel.

Of course, these changes would involve a lot more internal shuffling than the current stuff did. sad.gif

BTW, please feel free to e-mail me directly on your ideas. I really do appreciate your input (and work so far). smile.gif

David

edit: spelling

This post has been edited by bryant: Mar 22 2007, 13:16
Go to the top of the page
+Quote Post

4 Pages V  < 1 2 3 4 >
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 November 2014 - 19:29