Hi,
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[1]: REPLAYGAIN_REFERENCE_LOUDNESS=-18.00
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
REPLAYGAIN_ALGORITHM=ITU-R BS.1770
REPLAYGAIN_TRACK_RANGE=11.01 dB
REPLAYGAIN_ALBUM_RANGE=11.01 dB
encoder=Lavf57.46.100
R128_TRACK_GAIN=0
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
opus.
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.
Best,
Peter
