[Ffmpeg-devel] ac3enc.c modifications
Simone Karin Lehmann
Fri May 13 00:36:04 CEST 2005
On Monday, 25. April 2005 17:55, Justin Ruggles wrote:
Oh, someone's working on ac3enc.c.... great.
> I looked back at that thread about the ac3 scaling factor. I both agree
> and disagree with Simone about scaling by 2 during the mdct. I ran a
> test using the formula directly from the specification (including the
> -2/N scaling) and got the same results (too quiet). So I don't think
> the issue is with the mdct not being correct.
Ah, the scaling thingy again...
It's not the mdct itself which isn't correct, it's the kind of scaling which
is done in there. There's a bitshift rigt in the pre rotation code, but no
bitshift left in post rotation.
Just take a look at the file mdct.c. This file implements just the same mdct
function, but without any bitshifting.
And another point is, as the specs mention, that in the decoder described in
the specs, after imdct is done, the pcm has to be mutiplied by 2, which
"undoes headroom scaling performed in the encoder". ?(page 102 of the
ATSC/A52a spec). Maybe this is an approach of the A52 standard to prevent
clippings. As I've found out, ac3 tends to reproduce signals at a slightly
higher level than the original. Depending on the source and the encoded
bitrate this is in most cases something between 0.25 db to 0.5 db on peak
levels. (Still enough to get hearable clippings if the originial has 0 dbFS
peaks). Dialog normalisation will solve this problem, but that's another
Back again to the scaling... I still think, that just dropping the bitshift
right is the best way to solve this problem.
BTW, I'm working one the same features as you do, and have succesfully
implemented rematrixing, DC filtering the input, transient detection, and to
same degree, block switching to a 256 mdct (but this still gives some high
frequency artefacts....hmm, why?), dialog normalisation (I've just patched
liba52 to use the dialog normalisation), using doubles.
In the next few days I'll post my version of ac3enc.c to the ML, so that we
can take a look at each others code.
Simone Karin Lehmann
More information about the ffmpeg-devel