IPB

Welcome Guest ( Log In | Register )

 
Reply to this topicStart new topic
Replay Gain difference in FLAC Frontend and FB2k, Their is a small difference...
Caster1024
post Oct 2 2003, 15:46
Post #1





Group: Members
Posts: 51
Joined: 14-September 03
Member No.: 8831



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!
Go to the top of the page
+Quote Post
seanyseansean
post Oct 2 2003, 15:52
Post #2





Group: Members (Donating)
Posts: 487
Joined: 12-August 02
From: Cheltenham, UK
Member No.: 3029



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.
Go to the top of the page
+Quote Post
john33
post Oct 2 2003, 17:02
Post #3


xcLame and OggDropXPd Developer


Group: Developer
Posts: 3760
Joined: 30-September 01
From: Bracknell, UK
Member No.: 111



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


--------------------
John
----------------------------------------------------------------
My compiles and utilities are at http://www.rarewares.org/
Go to the top of the page
+Quote Post
AstralStorm
post Oct 2 2003, 17:11
Post #4





Group: Members
Posts: 745
Joined: 22-April 03
From: /dev/null
Member No.: 6130



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. smile.gif

This post has been edited by AstralStorm: Oct 2 2003, 17:14


--------------------
ruxvilti'a
Go to the top of the page
+Quote Post
Garf
post Oct 2 2003, 17:15
Post #5


Server Admin


Group: Admin
Posts: 4884
Joined: 24-September 01
Member No.: 13



Excellent point Astral - I'll have to check what rounding Vorbisgain does.
Go to the top of the page
+Quote Post
NumLOCK
post Oct 2 2003, 17:22
Post #6


Neutrino G-RSA developer


Group: Developer
Posts: 852
Joined: 8-May 02
From: Geneva
Member No.: 2002



QUOTE (AstralStorm @ Oct 2 2003, 05:11 PM)
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. smile.gif

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


--------------------
Try Leeloo Chat at http://leeloo.webhop.net
Go to the top of the page
+Quote Post
indybrett
post Oct 2 2003, 17:24
Post #7





Group: Members (Donating)
Posts: 1350
Joined: 4-March 02
From: Indianapolis, IN
Member No.: 1440



I asked a similar question here:

http://www.hydrogenaudio.org/forums/index....3&hl=replaygain


--------------------
flac>fb2k>kernel streaming>audiophile 2496>magni>dt990 pro
Go to the top of the page
+Quote Post
Garf
post Oct 2 2003, 17:24
Post #8


Server Admin


Group: Admin
Posts: 4884
Joined: 24-September 01
Member No.: 13



ReplayGain info is all-float and the value 32767 has no special meaning.
Go to the top of the page
+Quote Post
Garf
post Oct 2 2003, 17:25
Post #9


Server Admin


Group: Admin
Posts: 4884
Joined: 24-September 01
Member No.: 13



QUOTE (indybrett @ Oct 2 2003, 06:24 PM)

The effect there was unrelated.
Go to the top of the page
+Quote Post
jcoalson
post Oct 4 2003, 04:30
Post #10


FLAC Developer


Group: Developer
Posts: 1526
Joined: 27-February 02
Member No.: 1408



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
Go to the top of the page
+Quote Post
Porcus
post Jan 3 2014, 01:01
Post #11





Group: Members
Posts: 1842
Joined: 30-November 06
Member No.: 38207



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.

This post has been edited by Porcus: Jan 3 2014, 01:02


--------------------
One day in the Year of the Fox came a time remembered well
Go to the top of the page
+Quote Post
saratoga
post Jan 3 2014, 01:34
Post #12





Group: Members
Posts: 4923
Joined: 2-September 02
Member No.: 3264



QUOTE (Porcus @ Jan 2 2014, 19:01) *
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.
Go to the top of the page
+Quote Post
Porcus
post Jan 3 2014, 08:53
Post #13





Group: Members
Posts: 1842
Joined: 30-November 06
Member No.: 38207



QUOTE (saratoga @ Jan 3 2014, 01:34) *
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.


--------------------
One day in the Year of the Fox came a time remembered well
Go to the top of the page
+Quote Post
nu774
post Jan 3 2014, 09:52
Post #14





Group: Developer
Posts: 522
Joined: 22-November 10
From: Japan
Member No.: 85902



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.
Go to the top of the page
+Quote Post
2Bdecided
post Jan 6 2014, 12:39
Post #15


ReplayGain developer


Group: Developer
Posts: 5108
Joined: 5-November 01
From: Yorkshire, UK
Member No.: 409



QUOTE (nu774 @ Jan 3 2014, 08:52) *
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.
Go to the top of the page
+Quote Post
DVDdoug
post Jan 8 2014, 01:27
Post #16





Group: Members
Posts: 2566
Joined: 24-August 07
From: Silicon Valley
Member No.: 46454



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.
Go to the top of the page
+Quote Post
nu774
post Jan 8 2014, 03:09
Post #17





Group: Developer
Posts: 522
Joined: 22-November 10
From: Japan
Member No.: 85902



QUOTE (2Bdecided @ Jan 6 2014, 20:39) *
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)

QUOTE (2Bdecided @ Jan 6 2014, 20:39) *
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.
Go to the top of the page
+Quote Post
2Bdecided
post Jan 8 2014, 11:14
Post #18


ReplayGain developer


Group: Developer
Posts: 5108
Joined: 5-November 01
From: Yorkshire, UK
Member No.: 409



QUOTE (nu774 @ Jan 8 2014, 02:09) *
QUOTE (2Bdecided @ Jan 6 2014, 20:39) *
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
QUOTE (2Bdecided @ Jan 6 2014, 20:39) *
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.
Go to the top of the page
+Quote Post
Porcus
post Jan 8 2014, 13:17
Post #19





Group: Members
Posts: 1842
Joined: 30-November 06
Member No.: 38207



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.


--------------------
One day in the Year of the Fox came a time remembered well
Go to the top of the page
+Quote Post
lithopsian
post Apr 7 2014, 00:38
Post #20





Group: Members
Posts: 171
Joined: 27-February 14
Member No.: 114718



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.

This post has been edited by lithopsian: Apr 7 2014, 00:50
Go to the top of the page
+Quote Post

Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 30th August 2014 - 16:29