[Ffmpeg-devel] ac3enc.c modifications

[Simone Karin Lehmann]

On Tuesday, 17. May 2005 16:05, Justin Ruggles wrote:

> I've been looking over your changes, and I like a lot of what you've
> done.  Before I go into my comments on specific sections, I have a
> couple more general questions.
>
> Simone Karin Lehmann wrote:
> > /* use double prec */
> > #define AC3ENC_DOUBLE
> >
> > #ifdef AC3ENC_DOUBLE
> > typedef double sample_t;
> > #else
> > typedef int16_t sample_t;
> > #endif
>
> Is the use of sample_t meant to allow different data types?  When I take
> out the "#define AC3ENC_DOUBLE", I get silent output.  So is the intent
> to always use double and just call it sample_t or to use sample_t as a
> way to allow either integer or floating-point processing?

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.

>
> Secondly, I don't see where there's much, if any, benefit to using
> double precision.  The ac3 format doesn't encode the data nearly that
> precisely.  
yes, that's right. ac3 itself only stores 24-bit values....

> Right now, your code converts the doubles to int32s before
> encoding both the exponents and mantissas, so the precision is lost
> anyway.  Using 32-bit integers seems plenty accurate to me.  

... 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.

> An idea I
> saw that you used in the MDCT might be able to be used more generally.
> If the 16-bit input data is converted to 24-bit data wrapped in an int32
> from the beginning, then it would increase the accuracy without
> unnecessary floating-point arithmetic.

This will give some more bits even to samples which are near 0 dbFS.

> Briefly, some of the things I like.
> -adjusting the bandwidth to the bitrate (much needed!)
> -zeroing out the data above used bandwidth
> -the 8kHz filter for the transient detect
> -dialog normalization

:-)

Simone Karin