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 10762 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: ReplayGain DSP - Alternative ReplayGain implementation by Case

Reply #25 –
That's great, it works. One thing I noticed. In an "only prevent clipping" setting with the peak set to 0dbfs, the result peak still exceeds 1 (e.g. I saw one goilg up from 1.10 to 1.17). I was thinking intersample peaks related...? What can be said is that my RG (for the source files) does TruePeak scanning.

BTW. Should the gain correction be made before or after sample rate processing? I use this plugin also in a pure downsampling scenario.

Re: ReplayGain DSP - Alternative ReplayGain implementation by Case

Reply #26 –
All processing has potential to change the peaks. Both sample rate conversion and lossy encoding will definitely alter the peaks, unless the track consists only of some super simple tone with samples on a clear sine-shaped path. As ReplayGain based clip prevention depends purely on the peaks of a track the order of other DSP processing doesn't matter. It will be wrong if the data has any extra processing going on.

If you for some reason need or want to prevent lossy files from clipping on decode, just encode them without any tricks and use the foobar2000's 'Apply gain to file content' feature to bring the volume down enough to prevent clipping.

Re: ReplayGain DSP - Alternative ReplayGain implementation by Case

Reply #27 –
Thanks Case, that's right. One question still: For album gain, does it use the %album% tag or the album grouping string in the ReplayGain options? (I hope the latter).
Maybe, just maybe you could allow for an individual string per plugin instance. Why? Some of my converter chains keep directories/albums together, but some others split by (classical) works. Default should be to inherit the string from the global RG settings.

Re: ReplayGain DSP - Alternative ReplayGain implementation by Case

Reply #28 –
Only way the DSP can use album related ReplayGain data is if the file has the information already in the tags. If it does a peak/gain estimate on the fly, it is done purely for a single track.

Re: ReplayGain DSP - Alternative ReplayGain implementation by Case

Reply #29 –
Quote from: Case on
Only way the DSP can use album related ReplayGain data is if the file has the information already in the tags. If it does a peak/gain estimate on the fly, it is done purely for a single track.
Ah sure, its scope is the currently converted track... my logic module was broken for a moment.

Re: ReplayGain DSP - Alternative ReplayGain implementation by Case

Reply #30 –
Is there a foobar title-formatting variable that this component stores it's currently applied gain value?
I was hoping to display it on my "technical" panel.

Re: ReplayGain DSP - Alternative ReplayGain implementation by Case

Reply #31 –
There isn't, but foo_outinfo reports ReplayGain information and my plan is to make it able to report RG info from the ReplayGain DSP too later.

Re: ReplayGain DSP - Alternative ReplayGain implementation by Case

Reply #32 –
Im not sure why because i have never had problems before. But lately ReplayGain DSP will work for the most part but every now and then a song will play louder than the rest as if no settings are applied to the currant playing song. When i fiddle with its settings it starts to work again untill the next time. Im at a loss here as to whats going on. I have recently reinstalled everything before i started noticing this strange behaviour.

Re: ReplayGain DSP - Alternative ReplayGain implementation by Case

Reply #33 –
I'd be curious to hear more details about the circumstances and the DSP settings when this happens.
I'm assuming you use the "Apply most suitable gain" option and a non-random playback order - please correct me if assumptions are wrong.

The foobar2000 console will report which ReplayGain mode is in use, for example for album mode you'll see a line like "ReplayGain DSP in album mode".
If the effective mode is determined incorrectly and it uses wrong gain source, it could very well cause wrong loudness. If that's the case I'd like to see the tags of the problem track, the previous track in playlist, and the next track in playlist.

Or possibly if gain values are missing and you rely on the automatic scanning, it may not be able to do a good job if it runs out of time due to performance reasons. Details about the automatic scanning will be reported on the console too.
 

Re: ReplayGain DSP - Alternative ReplayGain implementation by Case

Reply #34 –
Dps manager i run skip silence, ReplayGain (alternative), Advanced Limiter in that order. ReplayGain source mode and processing is set to none. I use the apply track gain option, -14 LUFS (Spotify), 0 dBFS (reduce gain), Never scan, use previous gain and unchecked Allow volume increase even if peak is uncertain.

I play songs in shuffle mode. All my songs have replaygain info, i use truepeak scanner.

Re: ReplayGain DSP - Alternative ReplayGain implementation by Case

Reply #35 –
I use the playlist tabs and drag my music to them, they can be a mixture of old and new tunes. I use replaygain to get a general loudness level.
 
I use the DSP drop-down list to change profiles.

Looking at the console im not seeing replaygain mentioned all that often.

I have noticed one instance when playing a song from another tab/playlist that replaygain seems to ignore the song and it plays louder than it should?

Re: ReplayGain DSP - Alternative ReplayGain implementation by Case

Reply #36 –
The component only prints information to the console when something unexpected happens. Your log shows that only abnormality was that '30. Café Del Mar - Firewere.flac' required gain reduction to prevent clipping.
Since the gain reduction message did not appear immediately after track change it looks like you adjusted some gain-related setting in the DSP during playback.

I uploaded a special version of the DSP that reports all the gain information to the console. Please download: https://foobar.hyv.fi/foo_dsp_replaygain-log+.fb2k-component.

Re: ReplayGain DSP - Alternative ReplayGain implementation by Case

Reply #37 –
When i find its not behaving as expected, i used the drop-down dsp list to deactivate replaygain and re-enable it or sometimes i will change a setting and back again to get it to work again. It happened a few times in my My Old SkooL playlist in the console log.

Im using the download above.

Re: ReplayGain DSP - Alternative ReplayGain implementation by Case

Reply #38 –
Your log shows the DSP working as it should for at maximum 8 tracks. And out of those 8, four (4) showed several hundred millisecond delay after the track was opened and DSP reported information. That doesn't seem normal. For me the information is reported on the same millisecond. or with a one ms delay.

For 11 tracks the DSP did nothing.

And for 5 tracks you definitely manually enabled it several seconds after the track had started.

Even when the DSP did nothing I see that it was still loaded since the gain change interpolation got triggered when it did do its work.

Only explanation I have is that for the most part the DSP chain that was in use used a preset where the processing mode is simply set to 'off'. Regretfully I did not log that case to console with the previous loggin version, here's an update: https://foobar.hyv.fi/foo_dsp_replaygain-log+2.fb2k-component.

Are you certain you don't use Dynamic DSP, Flex DSP or Playlist Attributes to mess with your DSP settings?

Re: ReplayGain DSP - Alternative ReplayGain implementation by Case

Reply #39 –
I typically scan everything with TPS and have RG set to Track/Album by PlaybackOrder with (gain and clip prevention).

When I disable enable Replaygain and enable Replaygain DSP it uses these scanned values (as far as I can see). With the benefit that tracks that are not scanned yet and have no Replaygain values are scanned by Replaygain DSP on the fly.

The moment I switch to a stream however Replaygain DSP cannot scan the file obviously and uses the last settings used. Which is far too loud. Also between streams the loudness varies a lot.

Is there a way (plugin/dsp or else) to apply a decent Replaygain value when using streams?

Re: ReplayGain DSP - Alternative ReplayGain implementation by Case

Reply #40 –
I think i may have found the problem. In advanced settings, Fast DSP reset when cycling tracks manually was checked. When changing songs now, every song has a ReplayGain DSP entry in the console and seems to be working correctly. I apologise for not being more thorough before reporting an issue.

I do still experiance several hundred milliseconds delay before each track is played. Im wondering if this could be due to Minibar scanning the waveform beforehand?

Re: ReplayGain DSP - Alternative ReplayGain implementation by Case

Reply #42 –
Quote from: Defender on
Is there a way (plugin/dsp or else) to apply a decent Replaygain value when using streams?
If a stream uses a constant loudness level you should be able to manually configure appropriate ReplayGain values to it with foo_external_tags and possibly with the M-Tags component.
Otherwise only option is to use dynamic loudness normalizer, but that is a dynamics compressor and quite different than what ReplayGain does.

Re: ReplayGain DSP - Alternative ReplayGain implementation by Case

Reply #43 –
Quote from: Mekoz on
I think i may have found the problem. In advanced settings, Fast DSP reset when cycling tracks manually was checked. When changing songs now, every song has a ReplayGain DSP entry in the console and seems to be working correctly. I apologise for not being more thorough before reporting an issue.
That is a good find and I apologise for not knowing it to cause this kind of behavior. I vaguely remember Peter explaining how the feature worked but it had slipped my mind.

When that option is enabled manual track change looks just like normal seek so ReplayGain DSP has no idea that new gain values need to be read. I will add a workaround for the ReplayGain DSP. It's a bit against the idea of this speed option, moving a slow one-time operation to instead be performed possibly hundreds of time - every time user seeks - but that is the only choice for things to work with that setting enabled.

Quote from: Mekoz on
I do still experiance several hundred milliseconds delay before each track is played. Im wondering if this could be due to Minibar scanning the waveform beforehand?
Minibar scanning is performed in another thread so it doesn't delay the DSP processing. But over here Minibar scanning seems to introduce 1-6 millisecond delay for the DSP notification message based on quick tests. You have also lyrics stuff going on during track change, perhaps that causes a longer delay. If it works in main thread it probably causes a delay for the console message arrival, but again, it won't delay the DSP processing itself.

Re: ReplayGain DSP - Alternative ReplayGain implementation by Case

Reply #44 –
New version released with the promised change. Fast DSP reset will no longer be a problem.

Re: ReplayGain DSP - Alternative ReplayGain implementation by Case

Reply #45 –
Quote from: Case on
New version released with the promised change. Fast DSP reset will no longer be a problem.
Brilliant news and a quick turn around, thanks for your continued support.

I just want to mention the reason why i was using Fast DSP reset. My headphone dsp chain introduced some lag/latency which made skipping tracks a pain due to it taking longer than normal to switch.

Re: ReplayGain DSP - Alternative ReplayGain implementation by Case

Reply #46 –
Good to hear everything works now. And yeah, makes perfect sense to use the fast DSP option if you have DSPs that are so demanding to initialize.

@Defender : I just uploaded a new version of ReplayGain DSP component. This component was always supposed to use previous gain value exactly to help against for example radio stations suddenly blasting your ears off. But at some point with new features getting added the previous gain applying didn't work when any auto-RG scanning option was in use. I think this option alone is quite useful: you play for example a metal track with -14 dB gain, switch to a metal radio, your playback continues with -14 dB gain.

And I made another improvement. The pre-track quick RG scan will now start its timing after opening the source track so the process won't be canceled while waiting for the connection to be established. And it will automatically allow extra two seconds for radio streams to get a loudness estimate.

Perhaps these changes help you get more comfortable radio loudness levels.

Re: ReplayGain DSP - Alternative ReplayGain implementation by Case

Reply #47 –
Quote from: Case on
@Defender : Perhaps these changes help you get more comfortable radio loudness levels.
Yes it does, thank you.

One thing I noticed that it works rather well when switching between MP3 streams. When I switch to an AAC stream this is played a lot louder again. For instance: http://79.111.119.111:8000/melodicpower

I also tested RG DSP on a normal flac item.
When playing with RG PBO enabled and RG DSP disabled, that sounds the same as RG PBO disabled and RG DSP enabled.
When you however have RG PBO enabled and then also enable RG DSP soundlevels go down quite a bit.
Is this as intended?

NB. I'm only testing RG DSP, I prefer to use regular RG after scanning tracks with TPS and now you have added stream support to TPS in combination with external tags that will be my preferred way of using RG in general.

Re: ReplayGain DSP - Alternative ReplayGain implementation by Case

Reply #48 –
Audio format isn't a factor, loudness depends only on station settings. Last night I saw the DSP get about -5 dB RG value for the station but this morning it consistently fails and reverts to using previous gain, which of course depends on what I was playing earlier.

Having both core ReplayGain and the DSP enabled will cause gain values to be applied twice, so the levels will be quite wrong. It's expected but definitely not the intented way to use ReplayGain. I could force core settings off, or prevent the DSP from working when core settings are not the way they should be. But so far there hasn't been the need.

Re: ReplayGain DSP - Alternative ReplayGain implementation by Case

Reply #49 –
Hello @Case

When using the component, a brief pause or gap occurs between loud tracks that are intended to have a seamless transition.

Component settings:
X