[Ffmpeg-devel] ac3enc.c modifications
Thu May 19 21:53:33 CEST 2005
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
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
More information about the ffmpeg-devel