IPB

Welcome Guest ( Log In | Register )

 
Reply to this topicStart new topic
--blocksize: info on its impact on strength and how to use correctly?, Was: --blocksize (TOS #6)
_m_
post Feb 6 2012, 21:02
Post #1





Group: Members
Posts: 231
Joined: 6-April 09
Member No.: 68706



Recently I discovered --blocksize.
Bryant, could you tell some more about its impact on strength and how to use it correctly?
I saw some topics mentioning that setting it very low can have positive impact on some sources.
I tried the opposite, setting it to maximum on my quick and dirty high-res, multichannel dataset and it turned out to be slightly better than default, 0.05% on average, winning on 22 of 29 samples. Still, it was 0.71% worse than flake. Taking the best result from default / --blocksize reduced the flake's advantage to 0.63%.
Go to the top of the page
+Quote Post
bryant
post Feb 7 2012, 21:01
Post #2


WavPack Developer


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



Increasing the block size from the default will normally improve compression slightly (as youve seen) because the overhead of the block header becomes a smaller and smaller percentage of the total data size. However, there are negative implications of this and so I would not recommend it unless you are just archiving and going for the best possible compression ratio. The problem is that the resulting files require more memory to play (especially multichannel files) and some players (like Ffmpeg) might refuse to play them at all. I have even been considering reducing the default block size for some modes to reduce the playback memory footprint even though it might reduce compression slightly.

The times that setting a low block size improves compression is only in situations where there is redundancy in the LSBs of the audio samples. The only two cases of this that I know of are files from LossyWAV and decoded HDCD files, but there might be others. In the cases where the amount of redundancy is changing often, using smaller blocks help WavPack take advantage of this, and of course with LossyWAV you simply want the block size to match the block size that LossyWAV is using. Note that the --merge-blocks option must be used with --blocksize to get this.

The easiest way to get better compression is to use the -x switch. Although this can be very slow during encoding, there is no cost during decoding. I would start with -x4 to get an idea how much improvement you might get. Of course, -h and -hh improve compression too, but those will result in somewhat slower decoding.
Go to the top of the page
+Quote Post
_m_
post Feb 7 2012, 21:40
Post #3





Group: Members
Posts: 231
Joined: 6-April 09
Member No.: 68706



Thanks for the answer. All the numbers that I gave were with -hhx6. Which is what I call 'rather fast', but 'week/very week'.
I'll have to consider increasing blocksize, do some testing etc. While the main use is archival, portability is worth something too and the gains seem tiny.

This post has been edited by _m_: Feb 7 2012, 21:41
Go to the top of the page
+Quote Post
DARcode
post Feb 8 2012, 10:16
Post #4





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



-hhx6 rather fast?! Are you using a supercomputer?


--------------------
WavPack 4.70.0 -b384hx6cmv/qaac 2.41 -V 100
Go to the top of the page
+Quote Post
_m_
post Feb 8 2012, 20:24
Post #5





Group: Members
Posts: 231
Joined: 6-April 09
Member No.: 68706



QUOTE (DARcode @ Feb 8 2012, 10:16) *
-hhx6 rather fast?! Are you using a supercomputer?

Nah. It's a matter of throughput and latency. Slow compression increases the time from getting some music to having it integrated with the library. That's latency. But for the throughput, the bottlneck is me. I don't acquire music faster than my computer compresses it. For this reason I have most of my library compressed with OptimFrog --bestnew --optimise best. I call it 'very slow', but wavpack is still rather fast in comparison. smile.gif
I'm moving to wavpack because OptimFrog is not portable enough. And I find wavpack to be the most reliable portable codec around.

This post has been edited by _m_: Feb 8 2012, 20:26
Go to the top of the page
+Quote Post
bryant
post Feb 8 2012, 20:50
Post #6


WavPack Developer


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



QUOTE (_m_ @ Feb 7 2012, 12:40) *
All the numbers that I gave were with -hhx6.

Ah, okay. I'm surprised that Flake gives better compression than that. I'm on Flake 0.10-3 (with -12) and it's consistently worse than WavPack's best, but perhaps there were compression improvements in later versions.

Anyway, I'm glad WavPack is working out for you. smile.gif
Go to the top of the page
+Quote Post
Porcus
post Feb 8 2012, 20:53
Post #7





Group: Members
Posts: 1842
Joined: 30-November 06
Member No.: 38207



QUOTE (_m_ @ Feb 8 2012, 20:24) *
I don't acquire music faster than my computer compresses it.


And if that yardstick does not make spouse realize that your shopping is well within reason ... laugh.gif


--------------------
One day in the Year of the Fox came a time remembered well
Go to the top of the page
+Quote Post
_m_
post Feb 8 2012, 22:48
Post #8





Group: Members
Posts: 231
Joined: 6-April 09
Member No.: 68706



I used SVN version of flake and it's significantly better than the latest release. For my limited experience, compared to wavpack -hhx6, it's weaker on stereo, but stronger on multichannel audio.
Go to the top of the page
+Quote Post

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: 30th July 2014 - 15:24