Closed zuzzurro closed 6 years ago
Yeah, the current tag names are wrong. Fixing this is definitely on my TODO list. I think I implemented this at a time where there wasn't a real standard yet.
But I'll keep the REPLAYGAIN_* tags as a compatibility option behind some flag. Some players such as Rockbox only support the 'old' vorbisgain style.
Fine with me, as I use foobar2000 on my phone I'm more interested in forward compatibility rather than backwards. What should the logic be for other formats such as AAC?
Every format more or less has a different way of specifying ReplayGain information. But most of them don't have a distinction between R128 and ReplayGain tags. ReplayGain now uses the R128 algorithm as well, so there is no pressing need to invent new R128 tags. The only practical difference is the reference level (R128 uses -23LUFS, RG uses -18LUFS).
For MP4/M4A I do what iTunes does (or did at the time). It worked with foobar2000. https://github.com/jiixyj/loudness-scanner/blob/5b627e625236ca3a525c47a0fae8096255ceeb9d/scanner/scanner-tag/rgtag.cpp#L328
So the change needed is to split Vorbis and Opus, leave Vorsbis unchanged and change the tag names for Opus. Correct? Thanks
Yes, this is correct. But Opus is still a bit more involved: There is a gain flag in the Opus format itself that interacts with the R128 tags. You are supposed to set the Opus gain and then correct it with the R128_* tags. I'll just figure out what foobar2000 does and then do the same.
OK. I'll wait and test..
I've just pushed support for RFC compliant opus tags. There is also a flag --opus-vorbisgain-compat
that can be used to get the 'old style' vorbisgain tags in addition. Let me know if you encounter any issues.
OK, I'm testing it now. First comment is about the interaction between the --incremental flag and the new tags. It seems to me that in incremental mode the old tags are considered valid. Is that correct?
Yeah, the current tag detection is a bit naive. I'll try to fix this.
OK. The second point is the following:
--- z 2018-01-31 22:03:18.447063064 +0100
+++ z2 2018-01-31 22:04:26.741996025 +0100
@@ -30,15 +30,13 @@
MUSICBRAINZ_TRACKID=20a408fc-acb6-4b85-bbb8-15199ff73a87
ORIGINALDATE=1985-05
ORIGINALYEAR=1985
+ R128_ALBUM_GAIN=0
+ R128_TRACK_GAIN=226
RELEASE DATE=1991
RELEASE TYPE=Reissue
RELEASECOUNTRY=DE
RELEASESTATUS=official
RELEASETYPE=album
- REPLAYGAIN_ALBUM_GAIN=0.17 dB
- REPLAYGAIN_ALBUM_PEAK=1.057232
- REPLAYGAIN_TRACK_GAIN=1.06 dB
- REPLAYGAIN_TRACK_PEAK=0.749603
RETAIL DATE=1991-00-00
RIP DATE=2014-05-04
RIPPING TOOL=EAC Secure
@@ -51,14 +49,14 @@
METADATA_BLOCK_PICTURE=3|image/jpeg||0x0x0|<30108 bytes of image data>
Opus stream 1:
Pre-skip: 312
- Playback gain: 0 dB
+ Playback gain: -4.82422 dB
Channels: 2
Original sample rate: 44100Hz
Packet duration: 20.0ms (max), 20.0ms (avg), 20.0ms (min)
Page duration: 1000.0ms (max), 999.2ms (avg), 700.0ms (min)
- Total data length: 6328728 bytes (overhead: 1.42%)
+ Total data length: 6328637 bytes (overhead: 1.42%)
Playback length: 6m:17.693s
- Average bitrate: 134.1 kb/s, w/o overhead: 132.1 kb/s
+ Average bitrate: 134 kb/s, w/o overhead: 132.1 kb/s
It's a diff of two opusinfo runs in the same directory, the first with the old tags and the second with the new ones.
I have nothing to say about the tag values (yet) but I wonder where the Playback gain diff is coming from. Could it be that I tagged the folder some time ago with an older version and the new version calculate the gains differently? All files of this album show this exact same difference.
Actually thinking more about it think I know the reason for this, but please feel free to enlighten me ...
This is about what you wrote previously:
You are supposed to set the Opus gain and then correct it with the R128_* tags
Correct?
Yeah, this is expected behavior. For opus files, the album gain is actually stored in the opus header instead of some metadata field. It is relative to -23 LUFS (instead of -18 LUFS like ReplayGain). You can see this by comparing the old REPLAYGAIN_ALBUM_GAIN
value of 0.17
and the Playback gain
of -4.82422
. The difference is just about 5db. Later opus RFCs introduced the R128_ALBUM_GAIN
field to make it absolutely clear that the playback gain is related to the R128 standard level of -23 LUFS. This field is applied in addition to the playback gain field but usually is just 0.
However, playing at -23 LUFS would be a bit quiet compared to files tagged with ReplayGain tags -- so a music player would not just apply the playback gain when it sees any of the R128_*
tags. Instead, it would boost the loudness by 5db after applying the playback gain -- back to ReplayGain level. I know that at least foobar2000 does this.
If you try the --opus-vorbisgain-compat
flag you would see REPLAYGAIN_ALBUM_GAIN
values of always 5db. This forces older players that only support those tags to play back at the correct level.
OK, thanks for the detailed explanation. Still uncertain about using the --opus-vorbisgain-compat flag or not. My first full tagging is going to be without..
The --incremental
flag should be a bit more intelligent now. It should rescan opus files with 'legacy' tags correctly.
One last comment, and this could go into a new issue, if you prefer. I'm retagging my whole opus collection now and I see these warnings (they are pretty common):
$ loudness tag -v -r opus
found plugin input_sndfile
found plugin input_mpg123
found plugin input_ffmpeg
found plugin input_gstreamer
Warning: Could not read full file or determine right length: Expected: 12840019 Got: 12840000[### Warning: Could not read full file or determine right length: Expected: 17423080 Got: 17423040[### Warning: Could not read full file or determine right length: Expected: 11988496 Got: 11988480[########### Warning: Could not read full file or determine right length: Expected: 23847392 Got: 23847360[############# [############# ] 18%
Would it be possible to print the name of the file causing the issue? They are quite useless right now.
I've made this warning message more verbose. I wouldn't worry about those messages too much, though. The expected number of frames is just an estimation to initialize the progress bar.
Yeah, it's not important. I'm just curious about the reason some files cause this warning. I will let the current run finish, and then pull the newest release and retry.
Thanks very much again.
Hi @jiixyj I think this issue can be closed now. Thanks.
According to rfc7845, the Opus tags SHOULD NOT be called REPLAYGAIN* but R128*.
Would it be possible to make the change?