[FFmpeg-devel] [PATCH] E-AC-3 spectral extension

[Benjamin Larsson]

Justin Ruggles wrote:
> Benjamin Larsson wrote:
>   
>> Michael Niedermayer wrote:
>>     
>>> On Sat, May 30, 2009 at 11:43:12PM -0400, Justin Ruggles wrote:
>>>  
>>>       
>>>> Michael Niedermayer wrote:
>>>>    
>>>>         
>>>>> On Sun, May 17, 2009 at 02:23:34PM -0400, Justin Ruggles wrote:
>>>>>      
>>>>>           
>>>>>> Hi,
>>>>>>
>>>>>> I was recently made aware that some French TV station(s) will soon (if
>>>>>> not already) start using E-AC-3 streams in their broadcasts which
>>>>>> utilize spectral extension.  I was also given some samples (thanks j-b
>>>>>> and Anthony), which I uploaded to mphq:
>>>>>> http://samples.mplayerhq.hu/A-codecs/AC3/eac3/csi_miami_*
>>>>>>
>>>>>> So I decided to revisit my SPX patch.  The previous version was done
>>>>>> with all integer arithmetic, but it turns out that it's really not
>>>>>> accurate enough for spectal extension processing.  The resulting
>>>>>> decoded
>>>>>> output had a max bandwidth of about 2kHz less when using 24-bit fixed
>>>>>> point vs. floating point, and was only slightly higher than without
>>>>>> any
>>>>>> SPX processing at all.  Making just the square roots floating point
>>>>>> raised the bandwidth about 1kHz, and making the rest (noise/signal
>>>>>> scaling, spx coords, and notch filters) floating point added about
>>>>>> another 1kHz.
>>>>>>
>>>>>> I was able to compare the output to Nero's E-AC-3 decoder (thanks
>>>>>> madshi), and the results are very close considering that AC-3 uses
>>>>>> random noise for zero-bit mantissas:
>>>>>>         stddev:  131.16 PSNR: 53.96
>>>>>>         
>>>>>>             
>>>>> i wouldnt call 131.16 close
>>>>>       
>>>>>           
>>>> Well, considering I don't know how the Nero decoder differs, it's not
>>>> bad.  I don't know how the Nero decoder ends up with higher bandwidth
>>>> than it should, it very likely uses a different random noise generator,
>>>> and it could do dithering in the float-to-int16 conversion.
>>>>     
>>>>         
>>> dither in float2int might account for ~1.0 stdev maybe but we are 2
>>> magnitudes above that.
>>>
>>> about the PRNG, well just decode a AC3 with 2 different PRNGS and compare
>>> by how much they differ
>>>
>>> also you can take neros output and ours and create a wav file with the
>>> sample wise differences.
>>> looking at that / listening to it might provide a hint about what is that
>>> differs.
>>>   
>>>       
>> My guess is a sample delay. I know Siarhei wrote some patch for
>> tiny_psnr to calculate that.
>>     
>
> hmmm, looks like you were right... off by 1.  After resyncing, this is
> the result:
> stddev:   19.75 PSNR: 70.41 bytes:  3998720/  3999744
>
> -Justin
>   

A PSNR of 70 is quite good from what I remember.

MvH
Benjamin Larsson