[Flac-dev] Improving on Rice coding

Miroslav Lichvar lichvarm at phoenix.inf.upol.cz
Mon Apr 28 02:16:04 PDT 2003

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

More information about the Flac-dev mailing list