flac dev - Jun 2014 - [PATCH] stream_encoder : Improve selection of residual accumulator width

On Fri, Jun 20, 2014 at 01:21:03PM +0400, lvqcl wrote:
> Miroslav Lichvar ?????:
> 
> > +/*
> > + * This is used to avoid overflow with unusual signals in 32-bit
> > + * accumulator in the *precompute_partition_info_sums_* functions.
> > + */
> > +#define FLAC__MAX_EXTRA_RESIDUAL_BPS 4
> 
> > +		/* WATCHOUT: "+ bps + FLAC__MAX_EXTRA_RESIDUAL_BPS" is
the maximum
> > +		 * assumed size of the average residual magnitude */
> > +		if(FLAC__bitmath_ilog2(default_partition_samples) + bps +
FLAC__MAX_EXTRA_RESIDUAL_BPS < 32) {
> 
>  From FLAC__fixed_compute_residual:
>      residual[i] = data[i] - 4*data[i-1] + 6*data[i-2] - 4*data[i-3] +
data[i-4];
> 
> so max(residual[i]) == 16 * max(data[j]), or:  max_bps(residual[]) == 4 +
max_bps(data[]).
> 
> Am I right that it's the reason why FLAC__MAX_EXTRA_RESIDUAL_BPS is
equal to 4?
Not really, it's just a guess. With LPC the maximum possible residual
could be much larger than with the fixed predictor if the coefficients
were chosen randomly, but the autocorrelation routine should keep them
more reasonable. The snippet6.wav file needed 2, so I made it slightly
larger to have some extra room.

As overflow in the accumulator won't result in a data loss, I think
this is good enough until someone can figure out a better approach.

-- 
Miroslav Lichvar

Miroslav Lichvar wrote:
>>  From FLAC__fixed_compute_residual:
>>      residual[i] = data[i] - 4*data[i-1] + 6*data[i-2] - 4*data[i-3] +
data[i-4];
>>
>> so max(residual[i]) == 16 * max(data[j]), or:  max_bps(residual[]) == 4
+ max_bps(data[]).
>>
>> Am I right that it's the reason why FLAC__MAX_EXTRA_RESIDUAL_BPS is
equal to 4?
>
> Not really, it's just a guess. With LPC the maximum possible residual
> could be much larger than with the fixed predictor if the coefficients
> were chosen randomly, but the autocorrelation routine should keep them
> more reasonable. The snippet6.wav file needed 2, so I made it slightly
> larger to have some extra room.
>
> As overflow in the accumulator won't result in a data loss, I think
> this is good enough until someone can figure out a better approach.

I see.

FLAC calculates real bitdepth of input signal for every block. Is it
feasible to calculate real bitdepth of residual signal and use this
value instead of (bps + 4) ?

On Fri, Jun 20, 2014 at 02:15:31PM +0400, lvqcl wrote:
> Miroslav Lichvar wrote:
> > As overflow in the accumulator won't result in a data loss, I
think
> > this is good enough until someone can figure out a better approach.
> FLAC calculates real bitdepth of input signal for every block. Is it
> feasible to calculate real bitdepth of residual signal and use this
> value instead of (bps + 4) ?
That would be expensive and I'm not sure if it's worth the cost. It
could be a separate function or it could be integrated in the
fixed and LPC encoding functions. The later would be probably faster,
but it would require patching the assembly code.

-- 
Miroslav Lichvar