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
  • 323

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
  • 95,412