[FFmpeg-devel] [PATCH] ALAC Encoder
Fri Aug 22 03:09:07 CEST 2008
Justin Ruggles wrote:
> 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
3- decode file.mp4 and fail if it has not exactly the same data as the
Any reason why this is not the default procedure?
More information about the ffmpeg-devel