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 DSP - Alternative ReplayGain implementation by Case (Read 3637 times) previous topic - next topic
0 Members and 2 Guests are viewing this topic.

ReplayGain DSP - Alternative ReplayGain implementation by Case

Since there seems to be no thread about this component yet, I am starting one. You can find it here.

@Case :
Great component, but I have one question or suggestion:
"Only prevent clipping" in the "processing mode" menu makes every track as loud as possible while preventing clipping. I just wonder why it seems to use the track true peak value instead of the album true peak value. I have honestly no idea how this option works in the replay gain options included in foobar2000. I just think it would make more sense to use the album true peak value instead in order to keep the relative loudness differences of an album. I hope it is clear what I mean.

Can this maybe be implemented as an alternative option?

Best regards!

Re: ReplayGain DSP - Alternative ReplayGain implementation by Case

Reply #1
That was an oversight, I didn't really think about just clip prevention use. New version released with album based clip-prevention-only mode added.

Re: ReplayGain DSP - Alternative ReplayGain implementation by Case

Reply #2
Thanks a lot for the quick implementation! Great!

Re: ReplayGain DSP - Alternative ReplayGain implementation by Case

Reply #3
May I ask for a feature request: for this great component to have an option to limit maximum positive gain to 0dB, or +3dB or +6dB.

I am worried if realtime RG scanning is going on ... this component might accidentally add on huge gain for super soft tracks.
Some classical tracks are super soft, some converted SACD tracks are very soft too.
Usually those "super soft" tracks are supposed to be listened that way without artificially high gain.

( Using the builtin foobar RG, I have manually over-ridden huge positive RG after the scan. )
( In my mind, any RG greater than +3dB is "huge". )

Re: ReplayGain DSP - Alternative ReplayGain implementation by Case

Reply #4
On a separate note, is it possible to view on the console what gain is being applied by this component?

Re: ReplayGain DSP - Alternative ReplayGain implementation by Case

Reply #5
I am worried if realtime RG scanning is going on ... this component might accidentally add on huge gain for super soft tracks.
Some classical tracks are super soft, some converted SACD tracks are very soft too.
Usually those "super soft" tracks are supposed to be listened that way without artificially high gain.
You should be using album RG for that kind of material, it preserves the relative dynamics between tracks.

And no, RG is not a real-time system.   It has to scan entire tracks (or entire albums).
It's your privilege to disagree, but that doesn't make you right and me wrong.

Re: ReplayGain DSP - Alternative ReplayGain implementation by Case

Reply #6
May I ask for a feature request: for this great component to have an option to limit maximum positive gain to 0dB, or +3dB or +6dB.
I can see some point in an option to prevent loudness increase entirely, especially for the realtime scan option. But I don't like the idea of adding configuration for the maximum boost amount. If it's ok to add an option to prevent positive gain entirely for tracks that weren't fully scanned or that miss peak info, I can add that. For tracks/albums that have peak info you can always prevent clipping with other means.

On a separate note, is it possible to view on the console what gain is being applied by this component?
It prints the gain information to console if it's not using tagged values. And it prints information if clip prevention required gain reduction. If it uses normal gain values from tags then it's quiet.

And no, RG is not a real-time system.   It has to scan entire tracks (or entire albums).
The DSP component can scan track based RG values on the fly before the playback starts if you use long enough output buffer or have fast enough computer and source medium. If entire track can't be scanned in time the partial results will be used as an estimate. Realtime may not be 100% accurate term but I don't have trouble calling it realtime scanning either.

Re: ReplayGain DSP - Alternative ReplayGain implementation by Case

Reply #7
I can see some point in an option to prevent loudness increase entirely, especially for the realtime scan option. But I don't like the idea of adding configuration for the maximum boost amount. If it's ok to add an option to prevent positive gain entirely for tracks that weren't fully scanned or that miss peak info, I can add that.

Having the above option would be great.

It prints the gain information to console if it's not using tagged values. And it prints information if clip prevention required gain reduction. If it uses normal gain values from tags then it's quiet.

Fantastic!


 

Re: ReplayGain DSP - Alternative ReplayGain implementation by Case

Reply #8
New version out with an option to prevent loudness increase for tracks with missing or guessed peak.

Re: ReplayGain DSP - Alternative ReplayGain implementation by Case

Reply #9
New version out with an option to prevent loudness increase for tracks with missing or guessed peak.

Thank you very very much !!

Re: ReplayGain DSP - Alternative ReplayGain implementation by Case

Reply #10
New version out with an option to prevent loudness increase for tracks with missing or guessed peak.
Thank you very much Case!
This version working much faster then previous verses and also attenuate tracks volume much more accurate and softer.

Re: ReplayGain DSP - Alternative ReplayGain implementation by Case

Reply #11
New version out with an option to prevent loudness increase for tracks with missing or guessed peak.
But do I understand correctly:

a) If it is set to "Rescan everything", it will be enforced to know gain/peak levels?
b) If set to "Prevent clipping only" the checkbox has no effect?
c) With positive gain you mean "volume increase", correct? Because first I read it like "Allow end result to be +0.5db"/i.e. "Allow clipping".

I may be confused about terminology.

Re: ReplayGain DSP - Alternative ReplayGain implementation by Case

Reply #12
a) If it is set to "Rescan everything", it will be enforced to know gain/peak levels?
In theory. It will try to scan the track gain and peak levels. But remember that the scanner will abort the job if it takes too long. The scanner will only be allowed to run while the output buffer still contains audio data so that playback remains gapless. If that time isn't enough to scan the entire track, then the new checkbox will essentially treat the track as if its RG gain value is 0.0 and peak info is missing, if the RG scanner returned above 0.0 gain.
Note that easy way to give more time for the scanner is to increase foobar2000 output buffer size.

b) If set to "Prevent clipping only" the checkbox has no effect?
That's correct.

c) With positive gain you mean "volume increase", correct? Because first I read it like "Allow end result to be +0.5db"/i.e. "Allow clipping".
Actually at the moment the new checkbox can still allow volume increase in certain situations. Namely if the target loudness is higher than the ReplayGain reference level and the gain value is zero or less negative than the volume boost. For example if estimated gain is -1.0 dB and you have selected Spotify playback level of -14 LUFS. That means the playback level is reduced by 1 dB but boosted by 4 dB, so +3 dB increase.
I will need to change that to prevent volume increase instead of just positive RG result. But that will have to wait until tomorrow, too many quick fixes already released today. Let's see if there are more things that need adjusting.

Re: ReplayGain DSP - Alternative ReplayGain implementation by Case

Reply #13
Quote
ReplayGain DSP: gain data is missing but the DSP managed to scan the track. Found gain +8.95 dB peak 0.346279
ReplayGain DSP: reducing gain by 0.74 dB to prevent clipping

Based on the above log entries, may I know what the log entries mean?
a. Gain of -0.74dB applied?
b. Gain of +8.21dB applied?  ( 8.95-0.74 )

Configuration settings:
  • Processing mode = Apply track gain
  • Target = -18 LUFS
  • Max peak = -1 dBFS
  • Estimation = Scan local files that are missing RG data
  • Allow positive gain = unchecked

( I was hoping when I unchecked the "Allow positive gain" setting, there would not be any positive gain, only negative gain allowed. )

Re: ReplayGain DSP - Alternative ReplayGain implementation by Case

Reply #14
The log entries tell that the DSP managed to fully scan the track you were about to play. The track seems to be very quiet and its playback level needs to be increased by 8.95 dB to get similar playback level as other tracks under ReplayGain specifications.
The peak 0.346279 means -9.21 dBFS, so even if playback level is increased by 8.95 dB it would not clip (there would be 0.26 dB headroom). But since you had requested the headroom to be 1 dB, the playback level needs to be slightly reduced. The loudness will be increased by 8.21 dB.

The new checkbox prevents positive gain when it's uncertain if the boost would clip or not. But when peak information is known, you can protect against clipping even without dynamics compression.

Re: ReplayGain DSP - Alternative ReplayGain implementation by Case

Reply #15
Thank you for explaining the meaning of the log entries.

I am still testing out various scenarios ... may need some protection for some scenarios as shown below...
( Yes, these are rare noise files that are not music content... the auto-applied gain is quite scary ... )

Quote
Opening track for playback: "F:\MUSIC\z_Subwoofer wakeup\Pink_PN_64k_50_10000_-48_dBFS_44.1k_PCM24_LR.flac"
ReplayGain DSP: gain data is missing but the DSP managed to scan the track. Found gain +29.09 dB
Opening track for playback: "F:\MUSIC\z_Subwoofer wakeup\Pink_PN_64k_30_6000_-60_dBFS_48.0k_PCM24_LR.flac"
ReplayGain DSP: gain data is missing but the DSP managed to scan the track. Found gain +41.83 dB

It'll be great to have some sort of maximum gain limit as a form of protection, be it 6dB or 12dB or ...

ps: As a workaround, I scan the files and override the track & album gain with pre-determined values, and this component will pick up the pre-determined value.

Re: ReplayGain DSP - Alternative ReplayGain implementation by Case

Reply #16
New version released where the "positive gain" term is changed to "volume increase" as the option now takes both the gain and the target playback level amplifications into account.

There is now also advanced config setting at 'Preferences' -> 'Advanced' -> 'Playback' -> 'ReplayGain DSP' to control maximum allowed gain value with the realtime scanner. It now defaults to +20 dB, range is 0 to 100 dB.

And the peak compress clip prevention method was adjusted, it can now be enabled even for tracks that have unknown peaks (like Opus files with just tags).

Re: ReplayGain DSP - Alternative ReplayGain implementation by Case

Reply #17
Thank you very much @Case  :)

Re: ReplayGain DSP - Alternative ReplayGain implementation by Case

Reply #18
Hello,

I may miss some context here, but has this DSP any advantage over native replaygain when it comes to basic usage like mine i.e. mainly random playback of my library ?

Re: ReplayGain DSP - Alternative ReplayGain implementation by Case

Reply #19
The native RG is a separate step to scan your library (or a selection of files), and then having scanned you are asked whether to write the data to the file tags.  This DSP version scans each track at the time you open it to play, so there is no separate scanning stage.

If you already have your library scanned and the tags set, there is no need to use the DSP version.  But if you acquire tracks randomly the DSP version saves remembering to scan them, or if they can't be scanned (eg streamed).
It's your privilege to disagree, but that doesn't make you right and me wrong.

Re: ReplayGain DSP - Alternative ReplayGain implementation by Case

Reply #20
thanks a lot for the detailed info.
Indeed, I do scan every new library entry separately with Case's true peak scanner so no special need for this DSP

Re: ReplayGain DSP - Alternative ReplayGain implementation by Case

Reply #21
Compared to native ReplayGain gain application this DSP's automatic mode can decide album based vs track based gain correction more smartly. It doesn't depend only on playback mode but also on playlist contents. For example in non-random playback mode a playlist of tracks from different albums will be played with track gain and consequential tracks from an album in album mode.

Another feature is that in track based mode gain change between tracks isn't instantly applied on track change but the gain difference is smoothly interpolated. That can prevent pop artifacts between tracks where sudden gain change would have caused a sudden discontinuity in the waveform.

Re: ReplayGain DSP - Alternative ReplayGain implementation by Case

Reply #22
thank you Case for these details. I'll keep that in mind

Re: ReplayGain DSP - Alternative ReplayGain implementation by Case

Reply #23
I don't understand why this is happening. Input is flac files which are replaygain scanned already. Output is AAC or MP3 for my target devices. The whole test album has peaks >1 all over the place.

My goal is to bring the max. album peak <1, i.e. volume down all tracks, just as much as necessary.

Source left, target right:



BTW the same values appear if max. peak is set to "unlimited".

The way I understand it, the plugin lowers the volume too much. My first thought would be there is a bug. But admittedly I lack understanding of peak vs. dB values so maybe I'm not seeing something.

TY!

Re: ReplayGain DSP - Alternative ReplayGain implementation by Case

Reply #24
Sorry about that. There was a bug in the "only prevent clipping" handling once again. When no gain rescanning was requested it applied previously used gain value.
All the logic and status printing in the component is based on ReplayGain, the clip-prevention-only mode is an afterthought and I always seem to manage to forget about its special needs.

Everything should be fixed now in the latest version I just uploaded.