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: ReplayGain: File volume instead of the quantity to be modified (Read 1660 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

ReplayGain: File volume instead of the quantity to be modified

Hi there!

Is there any way to make foobar2000 scan files and present a result like the one below, from EZ CD Audio Converter?

Instead of showing -11.0 dB, for example, EZ CD shows 100.0 dB, that is, the volume of the file and not the number of decibels that will be attenuated.

Thanks in advance!

Re: ReplayGain: File volume instead of the quantity to be modified

Reply #1 –
The ReplayGain info isn't supposed to be displayed that way, if memory serves, so it's probably not something foobar2000 will one day do by default. And 100dB should at least be labelled Track Volume, not Track Gain.

The popup window displaying the results can't be changed, but I often found myself wanting to see them again after I'd closed it, so I created a tab containing the Playlist View element for displaying volume. Chances are you won't want to get that carried away, but you could create a custom playlist column for your current setup, and once the tags are updated, it might make it more accessible.

This should display the volume in the way you asked. I don't use it myself because it's mental, but I think it's just a matter of subtracting the TrackGain value from 89 and making it display nice.

ReplayGain Volume (calculated from track gain).
Code: [Select]
$if(%replaygain_track_gain%,$puts(TRACK_VOLUME,$sub(8900,$replace(%replaygain_track_gain%,.,)))$ifgreater($get(TRACK_VOLUME),9999,$substr($get(TRACK_VOLUME),1,3).$substr($get(TRACK_VOLUME),4,5),$substr($get(TRACK_VOLUME),1,2).$substr($get(TRACK_VOLUME),3,4)) dB)

The ReplayGain target volume of 89dB is a sound pressure level and rather meaningless to mere mortals. If you're interested, this is the syntax I use for displaying volume in a normal manner.

Volume (calculated from track gain).
Code: [Select]
$if(%replaygain_track_gain%,$pad_right($puts(TRACK_VOLUME,$sub(-1800,$replace(%replaygain_track_gain%,.,)))$ifequal($get(TRACK_VOLUME),0,0,$ifgreater($get(TRACK_VOLUME),0,$replace(+$substr($num($get(TRACK_VOLUME),4),1,2),+0,+),$replace($substr($num($get(TRACK_VOLUME),5),1,3),-0,-))).$substr($num($get(TRACK_VOLUME),5),4,5),6) dB)

ReplayGain's 89dB target volume is equivalent to -18dB or -18 LUFS in human-speak, or -18dB on an output meter. The TrackGain and AlbumGain values still work the same way, but you can think of them as being relative to -18dB, instead of relative to a volume that doesn't make sense.

Anyhow, to test the syntax for displaying volume as ReplayGain mumbo jumbo, I added a column to my setup, and attached a pic so you can see what I'm talking about. The "ReplayGain Volume" column is displaying it in ReplayGain-speak. The "Volume" column is displaying it as the rest of the world does.

Re: ReplayGain: File volume instead of the quantity to be modified

Reply #2 –
Dear @yetanotherid

You managed to solve my need. It was exactly what I needed and I really wanted to not need to use another program besides foobar. It works wonderfully here!

Thank you very much for your attention and for the enlightening teachings. Your teaching is very objective and clear.

All the best to you!

Re: ReplayGain: File volume instead of the quantity to be modified

Reply #3 –
Hi!
Would the "Volume" column be equivalent to the measure expressed by the VU?
 

Re: ReplayGain: File volume instead of the quantity to be modified

Reply #4 –
I thought the EU R128 method of determining volume was somewhat similar to a VU meter (foobar2000 uses it for ReplayGain scanning rather than the original ReplayGain method), but I wished you hadn't asked because I ran some tests and now I'm a little confused.

I guess it's possible the R128 method for determining volume on an output meter differs from the way it's determined when scanning a complete file, as it'd be more long term loudness, but according to the foobar2000 R128 Meter component (it only displays volume as text) the volume is consistently 3dB lower than the ReplayGain result, assuming the official ReplayGain volume is the equivalent of -18dB, which is the figure I obtained from this forum at some stage, and seems to be universally accepted. Hopefully an expert on this will join the thread and shed some light on the reason for the volume difference.....

In these screenshots, the meter on the left is the VU meter and on the right is the peak meter.
Calculated volume is the volume I've calculated based on ReplayGain's 89dB being equal to -18 dB/LUFS (it's the Volume column)
The VU and peak meter volumes are my estimates looking at the meters.
The ReplayGain volume is based on the TrackGain value after a ReplayGain scan.

I also added the results of a scan courtesy of MP3Gain, as it uses the original scanning method. It's not shown in the screenshots. The results surprised me a little, even taking into account they might vary slightly, as I had to convert the FLAC files to MP3 in order to scan them. If the results were the same as for a fb2k scan, they'd be 89dB. They're labelled "MP3Gain volume".

1k tone at ReplayGain volume
fb2k ReplayGain: 89dB
R128 Meter: -21LUFS
VU meter: -21dB
Peak meter: -18dB
Calculated: -18 dB/LUFS
MP3Gain volume: 85.2dB

Pink noise at ReplayGain volume
fb2k ReplayGain: 89dB
R128 Meter: -21LUFS
VU meter: Average of roughly -20dB
Peak meter: Average of roughly -10dB
Calculated: -18 dB/LUFS
MP3Gain volume: 84.9dB

White noise at ReplayGain volume
fb2k ReplayGain: 89dB
R128 Meter: -21LUFS
VU meter: Fairly steady at -24dB
Peak meter: Fairly steady at -14dB
Calculated: -18 dB/LUFS
MP3Gain volume: 81.6dB

You can see in the screenshots I also made equivalent samples at ReplayGain volume +8dB, to check if the results differed with volume. They didn't, so I won't bother posting screenshots. Just add 8dB to all the numbers above and you'd have the results.

Re: ReplayGain: File volume instead of the quantity to be modified

Reply #5 –
Looking at the results it does make me wonder if fb2k's ReplayGain scanner could be off by 3dB in respect to the calculated volume. If you reduced the fb2k ReplayGain results by 3dB they'd be more in line with everything else, so I scanned the same files with R128Gain.
As per the results above, these files are all 89dB / -18 LUFS according to a fb2k scan.

1k tone at ReplayGain volume
R128Gain ReplayGain scan: 85.2dB
R128Gain scan: -21 LUFs / 86dB

Pink noise at ReplayGain volume
R128Gain ReplayGain scan: 85dB
R128Gain scan: -21 LUFs / 86dB

White noise at ReplayGain volume
R128Gain ReplayGain scan: 81.6dB
R128Gain scan: -21 LUFs / 86dB

Unless I'm seriously missing the plot or confusing myself, foobar2000's ReplayGain scan results do seem to be off by 3dB.
If that's true, they should correspond fairly closely to what a VU meter says when they're correct.
I'm using fb2k 1.5.6.

Re: ReplayGain: File volume instead of the quantity to be modified

Reply #6 –
@yetanotherid

Your teaching is very good, thanks for the very timely clarifications.

Would you know if it is possible to create a column showing the maximum value of a measure expressed in VU?

Something, for example, like this: Peak VU: -10.0 dB

Re: ReplayGain: File volume instead of the quantity to be modified

Reply #7 –
@Adil
Hi.
Not that I'm aware of. There's no fb2k syntax for that.
BTW, I sent a PM to Case in the hope to discover the reason for the apparent 3dB volume discrepancy. It doesn't appear to happen with the EBU R128 test files, so I'm not sure what's going on with the samples I used previously... yet.

Re: ReplayGain: File volume instead of the quantity to be modified

Reply #8 –
Channel count? (Downmixing algorithm in use?)

Re: ReplayGain: File volume instead of the quantity to be modified

Reply #9 –
@kode54 
They test samples are all mono. I wonder if that's got something to do with it. It hadn't occurred to me it might until you asked.
I downloaded the latest EBUR128 test files and gave them a spin and I thought fb2k was producing the same result as R128Gain, give or take, but they're mostly stereo. There's one mono file though, and sure enough, fb2k says -19.96 LUFs and R128 says -23 LUFS.
There's one 6ch file in the bunch and they both agree on -23 LUFS. I didn't downmix as an R128 scanner is supposed to have it's own formula for scanning multichannel files.

I'll make stereo versions of my test files shortly, compare the results, and report back sometime soon.

Re: ReplayGain: File volume instead of the quantity to be modified

Reply #10 –
The difference between R128Gain and fb2k is definitely due to the mono files.
I converted the test files to wave while adjusting them to -18 LUFS.
I then made stereo versions from the -18 LUFS mono files without adjusting their volumes.
Foobar2000 reports -18 LUFS for the whole lot.
R128Gain reports -21 LUFS for the mono files and -18 LUFS for the stereo files.

I'm not 100% sure it's fb2k that's wrong though, because I converted all the files to MP3 and scanned them with MP3Gain. It reported the same volume for both the mono and stereo versions. The results differed quite a bit from what fb2k reported though. They're all 89dB according to fb2k, in ReplayGain volume, but MP3Gain says 85.2dB for the tone, 84.9dB for the pink noise and 81.6dB for the white noise. I assume that's down to the different scanning methods.

Re: ReplayGain: File volume instead of the quantity to be modified

Reply #11 –
foobar2000 doubles mono to stereo because that is how majority of people who play such tracks will hear it. It used to give different results but it was fixed many years ago to give more sensible results.

Re: ReplayGain: File volume instead of the quantity to be modified

Reply #12 –
@Case
What does the EBU R128 spec say though? If the sample from the test files
"EBU-reference_listening_signal_pinknoise_500Hz_2kHz_R128.wav"
is supposed to be -23 LUFS, even though it's mono, then fb2k can't be obeying the spec as it reports -19.96 LUFS.

I understand the logic behind it, and it appears the old ReplayGain scanning method does the same, but I'm surprised fb2k doesn't follow the spec. It still uses 89dB to express the ReplayGain target volume, which seems silly to me, given the volume itself isn't saved to ReplayGain tags (just inferred from the track/album gain info), so if another part of the spec can be changed to something sensible, that'd get my vote. :)

By the way, there's a test file that fb2k appears to be decoding incorrectly.
"seq-3341-6-5channels-16bit.wav"
According to the text file it's supposed to be 5 channel - L, R, C, LS, RS
fb2k's output meter shows it being decoded as L, R, LFE, LS, RS
I opened it with MPC-HC and used ffdshow to process the audio so I could see the channel layout in it's Mixer filter. There was a centre channel rather than LFE.

Anyway, at least I understand what's happening now.
Cheers.

PS. Assuming all the test files are supposed to be -23 LUFS, and for the older ones fb2k reports something fairly close for the most part, any idea what the deal is with the newer test files? See the attached pic.
There's also another one that intrigues me.
"seq-3341-19-24bit.wav.wav"
I think it's the first time I've seen a volume reported as being louder than the peak.
Thanks.

Re: ReplayGain: File volume instead of the quantity to be modified

Reply #13 –
Quote from: yetanotherid on
What does the EBU R128 spec say though? If the sample from the test files
"EBU-reference_listening_signal_pinknoise_500Hz_2kHz_R128.wav"
is supposed to be -23 LUFS, even though it's mono, then fb2k can't be obeying the spec as it reports -19.96 LUFS.
foobar2000 isn't trying to obey EBU specs. It just uses their loudness estimation methods for ReplayGain purposes.

Quote from: yetanotherid on
I understand the logic behind it, and it appears the old ReplayGain scanning method does the same, but I'm surprised fb2k doesn't follow the spec. It still uses 89dB to express the ReplayGain target volume
That is the standard and spec foobar2000 does follow.

Quote from: yetanotherid on
By the way, there's a test file that fb2k appears to be decoding incorrectly.
"seq-3341-6-5channels-16bit.wav"
According to the text file it's supposed to be 5 channel - L, R, C, LS, RS
The readme is wrong. The file doesn't specify any channel map so the perfectly logical assumption is to map the channels 1:1 with Microsoft's channel order, as it's a Microsoft WAV format. If they wanted to specify a different channel order it should be stored in the file header.

Re: ReplayGain: File volume instead of the quantity to be modified

Reply #14 –
Quote from: Case on
Quote from: yetanotherid on
By the way, there's a test file that fb2k appears to be decoding incorrectly.
"seq-3341-6-5channels-16bit.wav"
According to the text file it's supposed to be 5 channel - L, R, C, LS, RS
The readme is wrong. The file doesn't specify any channel map so the perfectly logical assumption is to map the channels 1:1 with Microsoft's channel order, as it's a Microsoft WAV format. If they wanted to specify a different channel order it should be stored in the file header.

Except, however, but....

Isn't the Microsoft wave channel order FL, FR, C, LFE, BL, BR?
So a 1:1 channel map would drop the BR channel, whereas according to the output meter, fb2k has chosen to drop the centre channel and keep the rest. Is there such as thing as 4.1ch audio, assuming that's what you'd call it? The FLAC encoder (official version, not ffmpeg) rejects it without --channel-map=none in the command line to tell it any channel mapping is acceptable. Even QAAC doesn't want anything to do with it unless the LFE channel is remapped as centre first. Admittedly though, it's probably just an oddity that wouldn't be found in the wild too often.

By the way, is there a reason why fb2k's output meters refer to the back channels as RL and RR? I've always wondered why it doesn't use the official wave file labels for those.

Thanks.