Patching ac3enc of ffmpeg

[Inc]

Seems the patching of the ac3enc.c regarding the low volume has begone:

From the FFmpeg-Devel Mailing list:

Re: BUG: AC3 encode volume is low"]Hi

On Sun, Apr 09, 2006 at 07:18:54PM -0400, Justin Ruggles wrote:

>> Michael Niedermayer wrote:
>
>>> > On Sat, Apr 08, 2006 at 08:59:26AM -0400, Justin Ruggles wrote:
>>
>>>> >>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
>
>>
>> I've looked into this a little more now.
>>
>> Using floating-point math in the 512-point MDCT reference equation, and
>> taking the window function into account, it seems that the maximum range
>> of the coefficients is ± ~0.752. This would give a fixed-point range
>> of ± 24641.
>>
>> I've attached the test program I used to come to this conclusion. If
>> there is something I'm missing just let me know.


ok, you are right, the mdct implementation in ac3enc is inaccurate and
needlessly scales things down, so the patch is ok and can be applied
since that information no reports on ac3 results have been given, so maybe its time to do a compile of the latest ffmpeg snapshot and try ....

[dragongodz]

i already tried the change awhile ago with an unreleased version of QuEnc. it does raise the volume noticably both a tester and myself found. cant say if its the same as input volume as we didnt test it that exactly but it is much better and sounds close enough to me.

[Inc]

I did post a comparison on the german doom9/Gleitz board.

The first three links are the resulted audio files out of using Output_Example.exe from the ffmpeg compiling process.

The compiled binary of ffmpeg is further below compressed/provided as 7z:

http://forum.gleitz.info/showpost.php?p=263887&postcount=2

You opinion on the volumes?

[squid_80]

Could I trouble you for a link to the patch itself?

[dragongodz]

its a whole 1 line, well to be honest 1 character change. :)
http://mplayerhq.hu/pipermail/ffmpeg-devel/2006-April/010175.html

his explanation there was coonsidered wrong and so it was rejected. so then he had to write a little test program to prove what was wrong so the patch couyld be accepted.

[Inc]

Seems that Videolan (on Win and MAC) refuses to playback the resulted ac3.
Mplayer or MPC with its internal ac3 decoder do have no problems.

Can someone confirm that?

[dragongodz]

Videolan 0.8.4a plays the resulting .ac3 ,produced by QuEnc with the 1 character change, fine here.

[danpos]

Seems that Videolan (on Win and MAC) refuses to playback the resulted ac3.
Mplayer or MPC with its internal ac3 decoder do have no problems.

Can someone confirm that?

Hi Andrej! I do confirm this: VLC (I'm using on WinXP) doesn't play it properly. WinDVD and Media Player Classic haven't problems to play it correctly (I used your test.ac3 file that you provide at german D9).

Cheers,

[squid_80]

I applied the patch to fccHandler's ac3-acm codec (which uses ac3enc for encoding) and ran some tests on a 20 minute sample using cooledit's analyze statistics option.
Original: Left Right
Min Sample Value: -6480 -6532
Max Sample Value: 6546 6525
Peak Amplitude: -13.99 dB -14.01 dB
Possibly Clipped: 0 0
DC Offset: 0 0
Minimum RMS Power: -141.72 dB -141.73 dB
Maximum RMS Power: -20.39 dB -20.48 dB
Average RMS Power: -30.19 dB -30.39 dB
Total RMS Power: -28.3 dB -28.5 dB
Actual Bit Depth: 16 Bits 16 Bits

Using RMS Window of 50 ms

old ac3enc: Left Right
Min Sample Value: -3437 -3408
Max Sample Value: 3423 3466
Peak Amplitude: -19.59 dB -19.51 dB
Possibly Clipped: 0 0
DC Offset: 0 -.001
Minimum RMS Power: -106.36 dB -105.39 dB
Maximum RMS Power: -26.37 dB -26.47 dB
Average RMS Power: -36.19 dB -36.4 dB
Total RMS Power: -34.31 dB -34.51 dB
Actual Bit Depth: 16 Bits 16 Bits

Using RMS Window of 50 ms

new ac3enc: Left Right
Min Sample Value: -6935 -6982
Max Sample Value: 6905 7043
Peak Amplitude: -13.49 dB -13.35 dB
Possibly Clipped: 0 0
DC Offset: -.001 -.001
Minimum RMS Power: -99.71 dB -98.92 dB
Maximum RMS Power: -20.37 dB -20.47 dB
Average RMS Power: -30.17 dB -30.38 dB
Total RMS Power: -28.29 dB -28.49 dB
Actual Bit Depth: 16 Bits 16 Bits

Using RMS Window of 50 ms

So with the patch the output is basically the same volume as the original. Without the patch, it's about 6db softer. Big thumbs up from me.

[Inc]

Nice!

Videolan 0.8.4a plays the resulting .ac3 ,produced by QuEnc with the 1 character change, fine here.
which snapshot did u use when compiling? As also some other changes have been done according to mdct data type.

My sample was just outputted by the output_example.exe which also results when compiling ffmpeg. Maybe its a bug in output_example.c out of a recent change in that code also? Hmmmm ...

So with the patch the output is basically the same volume as the original. Without the patch, it's about 6db softer. Big thumbs up from me.
What about your encodings and VLC playback compilance? Did u use the ffmpeg.exe binary I provided to generate the ac3 streams or did u also like dragongodz simply apply that "one" character patch by yourself?



Someone tested the 5.1 output? Im at work now so I cant do it by myself :)


If things are getting clear, maybe we also should give a hint to DspGuru so he can update the ac3enc.dll for BeSweet/BeLight

[dragongodz]

which snapshot did u use when compiling?
its a couple of months old. that shouldnt be a factor in if that change fixes the ac3 volume however.

As also some other changes have been done according to mdct data type.
again this shouldnt have had the effect of producing bad files though. you could try checking out an older version and making the changes 1 at a time yourself and see if they cause a problem then. you could also undo the changes with your current checkout and see if the produced ac3 is ok.

Someone tested the 5.1 output?
yes i tested that too. also got the volume increase. again though i used QuEnc with the change. ;)

Maybe its a bug in output_example.c out of a recent change in that code also?
cant say but i find it doubtful that these changes suddenly caused the problem.

[squid_80]

All I did was get the source (http://fcchandler.home.comcast.net/AC3ACM/) to ac3acm and patch the single line in ac3enc.cpp. Encoding was done with virtualdub. I don't have VLC installed so I can't test it, sorry.

Wouldn't the best way to check the output streams be to play them on a stand alone player? They seem to be the most "picky" about ac3 in my experience.

[Inc]

Thanks :),
ok, so you all just corrected that single character on an older ffmpeg source.
I posted the actual CVS compile -> VLC Playback issue in the ffmpeg-dev mailing list. Anyhow, that should be fixed.

[Inc]

Whats the correct way compiling a new version of ac3enc.dll for besweet/belight???

I got the ac3enc sources from DspGuru's Homepage but I'm not able to compile it properly. It starts with the issue that within ac3enc.c the functions are set to "static" so the linker wont be able to link it!? I get unresolved external symbols of exactly these functions. If I do change these ones in ac3enc.c from static to extern then the compile is done but an ac3enc.dll resulting in about 1.9Mb is the result and Besweet.exe cant access the ac3enc interface.

[BigDid]

I would appreciate to use that patched/debugged version but cannot help for compiling.

Kurtnoise maybe?

Did