Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Replay Gain difference in FLAC Frontend and FB2k (Read 13822 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Replay Gain difference in FLAC Frontend and FB2k

Hello,

I've noticed when you find the replay gain for .flac files with FB2k, you get a slightly different value then if you did it with FLAC Frontend.  The FB2k amount is slightly off for all peak values.

Such as FLAC Frontend woud've put something like .99996982
FB2K would've put .999969

I know this is a very small difference, the actuall difference being only +-.01 Db gain in some cases, but i was wondering if this is a bug or if FB2K just simplifies it?

Any input is a appreciated.

Thanks!

Replay Gain difference in FLAC Frontend and FB2k

Reply #1
Floating point rounding errors, could come from different compilers/cpus/pretty much anything.

As it's so little I wouldn't worry about it.

seany.

Replay Gain difference in FLAC Frontend and FB2k

Reply #2
I haven't researched it, but it could be no more complicated than the authors' decisions on the length of the data to store.

 

Replay Gain difference in FLAC Frontend and FB2k

Reply #3
Anyway, the number should be rounded up or else there might be clipping even with clipping protection on.
The easiest way to avoid it would be to add 0.000001 to the calculated value - cheap hack.
ruxvilti'a

Replay Gain difference in FLAC Frontend and FB2k

Reply #4
Excellent point Astral - I'll have to check what rounding Vorbisgain does.

Replay Gain difference in FLAC Frontend and FB2k

Reply #5
Quote
Anyway, the number should be rounded up or else there might be clipping even with clipping protection on.
The easiest way to avoid it would be to add 0.000001 to the calculated value - cheap hack.

You can do abs(ceil()) on the value, and see if it's exceeding 32767 


Replay Gain difference in FLAC Frontend and FB2k

Reply #7
ReplayGain info is all-float and the value 32767 has no special meaning.


Replay Gain difference in FLAC Frontend and FB2k

Reply #9
There are a few versions of gain_analysis.c floating around.  For FLAC I used the one that's used in vorbisgain (which has some tweaks by Frank Klemm).  Not sure what fb2k uses.

But this looks more like output precision writing the tag.

Josh

Replay Gain difference in FLAC Frontend and FB2k

Reply #10
Bumping a >10 year old thread, but: was this ever resolved? Wouldn't it be a good idea to round up the value upon writing?
There have recently been discussions on Windows' limiter striking in at fractions of a dB below zero ...

The reason why I found this thread, was that an album peak of 0.999969 occurs in over thirteen percent of my ripped albums. I searched for "999969" for a known explanation. Haven't found any.

Replay Gain difference in FLAC Frontend and FB2k

Reply #11
The reason why I found this thread, was that an album peak of 0.999969 occurs in over thirteen percent of my ripped albums. I searched for "999969" for a known explanation. Haven't found any.



1/(1-0.999969) = 32258, which is (within rounding error) the maximum value allowed in signed 16 bit audio. 

Most likely the tag was rounded down from 0.9999694 or so, which would be a peak normalized album scaled one level below full scale.

Replay Gain difference in FLAC Frontend and FB2k

Reply #12
Most likely the tag was rounded down


But as suggested above, why not round up? As long as the playback software uses higher resolution or floating point internally in the volume control, you could exceed zero.

Replay Gain difference in FLAC Frontend and FB2k

Reply #13
Since replaygain spec doesn't say anything about rounding method, I guess many (most) of implementations are just doing something like sprintf(tag, "%.6f", gain), so the result should be compiler dependent.
(AFAIK, GCC does bankers' rounding for it, and MSVC does rounding to the nearest)

BTW I found the following line in replaygain spec, which is somewhat astonishing:
Quote
.mp4 also .m4a, .m4b, .m4p, m4r (MPEG-4 Part 14) – ID3v2 (in "ID32" box)

Do you know any single spec compliant implementation that actually uses ID32 box? I don't know.

Replay Gain difference in FLAC Frontend and FB2k

Reply #14
Since replaygain spec doesn't say anything about rounding method
The original spec suggested storing the peak as a 32-bit floating point value with digital full scale = 1. I included a note to suggest that further clarification may be necessary (thinking that 16-bit full scale is -32768 not +32767), but never followed it up.

With 16-bit audio, 32768 scales to 1.
With 24-bit audio, 8388608 scales to 1.

With 32-bit floating point as the storage format for the peak value, you never need to round it.

Storing it in decimal, you need 7 decimal places.


I don't think it's rounding that's causing the "problem" here. It's a combination of factors, but mostly the asymmetric nature of digital audio, and dumb software ignoring it. e.g. if the peak is at +32767, you can't amplify that to +32768 because that number doesn't exist in 16-bit audio. Software that dumbly looks at 0.9999694824... and tries to scale the audio by 1.00003051851 is making a mistake.

I'm guessing all the CDs with a stored peak of 0.999969 have +/-32767 sample values, but no -32768 value, which is fair enough.

Cheers,
David.

Replay Gain difference in FLAC Frontend and FB2k

Reply #15
Quote
Such as FLAC Frontend woud've put something like .99996982
FB2K would've put .999969

I know this is a very small difference, the actuall difference being only +-.01 Db gain in some cases,
I'm not sure I trust Excel (or myself) when calcalulating logs with this kind of precision, but I get  a 0.00000712dB difference between those two values!

I'm pretty sure it's a LOT LESS than 1/100th of a dB.

Replay Gain difference in FLAC Frontend and FB2k

Reply #16
With 32-bit floating point as the storage format for the peak value, you never need to round it.
Storing it in decimal, you need 7 decimal places.

Or maybe 8? For example, 32bit floating point value for 3.141592 (7 digits) has 4 possibilities (40490FD8 to 40490FDB, in hex representation)

I don't think it's rounding that's causing the "problem" here. It's a combination of factors, but mostly the asymmetric nature of digital audio, and dumb software ignoring it. e.g. if the peak is at +32767, you can't amplify that to +32768 because that number doesn't exist in 16-bit audio. Software that dumbly looks at 0.9999694824... and tries to scale the audio by 1.00003051851 is making a mistake.

Good point. However, it can be that scaling logic in the filter chain is placed independent from requantization, therefore does not have the knowledge about final bit-depth at all. Moreover, things can get worse anyway due to dither/noise shape on the final stage.
So, simple rule/habit of always making a certain amount of headroom sounds enough to me, although I doubt that "clipping" introduced by THAT tiny difference is really a "problem" or audible in any way.

Replay Gain difference in FLAC Frontend and FB2k

Reply #17
With 32-bit floating point as the storage format for the peak value, you never need to round it.
Storing it in decimal, you need 7 decimal places.

Or maybe 8? For example, 32bit floating point value for 3.141592 (7 digits) has 4 possibilities (40490FD8 to 40490FDB, in hex representation)
I was assuming no real audio source files beyond 24-bits (though lossy formats can be decoded to higher). I could still have been wrong though!

Quote
I don't think it's rounding that's causing the "problem" here. It's a combination of factors, but mostly the asymmetric nature of digital audio, and dumb software ignoring it. e.g. if the peak is at +32767, you can't amplify that to +32768 because that number doesn't exist in 16-bit audio. Software that dumbly looks at 0.9999694824... and tries to scale the audio by 1.00003051851 is making a mistake.

Good point. However, it can be that scaling logic in the filter chain is placed independent from requantization, therefore does not have the knowledge about final bit-depth at all. Moreover, things can get worse anyway due to dither/noise shape on the final stage.
So, simple rule/habit of always making a certain amount of headroom sounds enough to me, although I doubt that "clipping" introduced by THAT tiny difference is really a "problem" or audible in any way.
Agreed. You could also drop in a bit of logic that, when the peak value ends up defining the scaling (i.e. when the ReplayGain adjustment + pre-amp setting pushes the audio over digital full scale) then if that peak value is between 0.99996 and 1, just don't scale. That would keep obsessives happy, though an always present built-in tiny amount of headroom is easier and does no harm.

I didn't imagine clipping by an amount equal to the amplitude of 1 LSB did any harm either, until I read the comment in this thread about windows limiter kicking in. I haven't looked at that at all.

Cheers,
David.

Replay Gain difference in FLAC Frontend and FB2k

Reply #18
That Windows limiter thing: http://www.hydrogenaudio.org/forums/index....howtopic=104051 and, linked to therein,
http://blogs.msdn.com/b/matthew_van_eerde/...le-signals.aspx

Looks like a sensible RG implementation for Windows would be apply gain and prevent clipping according to peak+0.02 rather than according to peak.

Replay Gain difference in FLAC Frontend and FB2k

Reply #19
I don't think anyone mentioned in this thread that the ID3v2 format for replaygain specs 2 decimal places for the peak tags and 6 for the peak tags, and many players use this format throughout.  However Flac (and other formats using the VorbisComment tags) specify and use 8 digits for the peak tags.  It may well be that what you see in Foobar is entirely the result of this.  I've even seen implementations that use 8 decimal places for the gain tags although that seems somewhat pointless.

It is worth noting that a typical 32-bit single precision float should be able to accurately convert 6 decimal digits back and forth without rounding issues.  Beyond that there can definitely be problems and you'd want to use a double to be sure of keeping 8 digits intact.

Re: Replay Gain difference in FLAC Frontend and FB2k

Reply #20
Sorry for bumping an old thread...thought this would be the proper place to ask though.

Most important to me is which program, FLAC command line or Foobar2000 calculates the more accurate replaygain values that will yield a closer result to the target dB (in this case 89dB).

I never found or didn't understand the answer if it was listed in this thread. I know a difference of a tenth or hundredth of a dB (if not 10-7 dB) is nothing but I'm finding a difference of over 2dB sometimes. This is one of my Rush (Japanese mastered) CDs.

And if anyone can answer, why is there such a difference in values...is there an easy answer?

The track peak values are nearly identical, if they are different it's out at like the 5th or 6th decimal point.

These are the track gain values...a difference of 2.17dB I feel would be noticable.
CMD:      Foobar:     Difference
-2.37     -3.64     1.27
-2.34     -3.69     1.35
-0.93     -2.36     1.43
-1.17     -2.15     0.98
-0.39     -2.56     2.17
-0.76     -1.91     1.15
-0.09     -0.87     0.78
-0.46     -2.31     1.85


Re: Replay Gain difference in FLAC Frontend and FB2k

Reply #22
Most important to me is which program, FLAC command line or Foobar2000 calculates the more accurate replaygain values that will yield a closer result to the target dB (in this case 89dB).
That can't be answered. How loud something sounds depends at least on playback equipment, playback volume and listener's ears.

But foobar2000 switched to the ITU-R BS.1770 loudness estimator because we found it to give better results. If you wish, you can make your own test. Switch your player to use Track Gain and play various tracks and see if one method gives steadier loudness than the other.