[Ffmpeg-devel] ac3enc.c modifications

[Michael Niedermayer]

Hi

On Thursday 19 May 2005 21:13, Rich Felker wrote:
> On Thu, May 19, 2005 at 12:30:32PM -0400, Justin Ruggles wrote:
> > Simone Karin Lehmann wrote:
> > > sample_t was intended to switch between doubles and integers at compile
> > > time, but I didn't finish to fully implement the integer code. This is
> > > why you get silence.
> >
> > Oh, ok.  Now it makes sense.
> >
> > > ... but the calculations to get these values will be more accurate if
> > > you use doubles. In mdct() there are plenty of multiplications using 
> > > sin and cos factors. Only using integers will give some really great
> > > rounding errors. I've done a lot of testing to this. First I encoded a
> > > wav file only using integers, decoded it back to wav, took audicity to
> > > give me spectrum analysis. Second I did the same procedure with
> > > doubles.
> > > The spectrum resulting out of the doubles encoding was more closely to
> > > original than only encoding in integer arithmetics.
> >
> > I can see where that would work.  Since it uses summations, the rounding
> > errors would just keep adding up.  And if you're going for accuracy over
> > speed, using floating-point would help.  How does the spectrum vary
> > between using floats vs. doubles?
> >
> > I was going to suggest keeping mdct_coefs as int32 and just using
> > doubles internally in the mdct, but the rematrixing would get a very
> > slight accuracy gain with floating point as well.
>
> Float should be removed entirely and replaced with 32bit int. There's
> nowhere it makes any difference to quality and the latter is much
> faster, and also has the benefit of being well-defined (float behavior
> is somewhat implementation-defined and will not pass regression
> tests).

both float and int should be supported, there are people with cpus where float 
IS faster then int and int generally requires some care to avoid overflows 
while maintaining good precission which will result in some shifts the float 
implementation doesnt need

just look at multiplications if you have fixed point ints with n and m 
fractional bits a simple a*b will have n+m fractional bits that would very 
quickly need some right shift and even if you do a right shift immediatly it 
will seriously limit precission, now you can do (a*(int64_t)b)>>32) and hope 
that the cpu architecture has a fast instruction for that and that the 
compiler is smart enough to use it, but still its quite limiting
for example if you multiply with a constant which is the most common use of 
multiplications and you want to maintain the number of fractional bits then 
your constant is limited to -0.5 ... 0.5

[...]
-- 
Michael