[FFmpeg-devel] [PATCH] ALAC Encoder

[Justin Ruggles]

Hi,

Michael Niedermayer wrote:
> anyway, some further ideas:
> * as ALAC dynamically adapts the LPC coeffs its not optimal to calculate
>   the best ones for the whole block with equal weighting for each sample.
>   for example if i simply just calculate them based on the first 1/4 of
>   the block, compression (and speed) improves.
>   That surely is an area that should be investigated, maybe using some
>   asymetric and at the right side exponentially decaying window instead
>   of the welch window ...

That is really interesting.  Did this happen with a variety of samples
with different types of audio?  I have never tried an asymmetric window.
 I did test various symmetric windows, and welch had a good overall
speed/compression trade-off.  I will be glad to run some tests.

> * regression tests, ive totally forgotten about them, but each new encoder
>   should be added to them, i think alac hasnt been yet ...

Jai, it would probably be good to use the 1st order prediction for the
regression test to avoid floating-point.  Or it might be nice to add a
compression_level option for using your previous 4th order fixed coeffs,
which would be better for regression tests than the 1st order prediction
since they cover more of the code.

> * more decorrelation types could be tried at higher compression_level

Do you mean testing for more intervals between left, mid, and right?
That could be interesting.  I tried something to calculate the left
weight on a scale of 0 to 1, but it was not as good as just testing the
4 types and comparing the sum of residual.  Maybe something better could
be devised instead of (or in addition to) adding more types.

> * rice_modifier
>   ive missed this parameter totally because it is not used in the encoder
>   but instead just replaced by a litteral number where its used.
>   This should also be fine tuned for each frame

Jai touched on this in his response.  He and I have discussed some
things which might work here.  The history modifier basically controls
the decay rate of the entropy coding context, so it sort of defines a
decaying window which determines the rice parameter.  FLAC does
something similar in that it allows the encoder to optionally split the
entropy coding windows into smaller sizes.

For ALAC, one idea could be to test to see how the rice params generated
by different history modifier values compare to optimal rice params when
breaking the frame down to different window sizes.

Another idea might be to iterate through the samples and generate a set
of rice params for various history modifier values.  Estimating the
number of bits for each should be fairly easy, but might get a little
tricky with the funky auto-RLE mode.  A brute-force method is still an
option if it improves compression significantly.

Any other ideas for these are welcome!

Thanks,
Justin