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

[Justin Ruggles]

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