Automatic gain mode problem

[TCmullet]

When I reencode audio, it's to AAC (lav).  (I wish I knew a reason to pick lav vs FDK; I can't seem to find any documentation about that issue.  But I am using lav and it seems to be okay.)  There are times I need to boost the audio.  As there is no GUI for seeing the waveform, I can't boost a fixed db as then I'd have to export to .wav and load to a wav editor to SEE whether my guess of boost db was appropriate.  If not okay, then try another value.
This wastes scads of time.  But when I use automatic, it maxs out at -3db. As the peaks I have are rather transient and severe, the overall effect is to not boost it ENOUGH.  I would like the ability to use some other maximum value, such as -1 or 0.  Maybe even a plus value.  Is the -3 stored in the registry somewhere?  I am very comfortable making registry changes as long as the labels and values straight forward.  Isn't there a list somewhere of ALL settings that are configurable in the registry but not settable within the Avidemux GUI?  There should be, IMHO.  (Or if not, then make this "auto gain" a user configurable setting.  ANY db value for Max should be settable, please.)

[Jan Gruuthuse]

or you could use:
- Latest Version of Audacity
- FFmpeg import/export library <= required
–– Allows Audacity to import and export many additional audio formats such as AC3, AMR(NB), M4A and WMA, and to import audio from video files.
Then just drag and drop on to audacity canvas

apply filter
- normalize 0 dB
- Amplify

export

[TCmullet]

It's all those extra steps (and they are very time consuming) that I'm trying to avoid and wish to avoid by having Avidemux allow control over that hard -3db value.

What I have to do now is actually easier than Audacity.  Avidemux-->export to wav.  Load wav to my fav Cooledit, Normalize.  Import back to Avidemux. SO much more work than audio-reencode WITHIN Avidemux.  (My files are huge, and there are many of them. so each of these numerous steps is big and they add up.  They add up so badly that I often am forced to decide NOT to improve the sound simply due to lack of adequate time.)  The -3db really should be configurable, whether in the GUI, an .ini file, or a registry entry.  So easy to implement, yet would save SO much time.

[eumagga0x2a]

While they are not, you could get the desired higher value instantly by modifying the line avidemux/common/ADM_audioFilter/src/audiofilter_normalize.cpp:142 accordingly and building Avidemux from source. This is trivial on Ubuntu and easy on any other current Linux distribution. This is considerably more complicated on Mac and almost unfeasible on Windows (Avidemux for Windows is cross-compiled on Linux).

[TCmullet]

I have VS 2008 and could get VS 2010 (or whatever the current one is).  If ADM exists as a VS solution (.sln) already and I could plop it in, make the one line change and compile, I'd do it.  But beyond that, I'm not able.  I really hope you'll make this very valuable addition to Avidemux, esp. as conceptually, it should be a very simple addition, once you can decide on which way you want to store the auto-db value.  (Any way you can store it and allow us to set it and leave it set for all our runs would be very acceptable.)

[eumagga0x2a]

conceptually, it should be a very simple addition

[audioFilter/normalize] Make max level in automatic gain mode customizable

But the merge will be probably reverted as the necessary scripting API change breaks compatibility to existing project scripts and people will face ugly tinyPy error dialogs popping up.

[Jan Gruuthuse]

Max level in automatic gain mode customizable by eumagga0x2a:

[eumagga0x2a]

The problem is that all project scripts created with earlier Avidemux versions (practically all, including the currently latest official nightlies) which include audio filter normalize will trigger an error message and won't load properly.

[TCmullet]

WOW, I just saw the screen shot of Jan's.  THANK YOU, Eumagga0x2a!  I didn't see it before because I carelessly looked at only your comment.  I didn't realize you made that "problem is" comment AFTER adding the feature (which Jan had just reported but I had not looked upward just one silly little message).  I discovered it in my current program by trying it for first time in ages.  Again, THANKS!  (And I hope it doesn't cause severe problems for too many.)

[eumagga0x2a]

You're welcome.

And I hope it doesn't cause severe problems for too many.

No, presumably not, as feared issues were preempted by [tinyPy] Rename method to set audio gain to stay compatible with scripts created by older versions the day after.

[AlanD]

There is a minor bug in the Windows version of manual gain mode where it loses the decimal part of the manual gain, i.e. you can set it to 1.50db, but next time you look it has reset itself back to 1.00db. I am pretty sure that an earlier version worked fine to two decimal places, and did apply the requested gain accurately, so I suspect this bug is just an interface error with something declared as an integer instead of a float. The two decimal places in the maximum value field when in automatic mode works fine.

[eumagga0x2a]

Good catch, now fixed (for gcc, not checked with Apple clang yet), thanks.