GNOME Bugzilla – Bug 165834
Compute ReplayGain tags
Last modified: 2021-05-17 15:47:22 UTC
It'd be nifty if sound-juicer computed the ReplayGain information and tagged extracted tracks automatically. For reference please see the vorbisgain commandline program. Rhythmbox, XMMS, BEEP, and other players support this and it makes the whole process of shuffle-listening much more pleasant since the volume is appropriately normalized.
Ah; you're obviously way ahead of me. Carry on then :-)
There is now a ReplayGain analysis element in gstreamer (in gst-plugins-bad CVS). It's called rganalysis and is provided by the replaygain plugin. I was told that the code looks good and that it will move to gst-plugins-good rather sooner than later, so this is ready to go. It natively supports the CD raw audio format, so SJ can include this in the pipeline easily. There are some complications that fall outside of the scope of the element though: As pointed out in the rganalysis documentation and in bug #127574 comment #18, muxer and encoder elements generally cannot save the tags generated by the analysis in their output since they become available just before the stream ends. I'm not sure if an easy and efficient solution for that exists that applications like SJ can make use of. Another problem is to detect when to _not_ run the ReplayGain analysis, which would be the case if the output data format provides no support to store the tags. That's the thought behind bug #345352. A solution might be to only include the rganalysis element as part of the editable pipeline descriptions from the media profiles, although that also has downsides. The dependency on bug #127574 can be lifted, it will probably stay open until I finish the ReplayGain volume/synthesis element.
*** Bug 474911 has been marked as a duplicate of this bug. ***
What's the status of the replaygain element and this bug in general?
ReplayGain elements are in gst-plugins-good now. To solve this bug, the hard part is still tagging the files.
Hello, It seems like progress on this has stalled. I know that the FLAC commandline application supports replaygain: == --replay-gain Calculate ReplayGain values and store them as FLAC tags, similar to VorbisGain. Title gains/peaks will be computed for each input file, and an album gain/peak will be computed for all files. All input files must have the same resolution, sample rate, and number of channels. Only mono and stereo files are allowed, and the sample rate must be one of 8, 11.025, 12, 16, 22.05, 24, 32, 44.1, or 48 kHz. Also note that this option may leave a few extra bytes in a PADDING block as the exact size of the tags is not known until all files are processed. == This would be ideal for me, as I only rip FLAC (and then generate Vorbis etc from those, when needed) and really like the idea that it would do both "track" and "album" replaygain tags if I ripped multiple tracks from the same CD (I wouldn't get album replaygain tags if I just ran a script over the FLAC files). Is there any way to pass this commandline option to the FLAC encoder through the gst pipeline, perhaps by editing the FLAC profile? I'm wondering if perhaps adding options to the profiles could be a quick and dirty fix until the GStreamer element is working properly?
For anyone interested, it looks like rganalysis has made it into Good: http://www.gstreamer.net/data/doc/gstreamer/head/gst-plugins-good-plugins/html/gst-plugins-good-plugins-rganalysis.html
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/sound-juicer/-/issues/25.