flac dev - Jul 2014 - Residual bps and encoding speed

I changed the condition in *_precompute_partition_info_sums_*()
functions from
     if(bps <= 16)
to
     if(FLAC__bitmath_ilog2(default_partition_samples) + bps < 32)

and then changed the 'subframe_bps' argument of
find_best_partition_order_()
in evaluate_fixed_subframe_() and evaluate_lpc_subframe_() as follows:

    evaluate_fixed_subframe_():    evaluate_lpc_subframe_():
1) subframe_bps + order           subframe_bps + 0
2) subframe_bps + order           subframe_bps + 2
3) subframe_bps + order           subframe_bps + 4
4) subframe_bps + 4               subframe_bps + 4

Version 0 hangs during encoding. So Miroslav was right, it is necessary
to increase bps for lpc subframes as well. Versions 1...3 have identical
encoding speed. So it's possible to play safe and just choose
"subframe_bps + 4" in both cases. This is equivalent to the patch in
http://lists.xiph.org/pipermail/flac-dev/2014-June/004771.html
(this patch also adds 4 to subframe_bps, but in different place).

So I think it's a matter of taste which patch to prefer: this --
http://lists.xiph.org/pipermail/flac-dev/2014-June/004771.html
or this --
http://lists.xiph.org/pipermail/flac-dev/2013-July/004303.html

lvqcl wrote:
> I changed the condition in *_precompute_partition_info_sums_*()
> functions from
>      if(bps <= 16)
> to
>      if(FLAC__bitmath_ilog2(default_partition_samples) + bps < 32)
> 
> and then changed the 'subframe_bps' argument of
find_best_partition_order_()
> in evaluate_fixed_subframe_() and evaluate_lpc_subframe_() as follows:
> 
>     evaluate_fixed_subframe_():    evaluate_lpc_subframe_():
> 1) subframe_bps + order           subframe_bps + 0
> 2) subframe_bps + order           subframe_bps + 2
> 3) subframe_bps + order           subframe_bps + 4
> 4) subframe_bps + 4               subframe_bps + 4
> 
> Version 0 hangs during encoding. So Miroslav was right, it is necessary
> to increase bps for lpc subframes as well. Versions 1...3 have identical
> encoding speed. So it's possible to play safe and just choose
> "subframe_bps + 4" in both cases. This is equivalent to the patch
in
> http://lists.xiph.org/pipermail/flac-dev/2014-June/004771.html
> (this patch also adds 4 to subframe_bps, but in different place).
> 
> So I think it's a matter of taste which patch to prefer: this --
> http://lists.xiph.org/pipermail/flac-dev/2014-June/004771.html
> or this --
> http://lists.xiph.org/pipermail/flac-dev/2013-July/004303.html
I much prefer the second version because its such a trivial patch.

Howver, exactly because it is such a trivial patch it would be
easy for someone to remove the "+ 4" again and break it.

Before I commit this, I'd like to have a test that triggers this
problem. Let me work on that.

Erik
-- 
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/

Erik de Castro Lopo wrote:
> I much prefer the second version because its such a trivial patch.
Actually, no, the second is better because its explicit and has
comments.
 
Erik
-- 
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/