After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 165834 - Compute ReplayGain tags
Compute ReplayGain tags
Status: RESOLVED OBSOLETE
Product: sound-juicer
Classification: Applications
Component: ripping
unspecified
Other Linux
: Normal enhancement
: ---
Assigned To: Sound Juicer Maintainers
Sound Juicer Maintainers
: 474911 (view as bug list)
Depends on: 127574
Blocks:
 
 
Reported: 2005-01-31 17:59 UTC by Rob Adams
Modified: 2021-05-17 15:47 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Rob Adams 2005-01-31 17:59:59 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.
Comment 1 Rob Adams 2005-02-06 17:10:32 UTC
Ah; you're obviously way ahead of me.  Carry on then :-)
Comment 2 René Stadler 2006-10-06 20:12:42 UTC
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.
Comment 3 Paul Fisher 2007-09-08 18:03:03 UTC
*** Bug 474911 has been marked as a duplicate of this bug. ***
Comment 4 Michael Monreal 2008-08-26 12:45:08 UTC
What's the status of the replaygain element and this bug in general?
Comment 5 René Stadler 2008-08-26 19:33:19 UTC
ReplayGain elements are in gst-plugins-good now.  To solve this bug, the hard part is still tagging the files.
Comment 6 lists 2010-09-04 07:31:31 UTC
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?
Comment 7 lists 2010-09-04 07:35:24 UTC
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
Comment 8 GNOME Infrastructure Team 2021-05-17 15:47:22 UTC
-- 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.