GNOME Bugzilla – Bug 127574
replaygain support
Last modified: 2008-10-04 21:43:28 UTC
It would be great if gstreamer could support replaygain metadata in flac files (and other formats too). http://replaygain.hydrogenaudio.org/index.html flac files with replaygain metadata created by metaflac: metaflac --add-replay-gain file1.flac file2.flac
Replay Gain is also available in Ogg Vorbis. The tool vorbisgain, made by Garf, works very well. I'll look into making a plug-in. (I've been needing an excuse to learn the framework's innards).
Standard replaygain fields may be found in any tag format for any audio format, so if replaygain is supported the tags should be looked for no matter what audio is loaded. E.g. foobar2000 on windows can place RG tags in APEv2/id3v2 tags for MP3, and also tags WMA files with RG info foobar2000.org. The field names are standardised.. e.g. replaygain_track_gain = -9.60 dB replaygain_track_peak = 1.170440 replaygain_album_gain = -10.41 dB replaygain_album_peak = 1.248962 Btw, if APEv2 tags are not supported (independent of format) then they should be (APE - monkeys audio tags).
I'd love a replaygain gain element I can put in the Sound Juicer pipeline.
gst has the following 4 tags : GST_TAG_TRACK_GAIN/PEAK GST_TAG_ALBUM_GAIN/PEAK for now, they are only provided by the 'vorbistag' element
Created attachment 37344 [details] [review] Patch to (possibly) read replaygain data from ape tags apetag should supply replaygain info, if present (foobar2000 tags mp3s with ape, and places rg data in these tags). I have attached a simple patch (IANAP) that will hopefully at least draw some attention..
Replaygain info is often present in the header of musepack files. libmusepack will read and supply these values as streaminfo... gain_title peak_title gain_album peak_album It would be nice if the musepack plugin could supply these values somehow.. ideally in the same way as the vorbis tag reader supplies them (GST_TAG_TRACK_GAIN etc).. so rhythmbox uses it the same way as for flac and vorbis.
Comment on attachment 37344 [details] [review] Patch to (possibly) read replaygain data from ape tags The patch needs to set i=TRUE for each value (it means: this value is an integer), and don't remove it for "track". I'd be interested in a patch for musepack as well, I will do it myself eventually if nobody else provides a patch.
Comment on attachment 37344 [details] [review] Patch to (possibly) read replaygain data from ape tags >--- gst/apetag/apedemux.c 2004-12-23 12:42:48.000000000 +0000 >+++ gst/apetag/apedemux.c.RG 2005-02-11 13:54:29.000000000 +0000 >@@ -473,6 +473,18 @@ > type = GST_TAG_ISRC; > } else if (!strcasecmp (tag, "track")) { > type = GST_TAG_TRACK_NUMBER; > i = TRUE; >+ } else if (!strcasecmp (tag, "replaygain_track_gain")) { >+ type = GST_TAG_TRACK_GAIN; >+ i = TRUE; >+ } else if (!strcasecmp (tag, "replaygain_track_peak")) { >+ type = GST_TAG_TRACK_PEAK; >+ i = TRUE; >+ } else if (!strcasecmp (tag, "replaygain_album_gain")) { >+ type = GST_TAG_ALBUM_GAIN; >+ i = TRUE; >+ } else if (!strcasecmp (tag, "replaygain_album_peak")) { >+ type = GST_TAG_ALBUM_PEAK; >+ i = TRUE; > } > if (type) {
Created attachment 38258 [details] [review] Better version of the 'use RG info in ape tags' patch Ok, I guess I should do this instead of the comment above. I suppose this fixes that patch. Mostly.
The patch has been committed. We still need to read the same info from other elements (FLAC, speex, musepack, probably a whole bunch more). However, that is an implementation detail, I'm not going to keep the bug open for that. What I *do* keep this bug open for, is the lack of a replaygain measuring element, like Ross said.
*** Bug 171124 has been marked as a duplicate of this bug. ***
I think I should point out that replaygain values are NOT integers.. something which I missed before... so the attached patch, which has been in apetag for ages, is wrong. Here's what they look like... replaygain_track_gain = +0.70 dB replaygain_track_peak = 0.972321
*** Bug 323720 has been marked as a duplicate of this bug. ***
Available in cvs apedemux (gst-plugins-good). Closing
Re-opening, didn't notice the bug was for Setting those tags too.
(In reply to comment #3) > I'd love a replaygain gain element I can put in the Sound Juicer pipeline. > I'm working on this. In spite of having done no work on GStreamer or anything sound processing related before, I got this pretty quickly to some working state (thanks to lots of existing code of course). See the following command as some kind of `vorbisgain --display-only': $ gst-launch filesrc location=test1.ogg \ ! decodebin ! rganalysis force=true ! fakesink -t * Output: Setting pipeline to PAUSED ... Pipeline is PREROLLING ... FOUND TAG : found by element "vorbisdec1". title: Concerto in D Major, RV512, I. Allegro molto artist: Antonio Vivaldi album: 6 Double Concertos replaygain track peak: 0.775115 replaygain track gain: 0.210000 replaygain album peak: 0.955308 replaygain album gain: 0.590000 encoder: Xiph.Org libVorbis I 20020717 encoder version: 0 audio codec: Vorbis nominal bitrate: 256000 bitrate: 256000 Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock: GstSystemClock * After some seconds, this comes in: FOUND TAG : found by element "rganalysis0". replaygain track peak: 0.775115 replaygain track gain: 0.210000 Got EOS from element "pipeline0". Execution ended after 3720342000 ns. Setting pipeline to PAUSED ... Setting pipeline to READY ... Setting pipeline to NULL ... FREEING pipeline ... Give me some more time for tinkering and polishing things up, then I'll post it for review.
Rene: when finished if I can just drop that into the Sound Juicer pipeline and automatically get track-replaygain tags set, you are MY NEW HERO.
(In reply to comment #17) > Rene: when finished if I can just drop that into the Sound Juicer pipeline and > automatically get track-replaygain tags set, you are MY NEW HERO. > I did some investigation and found out that this is not going to work. Neither oggmux nor flacenc incorporate meta data they receive after caps nego into the resulting stream. Examination of flacenc shows that it is not a limitation of GStreamer. It is (lib)flac that simply does not support such completion of meta data in the final header fix-up. I'm sure ogg has a similar limitation.
By the way, I would like to note that this bug should also stay open after the analysis element is finished: GStreamer also needs ReplayGain playback support (as an element). It should act like some sort of bin controlling a GstVolume + some limiter and interpret any tags that come along its path to make the volume/limiting adjustment automatically. This process is driven by some options that need to be user-adjustable, maybe this can be done through gconf and go into gstreamer-properties. That would solve a whole bunch of problems for many gst based players that want to support RG (that's all players, right?). I already played a bit around with these ideas in code, but try to stay focused on finishing rganalysis first (busy writing proper checks now).
Provided the ReplayGain analysis element for inclusion in gst-plugins-bad as bug #357069: http://bugzilla.gnome.org/show_bug.cgi?id=357069 About playback support: Seems likely that I will provide an element "rgvolume" that listens for tags on the pipeline and then applies the volume adjustment to raw data that passes through it, with element properties album-mode, prevent-clipping, pre-amp, fallback-gain. The original idea as a bin with volume + limiter is not very flexible, because apps might want to have additional processing elements between these. Also, a limiter is nothing specific to ReplayGain, it just depends on it if clipping-prevention is off.
ANd what about computing ReplayGain value for albums from the RB interface? Same way as in foobar2000 - select an album, right click, "compute ReplayGain". And ability for performing it over all non-replaygained albums.
(In reply to comment #21) > ANd what about computing ReplayGain value for albums from the RB interface? > Same way as in foobar2000 - select an album, right click, "compute ReplayGain". > And ability for performing it over all non-replaygained albums. > You should refer to the various ReplayGain related bugs filed against RB for that request. This bug is about the GStreamer parts that are needed for ReplayGain. The rganalysis element is already available and can be used to do what you want already.
What is the status of this bug? The rgvolume and rganalysis elements do what need doing, correct?
Indeed, and they are in gst-plugins-good now. If any encoder/muxer/demuxer/parser/decoder elements are still missing support for the metadata tags somewhere, this would best be handled as separate, specific bugs.