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 529424 - [rganalysis] Peak values never exceed 1.000
[rganalysis] Peak values never exceed 1.000
Status: RESOLVED NOTABUG
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
0.10.6
Other All
: Normal normal
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2008-04-22 19:56 UTC by Erik Christiansson
Modified: 2008-04-23 12:43 UTC
See Also:
GNOME target: ---
GNOME version: 2.21/2.22



Description Erik Christiansson 2008-04-22 19:56:08 UTC
Please describe the problem:
When using the rganalysis element to preform ReplayGain analysis the produced peak values, for both track and album, never exceed 1.000. When comparing the result to other tools such as foobar2000 or mp3gain the gain values (more or less) match, the peak values however don't.

Steps to reproduce:
1. Analyze a file; gst-launch -t filesrc location=/path/to/file.ext ! decodebin ! audioconvert ! audioresample ! rganalysis ! fakesink
2. Read output


Actual results:
Proper values for gain is calculated. Peak values are correct as long as they are lower than 1.000.

Expected results:
Receive proper gain values even if they exceed 1.000.

Does this happen every time?
Yes, at least all the files I've tested (apx. 30).

Other information:
Comment 1 René Stadler 2008-04-22 22:52:35 UTC
This isn't a bug in the element, the thing is that the mp3 decoder is producing output data in an integer format.  You can't exceed 1.0 with that, only with float formats.  This is not an issue as the fact that (float-based) decoders which actually give you float data that sometimes exceeds 1.0 is caused by some sort of compression artifacts.  The data you feed into an mp3 encoder is integer after all (so <=1.0), and the data that comes out of an mp3 decoder is ultimately  sent to an integer based sound card.

It has no effect on the gain values as you say, so it's save to ignore it.  It is even an advantage to clip to 1.0 because a higher peak value will lead the clipping prevention that is used on playback (see rgvolume docs) to applying a lower volume than actually needed.  I'm actually thinking of adding a property to the rgvolume element that makes it treat peak values >1.0 as 1.0 to improve the dynamic range a little for this case.  So in the end I have to say that the other tools you mention are broken :-)