Opened 11 years ago

Last modified 11 years ago

#2699 open enhancement

automate lossless normalisation

Reported by: feelart Owned by:
Priority: wish Component: undetermined
Version: git-master Keywords:
Cc: nfxjfg@googlemail.com Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

Introduce a new audio switch to automate LOSSLESS normalisation

Propose -a:llnorm
CLI example

ffmpeg -i src_audio.aac -a:llnorm out_LOSSLESS_NORMALISED.aac

P.S. To best of my knowledge volumedetect, does not
1/ automate normalisation
2/ does NOT do it losslessly

Attachments (2)

2normalize.mp3 (47.7 KB ) - added by feelart 11 years ago.
_Isnormalized.mp3 (47.7 KB ) - added by feelart 11 years ago.

Download all attachments as: .zip

Change History (14)

comment:1 by Carl Eugen Hoyos, 11 years ago

Keywords: audio lossless normalisation removed

Please elaborate more on what kind of issue you are reporting:
Iiuc, you write above that volumedetect is not lossless (that is how I read it, note that I am not a native speaker). Since the volumedetect filter does not modify its input, I cannot imagine how it can be more lossless than it currently is.

Otoh, if your issue is that the current filter system does not automatically change audio for some use-case, how would this change be lossless?

comment:2 by feelart, 11 years ago

Sorry, I meant

volumedetect helps to find out how much you'll change the volume, using vol switch (http://www.ffmpeg.org/ffmpeg-filters.html#volume)

To my best knowledge, vol filter does not provide/attempt a lossless normalisation.
Lossless normalisation is possible on mp3 & aac, for other codecs I do not know.

Instead of having 3 CLI:
1/ first volumedetect
2/ then vol (don't think you can pipe vol with the right normalisation factor from volumedetect directly on the CLI)
3/ run your other instructions

It would be nice to have a single CLI such as:

ffmpeg -i src.mp4 -vf "crop=in_w-24*32:in_h-5*32:17*32:3*32,hqdn3d,lut=y=val*0.65" -c:v libx264 -crf 28 -preset slower -a:llnorm -c:a libmp3lame -ac 1 -ar 32000 -aq 0 -async 1 videoStreamProcessedSoundLosslesslyNormalisedThenConvertedToMp3.mp4

You might find strange to make a lossless normalisation, then a sound convertion, but lossless convertion is lossless and convertion might be an user request.

comment:3 by feelart, 11 years ago

FYI:

MP3Gain provide lossless normalisation on MP3 & aac (with AACGain)

Re: http://mp3gain.sourceforge.net/

Lossless can be MD5 verified, as so
1/ Normalising
2/ decrease back by the same amount the normalised sound
3/ compare MD5 of source with processed sound.

comment:4 by Carl Eugen Hoyos, 11 years ago

Component: avfilteravcodec
Priority: normalwish

Does lame support setting gain? If not, I don't see how this could be implemented in FFmpeg for mp3. (If it does support it, I suspect it is already working.)

Last edited 11 years ago by Carl Eugen Hoyos (previous) (diff)

comment:5 by Carl Eugen Hoyos, 11 years ago

Could you provide two aac samples made from the same input but with different gain? Ideally, one would be extremely silent to make the difference very obvious.

comment:6 by feelart, 11 years ago

Does lame support setting gain?

http://ecmc.rochester.edu/ecmc/docs/lame3.98a2/switchs.html
Yes, with the --scale switch, but haven't tested if it's lossless, as I use MP3Gain to batch lossless normalise my MP3 or AAC.

If it does support it, I suspect it is already working

Maybe it's due to my lack of deep understanding of ffmpeg, but I failed to make use of LAME switch directly.

I do not know how MP3Gain does lossless normalisation of MP3 & AAC, but it's true that for MP3 it requires LAME and for aac it requires AACgain.

It's also possible to normalize with SOX http://sox.sourceforge.net/
but have never tried and at this stage don't know if LOSSLESS process.

Also,
http://gnormalize.sourceforge.net/ (RE-ENCODING !!)
http://normalize.nongnu.org/ (re-encoding ????)

in reply to:  6 comment:7 by Carl Eugen Hoyos, 11 years ago

Replying to feelart:

Does lame support setting gain?

Yes, with the --scale switch, but haven't tested if it's lossless

Please test and please clarify if lame just sets metadata or if it actually changes the bitstream.

If setting metadata is all you need, a patch may not be difficult, can you provide samples (or point to a specification)?

comment:8 by gjdfgh, 11 years ago

Cc: nfxjfg@googlemail.com added

comment:9 by feelart, 11 years ago

If setting metadata is all you need, a patch may not be difficult, can you provide samples (or point to a specification)?

I don't think so.
Attached is an mp3 example.

ffprobe -i 2normalize.mp3 -show_streams -show_packets
and
ffprobe -i _isNormalize.mp3 -show_streams -show_packets
show no KDiff3 difference (except in file's name)

Last edited 11 years ago by feelart (previous) (diff)

by feelart, 11 years ago

Attachment: 2normalize.mp3 added

by feelart, 11 years ago

Attachment: _Isnormalized.mp3 added

in reply to:  9 comment:11 by Carl Eugen Hoyos, 11 years ago

Replying to feelart:

If setting metadata is all you need, a patch may not be difficult, can you provide samples (or point to a specification)?

I don't think so.

You mean setting metadata will not be enough, the mp3 files will be encoded differently depending on which value is passed for --scale ?

Attached is an mp3 example.

ffprobe -i 2normalize.mp3 -show_streams -show_packets
and
ffprobe -i _isNormalize.mp3 -show_streams -show_packets
show no KDiff3 difference (except in file's name)

Meaning the metadata is the only difference between the files while the actual data packets are identical?

Sorry, I am not a native speaker...

comment:12 by Elon Musk, 11 years ago

Component: avcodecundetermined
Status: newopen

There are 2 distinct things: replaygain scanner and applying gain or just storing replaygain value into metadata.

mp3 allow apply gain losslessly (by changing single value in bitstream).

Note: See TracTickets for help on using tickets.