Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: ffmpeg not utilising ReplayGain correctly (Read 1817 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

ffmpeg not utilising ReplayGain correctly

I have found that positive ReplayGain values are not applied by ffmpeg, only negative ones!
typically: ffmpeg -i any.mp3 -af "volume=replaygain=track" anynew.mp3

If I change the volume manually, then the equivalent positive values are heard (and measured):
typically: ffmpeg -i any.mp3 -af "volume=+12dB" anynew.mp3

How can I get ffmpeg to correctly apply the replygain positive values when streaming music?

Re: ffmpeg not utilising ReplayGain correctly

Reply #1 –
https://ffmpeg.org/ffmpeg-filters.html#volume

how's the behaviour of `replaygain_noclip` and/or `replaygain_preamp`?
if that also doesn't help, I guess it would be more or less straightforward to find and remove this condition from the code. but building might be a pain, depending on the OS. if you use Arch Linux, then it's maybe easy to build using AUR package as a base.
a fan of AutoEq + Meier Crossfeed

Re: ffmpeg not utilising ReplayGain correctly

Reply #2 –
The files are not clipping else the fixed volume setting would not work. Only if ReplayGain uses other settings that are ignored when using a direct volume adjustment would explain the problem (unless it has a bug?) but ffmpeg makes no reference to other requirements for ReplayGain nor Volume settings.

I don't need to utilise preamp as the file volume is correct at normal.

I find it strange that no-one else has had an issue with ffmpeg only amending negative ReplayGain values:
ffmpeg -i any.mp3 -af "volume=replaygain=track" anynew.mp3
assumes the replaygain value CAN be positive, but doesn't work when it is.
ffmpeg -i any.mp3 -af "volume=+9dB" anyhigh.mp3
Feel free to try it for yourselves, using the attached clip and a negative replaygain tag or dB volume values:

Re: ffmpeg not utilising ReplayGain correctly

Reply #3 –
Quote from: AnnieBody on
The files are not clipping else the fixed volume setting would not work. Only if ReplayGain uses other settings that are ignored when using a direct volume adjustment would explain the problem (unless it has a bug?)
I would expect that replaygain_noclip is ignored when direct volume adjustment is used.

Why should it be used when you are not using replaygain mode?

Quote from: AnnieBody on
Feel free to try it for yourselves, using the attached clip and a negative replaygain tag or dB volume values:
I set the tag to +10 dB and used replaygain_noclip=0:
Code: [Select]
]$ ffmpeg -loglevel verbose -i any.MP3 -af 'volume=replaygain=track:replaygain_noclip=0' any_vol.mp3
...
... Using gain 10.000000 dB from replaygain side data.
...
I get:
Code: [Select]
Sample peak,          RMS
 -0.54 dBFS,  -15.79 dBFS - any.MP3
  0.00 dBFS,   -6.95 dBFS - any_vol.mp3
So everything seems to be working fine.

Re: ffmpeg not utilising ReplayGain correctly

Reply #4 –
danadam
You were right. I was wrong!
The noclip option does indeed set the correct replaygain + values.
My music streaming is now working as expected.

I finished up at this forum after following many many ffmpeg websites and links none of which made an reference to noclip: even on the ffmpeg support forum itself.
I can only assume there are many people using ffmpeg completely unaware that replaygain is not actually fully working for them when using the well documented method above!
Many thanks for your perfect assistance. You are indeed a star!

Re: ffmpeg not utilising ReplayGain correctly

Reply #5 –
Quote from: AnnieBody on
Many thanks
You're welcome.

Quote from: AnnieBody on
I can only assume there are many people using ffmpeg completely unaware that replaygain is not actually fully working for them when using the well documented method above!
I don't know how others, but if I was using ffmpeg to apply replaygain then the current behavior, i.e. clipping prevention, would be something I want most of the time.

Re: ffmpeg not utilising ReplayGain correctly

Reply #6 –
By the way, if you want to adjust volume of MP3s, then it can be done losslessly.
If mp3 in infile and outfile were only example filenames, then ignore.

Re: ffmpeg not utilising ReplayGain correctly

Reply #7 –
ReplayGain is lossless on both MP3 and Flac!
All it does is add a readable tag to the music file.

As I understand it the default ReplayGain uses a nominal db value well below the peak expectation. They know what they are doing!
Most files adjust using a marginal + or - of 1dB or so, so there is no problem with the file actually clipping.
In my extreme example above I was using up to + or - 12db just to confirm ReplayGain was working, and clearly the file was distorting at this plus level.
The reality is on my expensive HiFi I cannot hear any distortion or loss of quality when using ReplayGain. That is why it is supported by manufacturers in their streaming devices and services.
Of course, purists would state that any change is not recommended, but all the ReplayGain is doing is automatically applying a minor adjustment of the volume between tracks preventing me from having to constantly adjust the volume manually.

Re: ffmpeg not utilising ReplayGain correctly

Reply #9 –
unless you explicitly select "copy" codec for the respective type of stream, ffmpeg will re-encode it.
a fan of AutoEq + Meier Crossfeed

Re: ffmpeg not utilising ReplayGain correctly

Reply #10 –
magicgoose
You can't just make a statement without providing any supporting documentation. It is this type of response that renders support forums useless!
The initial code does indeed copy the original file. So what are you claiming is wrong, what are you advising should be rectified, and please provide an example to support your claim, and why?

Porcus
You only get losses when you downgrade, not re-encode the same file.
Digital files are volume adjusted by bit shifting. No loss of data is incurred using this method: it is industry standard practise.



Re: ffmpeg not utilising ReplayGain correctly

Reply #11 –
The code above does not re-encode anything . It merely provides a gain adjustment to the volume, in the exactly the same way as any digital media devices does. How do you think digital devices control volume of the digital source file?

Re: ffmpeg not utilising ReplayGain correctly

Reply #12 –
Try the following:
ffmpeg -i infile.mp3 -af "volume=+0dB" out0.mp3
ffmpeg -i infile.mp3 -af "volume=+12dB" outUpBy12.mp3
ffmpeg -i outUpBy12.mp3  -af "volume=-12dB" outUpBy12ThenDownBy12.mp3

Compare the audio with the appropriate tool.
Post the result in this thread.

And we'll take it from there.

Re: ffmpeg not utilising ReplayGain correctly

Reply #13 –
No need, read above!
In my extreme example above I was using up to + or - 12db just to confirm ReplayGain was working, and clearly the file was distorting at this plus level.

I suggest you start your own subject and not hijack this one!

Can someone please close this subject as the matter has been solved and it appears has been taken over by people with a different agenda.
 

Re: ffmpeg not utilising ReplayGain correctly

Reply #15 –
Just to clarify. I saw a comment above that using the volume filter with ffmpeg to apply replaygain does not result in a re-encode.

This is false. In order to apply audio filters, ffmpeg must decode the audio, apply the filters, and then encode again. There's no other way to apply any ffmpeg audio filters. The volume filter is absolutely one of those filters.

So if you use a command line:

Code: [Select]
ffmpeg -loglevel verbose -i any.MP3 -af 'volume=replaygain=track:replaygain_noclip=0' any_vol.mp3

You're applying an audio filter, so the audio will be decoded from MP3, filtered, and re-encoded into MP3. This will 100% result in a lossy-to-lossy conversion.

If you have MP3s and need the ReplayGain pre-applied you can use a tool like MP3Gain. The MP3 bitstream has a method of specifying gain to apply which is done at the decoder level, MP3Gain will go through your MP3 file and modify that gain field. It's not a re-encode, it's a direct modification of the existing bitstream, so you're not doing a lossy-to-lossy conversion. This is a lossless method of applying the gain.

The upside of that method is your gain is applied to all MP3 players since it's handled in the decoder itself, and not as a filter like ReplayGain usually is. The downside of this is you need to pick which gain to use ahead of time (track or album) since this bitstream gain parameter is just a single parameter.

If you go this route, you should probably wipe out your ReplayGain tags, or make sure your audio player doesn't apply ReplayGain, otherwise you risk having the gain applied twice (once from the MP3 decoder, again by your audio player).

EDIT: and just to clarify even more and respond to this chain:

Quote from: magicgoose on
unless you explicitly select "copy" codec for the respective type of stream, ffmpeg will re-encode it.

Quote from: AnnieBody on
magicgoose
You can't just make a statement without providing any supporting documentation. It is this type of response that renders support forums useless!
The initial code does indeed copy the original file. So what are you claiming is wrong, what are you advising should be rectified, and please provide an example to support your claim, and why?

I suggest reading the FFMPEG documentation: https://ffmpeg.org/ffmpeg.html#Stream-copy - here's the important part with emphasis added by me:

Quote
Stream copy is a mode selected by supplying the copy parameter to the -codec option. It makes ffmpeg omit the decoding and encoding step for the specified stream, so it does only demuxing and muxing. It is useful for changing the container format or modifying container-level metadata.

Since there is no decoding or encoding, it is very fast and there is no quality loss. However, it might not work in some cases because of many factors. Applying filters is obviously also impossible, since filters work on uncompressed data.

If you apply an audio filter, you're uncompressing/decoding the audio and recompressing/encoding, period.