[FFmpeg-devel] [PATCH] ALAC Encoder

[Vitor Sessak]

Justin Ruggles wrote:
> 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.

I'd like to protest against the idea of checking the md5sum of the 
generated alac files. It has the following downfalls:

1- Cannot check any code that uses floating-point
2- Breaks when a change that improves compression is made
3- Is of no use for the more subtle kind of regression: a change that is 
supposed to improve compression (and hence change the md5sum) but 
actually make it worse

I propose the following:

1- do "ffmpeg -i file.wav file.mp4"
2- check the size of file.mp4 and fail if it is greater than a certain 
amount
3- decode file.mp4 and fail if it has not exactly the same data as the 
original file.was

Any reason why this is not the default procedure?

-Vitor