[Flac-dev] Improving on Rice coding

[Miroslav Lichvar]

On Sun, Apr 27, 2003 at 07:28:48PM +1000, Paul Harrison wrote:
> On Sun, 27 Apr 2003, Miroslav Lichvar wrote:
> 
> > However, decoding will not be very fast. I think it is possible to
> > speed up bonk implementation (with some additional tables), but
> > probably it will never be as fast as decoding of rice codes.
> 
> Agreed, there's too much juggling going on to compete with rice codes, but
> maybe it can run at an acceptable speed with a bit of tuning... did you
> tell it to write the least significant bits separately (set the parameter
> base_2_part=true)? Also altering the algorithm so that low_bits is larger
> will produce a speedup (but impact the compression ratio). And there's a
> fair scope for optimization.

Interesting is that for slightly larger low_bits is compression ratio
sometimes better, at least in my case :). Maybe it takes more
iterations to adapt step variable well at beginning, if low_bits is
set too low.

Is there something better than
low_bits = bits_to_store(energy/(list.size()*2))
for optimal speed/compression_ratio ratio, maybe something with
minimum and maximum value?

> Overall, the speed (after encoding the least significant bits and
> dividing them out) is going to be of the order of the sum of the integers
> to be encoded.

Ok, but in bad case it have to loop too many (say 50) times over whole
block. This is not going to be very fast.

-- 
Miroslav Lichvar