[FFmpeg-devel] [PATCH] RealAudio 14.4K encoder

[Francesco Lavra]

On Tue, 2010-05-25 at 20:01 +0200, Michael Niedermayer wrote:
> On Tue, May 25, 2010 at 07:48:23PM +0200, Francesco Lavra wrote:
> > On Mon, 2010-05-24 at 02:53 +0200, Michael Niedermayer wrote:
> > > On Sun, May 23, 2010 at 08:52:30PM +0200, Francesco Lavra wrote:
> > > > I'd say we should go for the fast gain qantization, and in attachment is
> > > > an cleaned up patch for it, with code duplication removed.
> > > 
> > > the attached code looks like float brute
> > 
> > Yes, it is brute force, but it's the faster version: instead of
> > LP-filtering the sum of the 3 codebook vectors for each gain
> > quantization value, LP filtering is done only once for each of the 3
> > vectors (in floating point) and the search is done with the sum of the
> > filtered vectors.
> 
> yes and the variant that in addition tries the 5 best of that in integers
> and correct rounding produced worse psnr for some files, thats impossible
> correct rounding should always be better
> so either iam missing something (very possible) or i misremember the scores
> or theres a bug

While it seems strange, I think that's not impossible. Choosing a given
gain value for a subframe affects the output of the next subframe too,
and a choice based on integer calculations, while being the best for the
current subframe, might not be the best "in the long run".
>From the PSNR values I reported, you can see that in some cases even the
brute force approach (doing integer LP-filtering for all 256 gain
values) gives worse results than the fast one; but in any case, the
differences between the values are rather small.
In case you are still skeptical on this, I attach the file with the
variant that tries the 5 best values (sorted using quicksort), so if you
want you can take a look at it and spot any (very unlikely :P) bugs.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ra144enc.c
Type: text/x-csrc
Size: 20230 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100528/ecf09878/attachment.c>