[Flac-dev] Improving on Rice coding

[Paul Harrison]

On Mon, 28 Apr 2003, Miroslav Lichvar wrote:

>
> 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.
>

If the values being encoded are small, it's possible it is adapting to
changes in the frequency of particular values over time :-)

> Is there something better than
> low_bits = bits_to_store(energy/(list.size()*2))

                     Well, this parameter here ^ may be adjusted, maybe
even low_bits = bits_to_store(energy*whatever/list.size()) instead.

There may be a level that gives an optimial tradeoff between adapting to
the distribution and adapting to changes over time. I haven't really
investigated this.

> for optimal speed/compression_ratio ratio, maybe something with
> minimum and maximum value?
...
> 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.
>

Actually, that's just my shoddy unoptimized code. It should be possible to
make it always run in the order of the sum of the values, so the above
measure is quite good. The trick would be to keep a list of indicies of
the items that are still above the current cutoff value, and remove
indicies from this list as they fall below the cutoff.

Paul

Email: pfh at csse.monash.edu.au

one ring, no rulers, thecircle.org.au