opusenc/windows: lost some ReplayGain tags when trancoding from FLAC

xiph / opus-tools

A set of tools to encode, inspect, and decode audio in the Opus format.

https://opus-codec.org/

Other

218 stars 79 forks source link

opusenc/windows: lost some ReplayGain tags when trancoding from FLAC #39

Open vlakoff opened 5 years ago

vlakoff commented 5 years ago

Just tried out opus-tools-0.2, which is now able on Windows to receive FLAC as input.

My input FLAC file has these metadata:

regular tags ("artist", "title", etc.)
a custom tag (fwiw, it's "place")
ReplayTags tags ("track gain", "track peak", "album gain", "album peak")

All tags have been copied, except some ReplayGain ones, namely: "track peak", "album gain", "album peak".

Interestingly enough, the first ReplayGain tag ("track gain") has been copied.

rillian commented 5 years ago

Hi, thanks for the report.

Opus files use the EBU R128 track normalization instead of ReplayGain, so encoders are supposed to convert the track gain to the built-in lossless gain in the codec header, convert album gain tag and drop the others. The worry was that if the ReplayGain tags were propagated, players might get confused and try to apply the adjustment twice.

So some of that is as intended, although stripping the "album gain" and not "track gain" sounds wrong. Do the resulting files play with the correct levels in your player?

vlakoff commented 5 years ago

Understood about the *_PEAK tags, it's expected that they are dropped.
My sample input FLAC file has a REPLAYGAIN_TRACK_GAIN of -8.58 dB, the transcoded Opus file has a R128_TRACK_GAIN of 123. I haven't done the math to check the value, but I assume it's right. foobar2000 displays "RG -8.58 dB" for both files.
So the remaining issue is about not having a R128_ALBUM_GAIN in the output file.

How did opusenc determine the R128_TRACK_GAIN value?

Did it convert it from the FLAC metadata?
… or did it calculate it from the output Opus data?

It seems that the former is what opusenc does (because if I transcode a file without RG tags, the output has no R128_TRACK_GAIN). So, opusenc should as well convert the REPLAYGAIN_ALBUM_GAIN to R128_ALBUM_GAIN.

The latter would be the proper way to get the exact value (as the codec is lossy), though in doing so, it would be normal to not have a R128_ALBUM_GAIN, considering the tool can only take one input file at once.

vlakoff commented 5 years ago

See in the implementation of the metadata_callback() function:

Starting from line 144: Both REPLAYGAIN_TRACK_GAIN and REPLAYGAIN_ALBUM_GAIN are looked for, and their values are memorised.
Starting from line 179: However, only the track gain is converted to a R128 metadata tag.

Refs commit https://github.com/xiph/opus-tools/commit/892fd9297717d2f60fd56856e96d45b202945f0a

ftrebien commented 4 years ago

How did opusenc determine the R128_TRACK_GAIN value?

See the metadata_callback() function on lines 179 to 193.

From the RFC, decoders should add the header's output gain to R128_TRACK_GAIN or R128_ALBUM_GAIN to compute the final gain for the respective loudness normalization mode. For historical reasons, album gain is placed on the header's output gain field, and the difference between track gain and album gain is placed on the R128_TRACK_GAIN tag. This is so because listeners are generally more satisfied using album gain, an assumption that often frees a decoder from the complexity of having to support both loudness normalization modes. As a note, this is also how foobar2000 works by default.