0

I am using the ffmpeg-normalize tool to normalize the relative volume of some AAC (extension .m4a) audio files. Often the output file is much larger than the input one, but I thought ffmpeg by default figured out an appropriate output bitrate based on the input bitrate.

Here's a file before using ffmpeg, and here it is afterwards. In this example, the former is 125kbps, and the latter is 280kbps. The second file was generated with

ffmpeg-normalize file1.m4a -t 32 -f -c:a libfdk_aac -o file2.m4a

Any idea why the bitrate is so enlarged after processing with ffmpeg and ffmpeg-normalize?

Luke Davis
  • 293
  • 3
  • 10
  • 1
    Does this help: https://superuser.com/questions/859220/does-ffmpegs-aac-encoder-need-a-audio-bitrate ? It seems the AAC filter you are choosing to output to default to 128 1kBit/s – Kinnectus May 03 '19 at 14:24
  • It did, tested with a simple ffmpeg command `ffmpeg -i file1.m4a -c:a libfdk_aac file3.m4` and indeed the output is around 128kbps. This seems to be specific to `ffmpeg-normalize`. Perhaps will post an issue. – Luke Davis May 03 '19 at 17:59

1 Answers1

0

Rather than transcoding the files, which will incur generation loss, why not use a lossless (effectively) method such as various Replaygain implementations?

That way there is no change in bitrate and no potential loss of quality, assuming your gain is below clipping.

By default replaygain will insert tags that tell the player program what gain it should apply, but for formats such as mp3 and AAC there is also the ability to modify the "gain" data within each block to make it louder or quieter without affecting the actual encoded data at all.

To work with replaygain there is foobar2000 which supports the Replaygain algorithm and can additionally apply the calculated gain losslessly to the raw mp3 or aac (mp4) data without transcoding:

  • MP3: Values written to ID3v2 (default) or APEv2 tags. A separate function can be invoked to apply the tagged Track or Album Gain to the MP3 global gain fields (as MP3Gain does), and rewrite any existing tags to account for the peak change and compensate for the difference from 89 dB.
  • AAC: Values written to APEv2 tags. As with MP3, it is also an option to apply gain via a separate function.
Mokubai
  • 89,133
  • 25
  • 207
  • 233
  • Unfortunately I'm on a mac, so foobar2000 is not an option. But thanks for the info. I think hardcoding the audio gain instead of relying on a playback tool is necessary for me. – Luke Davis May 03 '19 at 14:39
  • @LukeDavis there is some instructions on how to build [AACGain](http://aacgain.altosdesign.com) which is a command line program to achieve the above. The instructions are at http://macappstore.org/aacgain/ It appears to boil down to "install homebrew and then `brew install aacgain` ... " – Mokubai May 03 '19 at 14:46
  • @LukeDavis my advice isn't to just calculate it and apply in software later either, mp3 and aac audio can have the block gain directly modified without affecting the audio data in the block. Net result is *hardcoded* gain and no loss. The benefit is that it saves CPU time transcoding (which will need at least two decode passes, one to calculate peak and one for on-the-fly decode and one encode) this method is much faster because it is only one decode pass and some file data modification. – Mokubai May 03 '19 at 15:13
  • But this still requires that the player supports ReplayGain metadata, and apparently the options for Mac are [limited/outdated](https://en.wikipedia.org/wiki/ReplayGain). And I use [Swinsian](https://swinsian.com) rather than iTunes so "iGain" is not an option. – Luke Davis May 03 '19 at 17:42
  • Also I **very much dislike** that disclaimer about potentially corrupting the AAC files... I suppose I could switch to encoding to mp3, but most of my originals are from youtube and are in `m4a` by default so doesn't it make more sense to keep the `m4a` format? – Luke Davis May 03 '19 at 17:45
  • Also I just checked and the last modified date of the AACGain webpage is 2012... really do not want to depend on inactive/abandoned projects when `ffmpeg` is heavily used and will be for the forseeable future, and `ffmpeg-normalize` is really just a thin wrapper around that tool. I guess I recognize that ReplayGain makes sense as a standard but it seems to just not be currently practical for my situation. – Luke Davis May 03 '19 at 17:48
  • @LukeDavis You're welcome to use whatever methods you like, but ffmpeg is massively wasteful when faster and more efficient methods are available. I know that "CPU time is cheap" these days, but so are unrecyclable single-use containers and look where that is getting us. Once you have applied Replaygain to the *actual file data* you do not need support in the player at all, the actual file data is at the gain level you want and player support is required only for the most minor adjustments. As to corruption I would **always recommend having backups** and not overwriting originals. – Mokubai May 04 '19 at 11:31