[Ffmpeg-devel] Re: BUG: AC3 encode volume is low

[Justin Ruggles]

Michael Niedermayer wrote:
> Hi
> 
> On Sat, Apr 08, 2006 at 08:59:26AM -0400, Justin Ruggles wrote:
> 
>>Hello,
>>
>>Pierre Marc Dumuid wrote:
>>
>>>Hi Matthieu,
>>>Re: http://mplayerhq.hu/pipermail/ffmpeg-devel/2006-April/010010.html  
>>>As I said, I wasn't on the mailing list, (I took a peek on the logs to 
>>>see if any discussion had resulted)  Please CC me any discussion, 
>>>(though I will take a peek)
>>>
>>>Regarding there being a discussion, these discussions are quite old... I 
>>>read them, and didn't completely understand them, though I get the 
>>>feeling that nothing got committed to fix the problem.  Is the problem 
>>>unfixable?  (because a poor definition of a formula).  If so, maybe a 
>>>message should be displayed indicating the attenuation.  Alternatively, 
>>>a command argument could be used such as --use_dodgy_ac3_formula...
>>
>>IMO, neither ac3's MDCT formula nor FFmpeg's implementation of it is
>>dodgy.  
> 
> 
> i agree here
> 
> 
> 
>>You're right, though, that there was never any consensus on a
>>resolution to the issue and no fix was ever committed.  I still haven't
>>changed my opinion on the matter, although there is one thing that I am
>>not 100% sure about...
>>
>>Why does the MDCT output to a 32-bit int instead of 16-bit?  Isn't it
>>just a signed 15-bit fixed-point implementation of the formula in the
>>spec?  I can't find where the output coefficients would need to be more
>>than a 16-bit signed integer.
> 
> 
> and thats what scares me, i dont know ac3 very well, but i do know that a
> N point decorrelation style transform will generally need log2(sqrt(N)) 
> bits more at the output to maintain the same precission
> 
> 
> 
>>>From what I can tell from the MDCT code, and from the fix15() function,
>>the output coefficients should have a range of -32767 to 32767.  Thus,
> 
> 
> i dont think this is true
> 
> and as the patch is based on apparently wrong assumtations its rejected
> 
> [...]
> 


Okay.  You're right again :)  I didn't notice before that CMUL can
result in +/-65532. Hmm. Now I am stumped. The MDCT test function shows
that the fixed-point MDCT implementation matches the spec with very
little error. I'll delve a bit deeper to see if this is really a bug. It
sure would be nice to have a reference encoder for these type things.

-Justin