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: Confused by R128 ReplayGain scanning (Read 5503 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Confused by R128 ReplayGain scanning

So today I purchased a FLAC track from bandcamp.  First, I made a copy and had Foobar 1.3.7 ReplayGain scan by right clicking.... this is what it generated



Then, I took another copy of the original into Jriver Media Center 20 and scanned it.  This is what it generated:



The ReplayGain values appear to be the same, but I thought Foobar switched to R128 scanning a while back?
Am I somehow incorrectly doing the scan?  Do I need to instruct Foobar to do R128 scanning in addition to legacy ReplayGain?

Thanks

Confused by R128 ReplayGain scanning

Reply #1 –
Would be great in FB2K included DR and EBU scanning/reading in its properties pane. Then I could finally ditch that buggy DR component!

Confused by R128 ReplayGain scanning

Reply #2 –
I thought foobar2000 RG scanner was based on R128?

Confused by R128 ReplayGain scanning

Reply #3 –
What is the confusion here? foobar's scanner uses the same loudness evaluation method as EBU R128. The R128 peaks you see in the lower screenshot are from True Peak scanning which foobar2000 doesn't use.

Confused by R128 ReplayGain scanning

Reply #4 –
Both use EBU R128 calculation. Fb2k (like most sensible software) applies a 5dB shift when writing the value to ReplayGain tags. Or, to say the same thing a different way, it uses a -18LUFS target instead of -23LUFS.

True peak is the reconstructed inter-sample peak, which can be higher than digital full scale. Peak is the on-sample peak (i.e. largest sample value stored in the file).

Cheers,
David.

Confused by R128 ReplayGain scanning

Reply #5 –
Thank you Case and 2Bdecided -- this helps a lot and clears this up.  Cool.

Confused by R128 ReplayGain scanning

Reply #6 –
@Case/2B: I'd like to see true peak scanning in the fb2k RG component.
"I hear it when I see it."

Confused by R128 ReplayGain scanning

Reply #8 –
So in Foobar if I right click and select Properties (looking at the Metadata tab), then also from Windows Explorer with dbPoweramp right click and select Edit-IDTag, why do the ReplayGain fields NOT appear in Foobar Properties/Metadata?  In library view, I know that Foobar sees these replaygain tags because I have a column "%replaygain_track_gain%" that populates properly.  I just don't understand why these ReplayGain tags do not appear in the Properties/Metadata window.

See image

Confused by R128 ReplayGain scanning

Reply #9 –
Quote from: jaynyc on
I just don't understand why these ReplayGain tags do not appear in the Properties/Metadata window.

Because foobar2000 shows them in Properties/Properties tab.

Confused by R128 ReplayGain scanning

Reply #11 –
I'm still confused. Lots of people say that foobar2000 targets -18 LUFS, but I thought the ReplayGain standard targets -14 LUFS according to the HA wiki and Wikipedia.

Confused by R128 ReplayGain scanning

Reply #12 –
From HA wiki:
Quote
RG1 is calibrated to a pink noise reference signal with a RMS level 14 dB below a full-scale sinusoid. [...]
BS-1770 defines a loudness scale for program material. The units of BS.1770 loudness measurements are in Loudness Units [relative to] Full Scale (LUFS). LUFS can be treated like decibels.
The loudness measurement of the RG1 reference signal is -18 LUFS. In order to maintain backwards compatibility with RG1, RG2 uses a -18 LUFS reference.
"I hear it when I see it."

Confused by R128 ReplayGain scanning

Reply #13 –
Neither this nor this show the quote you specified. Mind posting a direct link to the page for future reference?

Edit: I found the page. The problem is that only the Opus page links to that entry. That ought to be corrected. I'm still confused how people came up with -18 LUFS when multiple pages keep stating that ReplayGain plays at -14 dBFS, which is basically -14 LUFS. One possibility I thought of is that -18 LUFS seems to be the halfway point between -23 LUFS and -14 LUFS. Then again, that's just me making a wild guess because many sites I checked treat -18 LUFS as dogma without explaining the -4 LUFS discrepancy.

Confused by R128 ReplayGain scanning

Reply #15 –
There was a thread very early on where that 5dB offset (implemented even before the thread started AFAICT) was shown to be approximately correct...
http://www.hydrogenaud.io/forums/index.php...st&p=759785

You would think that the original ReplayGain, trying to match the loudness of a -20dB FS RMS pink noise file, and then adding 6dB to the result, would result in a loudness of -14 LUFs according to EBU R128. While the analysis of the pink noise file does pretty much match up in this way (when you "listen" to the pink noise file in stereo), the analysis of actual music doesn't. IIRC there were a couple of papers (which sadly I've now lost the links to) which found a similar result.

Hence it's approximately -18LUFs, not -14LUFs, because analysis of lots of music through both algorithms showed this is a reasonable match.

The two algorithms are very different, so there are some audio tracks where they give very different results. There are some examples in the thread linked above. Unfortunately the ref_pink.wav signal used as the reference for the original ReplayGain calculation appears to be one of those outliers, so can't be used as the basis of figuring out the equivalence.

(With apologies if I have mis-remembered any of this. I haven't worked on ReplayGain for a long time. I won't mind if someone corrects me.)

Cheers,
David.
 

Confused by R128 ReplayGain scanning

Reply #17 –
Another question: when foobar2000 applies the offset to match the target -18 LUFS for ReplayGain, is it +5 LUFS or +5.4 LUFS? Past threads keep waffling between the two values. One user suggested it's 5.4 LUFS while this thread says it's 5 LUFS.