Normalizing OGG files

[kolamorx]

I'm interested in a Windows tool, preferably a command line tool, that can normalize multiple OGG files at once, preferably losslessly.

[tebasuna51]

Maybe you want ReplayGain (https://en.wikipedia.org/wiki/ReplayGain)

Try Foobar2000 (http://www.foobar2000.org/) than can apply ReplayGain to multiple OGG files at once.

[kolamorx]

Foobar2000 can't do this losslessly via a command line, right?

[tebasuna51]

I don't know if it is possible.

[Asmodian]

VorbisGain (http://www.softpedia.com/get/Multimedia/Audio/Other-AUDIO-Tools/VorbisGain.shtml) does exist for flag based (lossless) normalization.

[kolamorx]

VorbisGain (http://www.softpedia.com/get/Multimedia/Audio/Other-AUDIO-Tools/VorbisGain.shtml) does exist for flag based (lossless) normalization.
What do you mean by "flag based"?

[tebasuna51]

Seems than it add flags/tags/metadata without decode/recode (lossless), the same concept than ReplayGain.

[kolamorx]

So if the player doesn't support those flags, it's basically useless.

[hello_hello]

So if the player doesn't support those flags, it's basically useless.

Pretty much, although that's how ReplayGain was designed to work. Physically altering the audio volume is a workaround for lack of ReplayGain support.

Foorbar2000 can losslessly adjust MP3 and AAC as MP3Gain does. I don't know of any way to adjust ogg files losslessly. You'd have to scan them, add the ReplayGain info to the tags, then convert to ogg or some other format while applying the ReplayGain info. Foobar2000 can do that.

[tebasuna51]

Of course, is the only method without a lossy decode/recode conversion.

Despite the hello_hello comment ReplayGain, VorbisGain and Foobar2000 claim than OGG files support that method without recode.

If you use a standalone player you need check if it support the method.

[kolamorx]

Just came across replaygain parameter of FFmpeg volume filter (https://ffmpeg.org/ffmpeg-filters.html#volume). What exactly does it do?

[sneaker_ger]

It reads ReplayGain metadata from the source files and applies is to the raw, decoded PCM audio. If the source does not have ReplayGain metadata the parameter should have no effect at all.

[hello_hello]

Of course, is the only method without a lossy decode/recode conversion.

Despite the hello_hello comment ReplayGain, VorbisGain and Foobar2000 claim than OGG files support that method without recode.

When I referred to adjusting ogg files losslessly, I meant physically altering the volume as you can for MP3 and AAC. You can't do the same with Ogg can you?

Mind you, I wouldn't have thought adding ReplayGain info to tags counted as a lossless adjustment as such, given it only provides instructions for a player to adjust it's volume and doesn't change the volume of the audio itself.

Foobar2000 will scan and add ReplayGain info to just about any audio/file type these days. AC3, raw AAC, MP4, M4A, DTS, WAVE, FLAC, MKA, MPC, OGG, WavPack, AIFF, WMA, MP2, MP3....

I assume most of the previously mentioned scanning options use the original ReplayGain scanning algorithm. Foobar2000 uses the newer EBU R128 algorithm for ReplayGain scanning which seems more accurate. What does ffmpeg use these days? Anyone know?

[smok3]

There are ebur128 and loudnorm (possibly more) in ffmpeg today (r128 based i mean). Of corse docs are historically sparse and without examples, so good luck at constructing your cli.

[Asmodian]

When I referred to adjusting ogg files losslessly, I meant physically altering the volume as you can for MP3 and AAC. You can't do the same with Ogg can you?

You cannot losslessly physically alter the volume in any of the lossy formats (is physically the right term? I suppose I do know what you mean ;)). That always requires a decode, apply gain/normalize, and re-encode.

They way lossless volume adjustment for MP3 and AAC files works is with flags too. I remember MP3 players back in the day that didn't respect MP3's volume flags but now support seems universal. I have no idea how universal support is for Vorbis flags. :o

[sneaker_ger]

In mp3 all players should respect the gain flags - it's an integral part of the mp3 format. It is 100% lossless unless you hit the upper or lower limit of the flag's range. (I believe AAC-LC works the same.)

[hello_hello]

You cannot losslessly physically alter the volume in any of the lossy formats (is physically the right term? I suppose I do know what you mean ). That always requires a decode, apply gain/normalize, and re-encode.

They way lossless volume adjustment for MP3 and AAC files works is with flags too. I remember MP3 players back in the day that didn't respect MP3's volume flags but now support seems universal. I have no idea how universal support is for Vorbis flags. :o

It seems like some programs must be doing the impossible.
MP3DirectCut will even apply fade-ins and fade-outs to MP3s without re-encoding. The flags they use must be quite detailed. :)

The way I understand it, each MP3 frame includes some sort of volume information, so an MP3 can have it's volume adjusted by altering the data in each frame. That must be pretty close to the definition of a lossless adjustment.

Roughly two thirds of the way down the page (MP3 tag spec):
http://gabriel.mp3-tech.org/mp3infotag.html

byte $B5 MP3 Gain

any mp3 can be amplified by a factor 2 ^ ( x * 0.25) in a lossless manner by a tool like eg. mp3gain

byte $B5 is set to (00)h by default.

if done so, this 8-bit field can be used to log such transformation happened so that any given time it can be undone.

WARNING:
Do NOT alter this field if you do not fully understand its use. You will damage the Replaygain fields and musicCRC if you do not implement this correctly.

You can only modify this field if

the TagCRC checks out
you update all three the ReplayGain fields with the correct number of 1.5dB steps
the TagCRC is updated after all this

Do NOT change/update the musicCRC. It will be invalid after you change this mp3gain field.
If an application like mp3gain changes the main music frames of the mp3 then the musicCRC should be invalid.
The Lame Tag CRC should still be valid however (it could be updated by mp3gain). only tools like mp3gain should use this field, as it is made for making lossless adjustments to the mp3
after encoding is finished. No need to support this in LAME or any decoder at all.

2^(a/4) , range of "a" here: -127..0..127

The way I read that, space was reserved in the MP3 tag for programs to store information in order to losslessly undo the previously applied lossless volume changes, but it doesn't look like anyone uses it. Maybe because it's not a completely standard MP3Tag. Here's what MediaInfo shows for an MP3 after it was was losslessly adjusted by MP3Gain (GUI):

0008D5 Stereo mode: 3 (0x3) - (3 bits)
0008D5 noise shapings: 1 (0x1) - (2 bits)
0008D6 MP3 Gain: 0 (0x00)
0008D7 Preset and surround info: 480 (0x01E0)
0008D9 MusicLength: 5087909 0x004DA2A5)

I'm not sure I can see any other field for storing volume information. Are you referring to something else?

I brewed a fresh MP3, scanned it and adjusted it's volume with foobar2000 and had a look at it's tag, but it seems foobar200 doesn't write the MP3Gain info either.

00094B Stereo mode: 3 (0x3) - (3 bits)
00094B noise shapings: 1 (0x1) - (2 bits)
00094C MP3 Gain: 0 (0x00)
00094D Preset and surround info: 480 (0x01E0)
00094F MusicLength: 4618468 (0x004678E4)

[sneaker_ger]

There are different things. The "actual" adjustment is made in each frame in "global_gain" element (MediaInfo shows this). Then mp3gain may also add APEv2 tags to undo adjustment or make it more precise (global_gain is 1.5 dB steps).

The way I read that, space was reserved in the MP3 tag for programs to store information in order to losslessly undo the previously applied lossless volume changes
There is no reserved space for either global_gain or APEv2. global_gain is always present in every mp3 file. Just needs to be altered. The (optional) APEv2 tag will be added.

[hello_hello]

There are different things. The "actual" adjustment is made in each frame in "global_gain" element (MediaInfo shows this). Then mp3gain may also add APEv2 tags to undo adjustment or make it more precise (global_gain is 1.5 dB steps).

Which is why I originally said it's possible to losslessly adjust the volume of MP3s.... unless there's some other definition of "losslessly adjusting the volume" to which changing the global_gain of each frame wouldn't apply?
There's no law stating the global_gain value for each frame must be adjusted by the same amount, which is why MP3DirectCut can change the volume of specific parts of an MP3 or apply fade-ins and fade-outs etc.

There is no reserved space for either global_gain or APEv2. global_gain is always present in every mp3 file. Just needs to be altered. The (optional) APEv2 tag will be added.

I realise MP3Gain adds ReplayGain/undo information to an APEv2 tag, but I didn't say the field was used for either global gain or APEv2 or that it's ever used at all. Only that it exists.
Is there also some other definition of "logging a volume adjustment" that'd only apply in this case?

http://gabriel.mp3-tech.org/mp3infotag.html
byte $B5 MP3 Gain
any mp3 can be amplified by a factor 2 ^ ( x * 0.25) in a lossless manner by a tool like eg. mp3gain
byte $B5 is set to (00)h by default.
if done so, this 8-bit field can be used to log such transformation happened so that any given time it can be undone.

I still don't know which volume flag Asmodian referred to. Was there a time MP3 players ignored the global_gain of each frame? It sounded to me like he was referring to some sort of "master volume" flag, but aside from the possibility of using the ReplayGain field in the MP3 header, which is far as I know isn't widely supported by players, I don't know what field/flag that'd be.

[sneaker_ger]

There's no law stating the global_gain value for each frame must be adjusted by the same amount, which is why MP3DirectCut can change the volume of specific parts of an MP3 or apply fade-ins and fade-outs etc.
I don't know. Decoding a frame relies on previous frames. I don't know whether this is before or after applying global_gain.

Is there also some other definition of "logging a volume adjustment" that'd only apply in this case?
I don't understand the question.

Was there a time MP3 players ignored the global_gain of each frame?
I highly doubt that.

[hello_hello]

I don't know. Decoding a frame relies on previous frames. I don't know whether this is before or after applying global_gain.

I don't understand the exact workings of it either, but I've applied fade-ins and fade-outs to MP3s with Mp3DirectCut countless times without re-encoding, and whatever the type of voodoo required, the "not having to re-encode part" has always fallen under my definition of a lossless volume adjustment.
The fact you can edit MP3s without re-encoding by cutting, copying and pasting frames (Mp3DirectCut) seems to imply global_gain would be applied after decoding, but I don't know how any dependency on previous frames would be effected. Then again, maybe that's what sometimes causes an audible high pitched "glitch" sound (for want of a better description) when MP3's are edited that way? Often if cutting part of an MP3 causes it to happen, adjusting the cut points a little will prevent it, or at least reduce the effect enough for it to be to be inaudible.

I don't understand the question.

Likewise, I don't understand why you said the MP3 Gain field in the header isn't reserved for global_gain or APEv2 as though I'd claimed it was.

I highly doubt that.

Hopefully Asmodian will return and provide more details on the flag to which he referred.