[opus] opusenc confused by Replaygain tags

Peter White peter.white at posteo.net
Thu Aug 11 16:15:30 UTC 2016


I think I might have kind of, sort of found a bug in opusenc. But do
correct me if I am worng. :)

When converting an FLAC file that contains RG tags written by
bs1770gain the resulting opus file has a way, way too high RG value. I
am talking >90dB(!).

Here is the metaflac output of the flac file:

% metaflac --block-number=2 --list bs.1770/test.flac
METADATA block #2
   type: 4 (VORBIS_COMMENT)
   is last: false
   length: 351
   vendor string: reference libFLAC 1.3.0 20130526
   comments: 9
     comment[0]: REPLAYGAIN_ALGORITHM=ITU-R BS.1770
     comment[2]: REPLAYGAIN_TRACK_GAIN=-11.84 dB
     comment[3]: REPLAYGAIN_TRACK_PEAK=1.220055
     comment[4]: REPLAYGAIN_TRACK_RANGE=11.01 dB
     comment[5]: REPLAYGAIN_ALBUM_GAIN=-11.84 dB
     comment[6]: REPLAYGAIN_ALBUM_RANGE=11.01 dB
     comment[7]: REPLAYGAIN_ALBUM_PEAK=1.220055
     comment[8]: encoder=Lavf57.46.100

Note, the comment[8] is due to bs1770gain using ffmpeg's libs. I did
an additional run of

% flac -f test.flac

just to make sure it was the reference encoder doing the last flac
encoding, in case libav* or bs1770gain messed something up. The file
plays as expected in the media player of choice.

Then I converted it to opus:

% opusenc test.flac test.opus
Encoding using libopus 1.1.3 (audio)
    Input: 44.1kHz 2 channels
   Output: 2 channels (2 coupled)
           20ms packets, 96kbit/sec VBR
  Preskip: 356

Encoding complete
        Encoded: 5 minutes and 18.68 seconds
        Runtime: 8 seconds
                 (39.83x realtime)
          Wrote: 3616359 bytes, 15934 packets, 321 pages
        Bitrate: 90.1199kbit/s (without overhead)
  Instant rates: 1.2kbit/s to 190.4kbit/s
                 (3 to 476 bytes per packet)
       Overhead: 0.731% (container+metadata)

All went well there, seemingly. But opusinfo now shows this:

% opusinfo test.opus
Processing file "test.opus"...

New logical stream (#1, serial: 3d89c72a): type opus
Encoded with libopus 1.1.3
User comments section follows...
         ENCODER=opusenc from opus-tools 0.1.9-23-gaa0e15c
Opus stream 1:
         Pre-skip: 356
         Playback gain: 90.1602 dB
         Channels: 2
         Original sample rate: 44100Hz
         Packet duration:   20.0ms (max),   20.0ms (avg),   20.0ms (min)
         Page duration:   1000.0ms (max),  999.0ms (avg),  680.0ms (min)
         Total data length: 3616359 bytes (overhead: 0.731%)
         Playback length: 5m:18.666s
         Average bitrate: 90.79 kb/s, w/o overhead: 90.12 kb/s
Logical stream 1 ended

Note the 90+ dB Playback gain.

I used the latest git master of opus-tools for this. I also wanted to
try the latest libopus git master, but that doesn't compile. The last
good commit, that compiles for me is 4f5557c3. I can check with that
one as well, if need be.

I discovered this with the latest release versions, though. The tests
with the git version were done primarily to check if this might have
been fixed already.

I really think this shouldn't happen. :) The only way of avoiding
this, is to use the --discard-comments option of opusenc. Or, of
course, not to write replaygain tags to the flac before converting to

What I expected to actually happen was that opus would just uses the
samples of the original file and simply copies the tags/comments. But
there is obviously some calculation going on there.
When using flac (the command) to do the RG calculation of the original,
opusenc then calculates an R128_GAIN, but only if there are both track
and album gain present in the original.

Honestly, I don't think it should do this, because the resulting opus
file might be slightly different in loudness, due to the lossy nature
of the codec. BTW, does opusenc apply RG during conversion, meaning
does it amplify/attenuate the original file and then encode? Because,
just now, to double-check I cleaned the flac file of all tags had flac
reencode it with --replay-gain activated and now the resulting
opusfile has an R128_TRACK_GAIN of exactly 0.
If that is the case, I really don't want it to happen because that
does affect the signal-to-noise ratio, doesn't it? At least for the
attenuation case, that is. Or, am I thinking wrong?

Anyway, I'd be glad to here your comments.


More information about the opus mailing list