[Flac-dev] Improving on Rice coding
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.
More information about the Flac-dev