HDTV volume issue with VLC player using FAAD2 AAC decoder.

Seeing reports of pumping volume levels on UK DVB HD when using VLC
player I had a look and think a bug in libfaad is the reason.

I don't use VLC myself though I have tested an old version and can hear
the problem.

To report a bug I guess would need the latest - which I haven't got the
time/will to build on my old LFS system. FAAD is not an open source
project so no mailing list or current version to test. I see from the
VLC build instructions that faad 2.7 is a dependency so assume the issue
will still exist.

Get FAAD2 and the spec -
http://www.audiocoding.com/downloads.html
http://www.andyqos.ukfsn.org/AAC-13818-7.pdf

Compare the code surrounded by #ifndef FIXED_POINT in

libfaad/drc.c

with the example on p70(64) in the spec

and it seems that they tried to normalise level and apply drc (dynamic
range control) correction in one step rather than two, which works if
sign=0 (boost) but fails when sign=1.

Despite the spec saying target_level is a user setting and warning about
doing it in digital domain FAAAD2 has it fixed at 80 so -20dBfs as all
numbers are 1/4 dB steps.

Using ffmpeg with some debugging I can see the drc and program reference
levels in samples I have. 108 is the lowest I've seen 92 and 96 being
the others. This bug is worse the further away from 80 the ref level is.

A quick prog that compares the FAAD2 way with the spec way shows it
being really quite bad with level 108 as the drc goes from 0 to 1.

http://www.andyqos.ukfsn.org/faadtest.c

On linux compile with -

gcc -Wall faadtest.c -lm -o testfaad

I am surprised that there aren't more reports of this or bugs that I
could see against VLC. If I hadn't heard it my self I would suspect my
analysis was flawed.

Some programs seem to only have boost, so they won't show it and maybe
the use of drc isn't that common in the ROTW.

Any player using ffmpeg to decode AAC will work as it doesn't apply
either drc or normalise.

In article , Andy Furniss
wrote:
Seeing reports of pumping volume levels on UK DVB HD when using VLC
player I had a look and think a bug in libfaad is the reason.

I don't use VLC myself though I have tested an old version and can hear
the problem.

To report a bug I guess would need the latest - which I haven't got the
time/will to build on my old LFS system. FAAD is not an open source
project so no mailing list or current version to test. I see from the
VLC build instructions that faad 2.7 is a dependency so assume the issue
will still exist.

FWIW I did install a more up-todate version of FFMPEG. And when I use that
to rip the audio from an affected transports stream the resulting LPCM wave
file *doesn't* show the pumping in levels. But VLC continues to show them.
I'd wondered if the latest version of VLC might have sorted this. (Mine is
the default for Xubuntu 11.10, so now quite old.) But maybe not. cf
below...

Get FAAD2 and the spec - http://www.audiocoding.com/downloads.html
http://www.andyqos.ukfsn.org/AAC-13818-7.pdf

Compare the code surrounded by #ifndef FIXED_POINT in

libfaad/drc.c

with the example on p70(64) in the spec

and it seems that they tried to normalise level and apply drc (dynamic
range control) correction in one step rather than two, which works if
sign=0 (boost) but fails when sign=1.

Despite the spec saying target_level is a user setting and warning about
doing it in digital domain FAAAD2 has it fixed at 80 so -20dBfs as all
numbers are 1/4 dB steps.

OK. Noted.

Using ffmpeg with some debugging I can see the drc and program reference
levels in samples I have. 108 is the lowest I've seen 92 and 96 being
the others. This bug is worse the further away from 80 the ref level is.

A quick prog that compares the FAAD2 way with the spec way shows it
being really quite bad with level 108 as the drc goes from 0 to 1.

http://www.andyqos.ukfsn.org/faadtest.c

On linux compile with -

gcc -Wall faadtest.c -lm -o testfaad

Thanks. I'd also welcome some more info on how to use ffpmeg to get
diagnostic reports on this.


I am surprised that there aren't more reports of this or bugs that I
could see against VLC. If I hadn't heard it my self I would suspect my
analysis was flawed.

Some programs seem to only have boost, so they won't show it and maybe
the use of drc isn't that common in the ROTW.

Any player using ffmpeg to decode AAC will work as it doesn't apply
either drc or normalise.

I'll need to check, but I *think* that I installed the newer version of
FFMPEG such that it was runnable at system level. But VLC here still gave
the problem. Might I have not done this correctly? Or does VLC do something
different?

Slainte,

Jim

--
Please use the address on the audiomisc page if you wish to email me.
Electronics http://www.st-and.ac.uk/~www_pa/Scot...o/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc http://www.audiomisc.co.uk/index.html

Jim Lesurf wrote:

FWIW I did install a more up-todate version of FFMPEG. And when I use that
to rip the audio from an affected transports stream the resulting LPCM wave
file *doesn't* show the pumping in levels.

ffmpeg had its own decoder which doesn't have the bug - in fact it
doesn't do anything with the drc and program ref level metadata so you
get full range un-normalised sound.

But VLC continues to show them.
I'd wondered if the latest version of VLC might have sorted this. (Mine is
the default for Xubuntu 11.10, so now quite old.) But maybe not. cf
below...

Unless it's abandoned using FAAD2 in favor of ffmpeg for AAC I expect
current VLC still has the issue.


Thanks. I'd also welcome some more info on how to use ffpmeg to get
diagnostic reports on this.

http://www.andyqos.ukfsn.org/ffmpeg-drc-info.patch

you can use git to apply it, from your ffmpeg tree -

git apply /path/to/ffmpeg-drc-info.patch

rebuild then -

../ffplay -loglevel debug something.ts

git apply --reverse /path/to/ffmpeg-drc-info.patch

to remove as if you git pull in future it may cause a fail.


I'll need to check, but I *think* that I installed the newer version of
FFMPEG such that it was runnable at system level. But VLC here still gave
the problem. Might I have not done this correctly? Or does VLC do something
different?

VLC (unless it's changed) uses FAAD2 for AAC which is nothing to do with
ffmpeg.