Posts
| « | April 2007 | » | ||||
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| 8 | 9 | 10 | 11 | 12 | 13 | 14 |
| 15 | 16 | 17 | 18 | 19 | 20 | 21 |
| 22 | 23 | 24 | 25 | 26 | 27 | 28 |
| 29 | 30 | |||||
| « | April 2007 | » | ||||
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| 8 | 9 | 10 | 11 | 12 | 13 | 14 |
| 15 | 16 | 17 | 18 | 19 | 20 | 21 |
| 22 | 23 | 24 | 25 | 26 | 27 | 28 |
| 29 | 30 | |||||
After ending up with too many MP3 files without proper ReplayGain information, and knowing that mp3gain doesn't suit my needs quite right, I went jonesing around in GStreamer once again. Today was my lucky day, though; René Stadler had created a GStreamer element which calculates ReplayGain.
In what's starting to feel usual, Debian doesn't have up to date versions of the software I want to use in either testing or unstable, but this hasn't prevented the maintainer from packaging what I want to use and mirroring it in experimental. After downloading and installing it, I was good to go. First I put together a command-line example of the process, to make sure I knew what was required. Then I munged it into a plugin for Quod Libet.
There's still something fishy about it, as MP3s which I have previously found peak values for above 1.0 are now being reported capped to 1.0; Ogg Vorbis files, on the other hand, correctly exceed this cap and run presumably all the way to 2.0. I hope to clarify my understanding of this probable GStreamer bug shortly, as other than that all values match what I've seen before. I'm quite pleased the results of tonight's work.
Comments:
Michael Urman @ 2007.04.08 07:50:
cymacs on #gstreamer, who has been helping me all along, assures me that the 1.0 cap is related to the integer decoding used by GStreamer. Since this feeds clamped values to the analysis, the maximum the result can be is 1.0.
Tobias @ 2007.04.08 11:40:
Awesome, simply awesome. One less reason to resort to external tools (which often don't take tags into account). I didn't understand why the peak should reach 2.0. Isn't the peak the maximum sample value in the file, for a possible range 0-1.0?
Michael Urman @ 2007.04.08 16:11:
Looking at code that implements it, generally 16bit values that are scaled by 1/32768. Thus I expect 2.0 to be the cap, but something doesn't add up. (This would be as you describe, but with a 2x multiplier for reasons I cannot explain.)
Joe Wreschnig @ 2007.04.26 01:01:
I finally got around to actually using this today. The best part is that it's about twice as fast as mp3gain was.
Maybe they're clamping signed ints rather than unsigned ones?