Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

remember gain adjustments values #8268

Closed
mixxxbot opened this issue Aug 22, 2022 · 31 comments
Closed

remember gain adjustments values #8268

mixxxbot opened this issue Aug 22, 2022 · 31 comments
Labels
Milestone

Comments

@mixxxbot
Copy link
Collaborator

Reported by: Be-ing
Date: 2015-10-23T22:14:33Z
Status: In Progress
Importance: Wishlist
Launchpad Issue: lp1509557


ReplayGain works most of the time, but not always. Manual gain adjustments are still needed. It would be convenient if Mixxx adjusted its stored ReplayGain value of a track by the amount the channel gain was adjusted when the track is ejected from a deck. When the track is loaded again with ReplayGain turned on and the channel gain control is at unity, the track would be at the same level it was at when it was ejected before.

@mixxxbot
Copy link
Collaborator Author

Commented by: daschuer
Date: 2015-10-24T05:22:12Z


What are the reasons that require manual adjusting?
Is it the detection quality of replaygain?
I have prepared a brach that switches to EBU R 128, pull request #⁠520. It should provide a better overall loudness.

The proposed implicit gain storing, may confuse users and may not work reliable in all cases. We may think of an additional gain value for each track that can be adjusted by the the gain knobs in a visible way. Instead of the feature of resetting the gain knobs on track load, the gain knobs cam move to this stored value. (Reset to previous track gain)

@mixxxbot
Copy link
Collaborator Author

Commented by: Be-ing
Date: 2015-10-24T05:39:28Z


The current ReplayGain implementation does not even out the levels of some tracks well.

"Instead of the feature of resetting the gain knobs on track load, the gain knobs cam move to this stored value. (Reset to previous track gain)"

That seems like a better idea.

@mixxxbot
Copy link
Collaborator Author

Commented by: uklotzde
Date: 2015-10-24T12:32:31Z


I like the idea of mapping the replay gain value directly to the gain knobs to have a single parameter for controlling the level of each track! Next time I load a track the gain will already be in place and no adjustments are necessary, very convenient. I'm missing this feature in Mixxx, because the calculated replay gain is not always accurate.

As a drawback the controls on your controller will not follow when you load a new track. But with soft-takeover for the gain controls this issue can easily be solved.

By re-analyzing tracks users will be able to restore the analyzed values for both replay gain and bpm. I don't see any need for introducing additional (hidden) values or flags to distinguish between analyzed and custom values. This would confuse users, including myself ;)

@mixxxbot
Copy link
Collaborator Author

Commented by: Be-ing
Date: 2015-10-24T15:53:08Z


"As a drawback the controls on your controller will not follow when you load a new track. But with soft-takeover for the gain controls this issue can easily be solved."

Yes, this would be an issue for most controllers, although some controllers use encoders to control gain so it wouldn't be an issue.

@mixxxbot
Copy link
Collaborator Author

Commented by: daschuer
Date: 2015-10-24T20:35:44Z


IMHO we cannot reuse the replay gain field from the track meta data.
The replaygain field is somehow tight connected with the a standard algorithm that is uses by the detector, in a way that the player software can rely on a specific target loudness (-18 LUFS reference)
See: http://wiki.hydrogenaud.io/index.php?title=ReplayGain_2.0_specification

If a user likes a specific track to played on a different loudness for some reasons, this should be not effect the gain value for -18 LUFS.

If the track is not played at -18 LUFS if the replay gain is applied, the detection algorithm may have failed. In this case we may manually adjust the replay gain. But this should happen cautious during preparing a set an not implicit during a set.

Did you checkout #520 ?

The new EBU R 128 algorithm may fix your pending issues.

A remaining issue could be that you like to play silent part of a high dynamic track, which is to silent compared to the other tracks.
If we adjust the replay gain for such a track, it is getting worse for the loud part.

What are your issues. An example would be nice.

@mixxxbot
Copy link
Collaborator Author

Commented by: uklotzde
Date: 2015-11-07T19:49:55Z


The following PR implements safe writing of tags into files including replay gain:
#728

@mixxxbot
Copy link
Collaborator Author

Commented by: Be-ing
Date: 2015-11-17T06:20:23Z


The biggest issue I am having with Mixxx's ReplayGain is that sometimes tracks clip when the deck gain is at unity. Here are some tracks I have had this issue with:

https://auditiveescape.bandcamp.com/track/beats-per-feeling (can be downloaded for free if you download the whole album at https://auditiveescape.bandcamp.com/album/sense-intra )
http://music.gravitasrecordings.com/track/sankars-lake

@mixxxbot
Copy link
Collaborator Author

Commented by: Pegasus-RPG
Date: 2015-11-17T06:58:56Z


Be: you likely need to reduce the "initial boost" setting on the Normalization prefs pane.

@mixxxbot
Copy link
Collaborator Author

mixxxbot commented Aug 22, 2022

Commented by: Be-ing
Date: 2015-11-17T14:14:22Z


That's not really a solution, because then I'd have the opposite problem; some tracks would be too quiet with the deck gain at unity.

@mixxxbot
Copy link
Collaborator Author

Commented by: daschuer
Date: 2015-11-17T15:04:48Z


What is your target Loudness?

I have just tested the track as mp3 and I cannot reproduce the clipping with the recommended default loudness of -16 LUFS and replay gain applied. The track plays also in almost the same loudness then my other tracks.

But I have noticed that the original track is already clipping without applying any gain.

This is possible due to the lossy nature of mp3. If you level a track to digital full scale and pass it to a lossy codec, the
output samples can reach values on top of the digital full scale.
This happens, because of two reasons.
1: the codec adds a amount of "noise" the track original sample at 1 + noise = clipping.
2: a track leveled at digital full scale can be considered as already clipping, since a digital track is already a "compressed" appearance of the original analog sound. The DAC circuit in you soundcard reintroduces the voltage level between the samples, and can reach likely values above full scale in between two samples at full scale.
Something similar happens inside the mp3 codec when transforming to the frequency domain.

Conclusion: Tracks leveled at digital full scale are broken (of bad quality)

However the MAD codec used in Mixxx is able to output fixed point samples above digital full scale.
Unfortunately they are clamped by the following code in Mixxx 1.12. This means you will experience an undesired distorsion / noise when playing such an effected track. This is independent from the following gain settings.

Mixxx "master" has a full floating point engine, which does not clamp such a track anymore.
Here you can reduce the gain of the track, in a way that all track samples are below the clipping threshold.
Of cause this reduces the loudness of Mixxx (but you can increase it at the amp :-P )

@mixxxbot
Copy link
Collaborator Author

Commented by: daschuer
Date: 2015-11-17T15:05:18Z


Maybe we should add that info to the manual.

@mixxxbot
Copy link
Collaborator Author

Commented by: Be-ing
Date: 2015-11-17T15:43:46Z


I only play FLACs.

@mixxxbot
Copy link
Collaborator Author

Commented by: Be-ing
Date: 2015-11-17T15:52:45Z


On further testing, I think the issue is actually that those loud tracks make the master output clip when mixed with other tracks rather than the deck clipping.

@mixxxbot
Copy link
Collaborator Author

Commented by: Pegasus-RPG
Date: 2015-11-17T17:20:15Z


Well then that's expected. Getting back to the reason for the bug: my vote is to save the position of the gain knob in the library DB on track eject. (Don't change the RG value in the track metadata.)

@mixxxbot
Copy link
Collaborator Author

Commented by: ronso0
Date: 2016-12-08T14:53:05Z


I wanted to add this to the wishlist. I don't know how your progress is right now, but I'd like to give you my opinion on this. When writing this I have a track in mind that starts with a quiet poem and finishes with a set of explosions.

"A remaining issue could be that you like to play silent part of a high
dynamic track, which is to silent compared to the other tracks.
If we adjust the replay gain for such a track, it is getting worse for the
loud part."
When using that poem track in a set I only play that poem part. I'm aware that the explosions will likely clip (or, the other way around, the poem would be too quiet). DJs know their tracks and the overview waveform clearly shows those different levels to be careful with.

"In this case we may manually adjust the replay gain. But this should
happen cautious during preparing a set an not implicit during a set."
Yes! As a 2-deck-controller user soft-takeover is already stressing when using 4 decks since I have to switch focus back & forth between controller and screen. Please don't implement this in a "set gain knob on track load" way, this would be irritating.

How I'd love this to work:

  • load a track, let analysis finish
  • adjust gain with gain knob
  • press "adapt replayGain"

detected replayGain is multiplied by current gain factor
track is louder/more quiet immidiately

  • center gain knob
    = desired gain, now and on any future track load

If -some time- I like to play the explosion part, clipping can be avoided by adjusting normal gain, right?

@mixxxbot
Copy link
Collaborator Author

Commented by: daschuer
Date: 2016-12-08T15:23:27Z


We have made no progress in the original issue. But we have improved the Replay-Gain behaviour, by introducing the EBU R 128 (Replaygain 2) analysis.

This may work except that we should store the additional offset in an extra field, and not touch the RG value form the analysis.

The sudden gain change when storing the offset might be surprising for some users....

@mixxxbot
Copy link
Collaborator Author

Commented by: Be-ing
Date: 2016-12-08T16:00:38Z


If the user adjusts the gain on first track load without ReplayGain applied, Mixxx should figure out the difference between the user set gain and the ReplayGain and store that in the database so the next time it is loaded, the effective gain is the same.

@mixxxbot
Copy link
Collaborator Author

Commented by: ronso0
Date: 2016-12-09T13:47:45Z


@Daniel  Yeah, I noticed that gain analysis is mostly right recently. But I'm literaly talking about that 'poem track' where it is right...but wrong depending on my intentions with that very track ;)

"The sudden gain change when storing the offset might be surprising for
some users...."
Indeed, didn't imagine to have that track playing when re-adjustment is done.
But the learning curve would be steep...
If it is applied on next track load it would be clearer, right?

@be In that case it had to be clear to the user he has the chance to change replayGain on 1st track load. For my 'poem track' I decided to do so long after 1st load.

Not a poem but an example: Einstürzende Neubauten - Silence is sexy

@mixxxbot
Copy link
Collaborator Author

Commented by: Be-ing
Date: 2017-12-28T04:56:40Z


I think I have taken up enough for myself for the 2.2 release with the effects system improvements. Does anyone else want to volunteer for this? Uwe? If not, let's remove it from the 2.2 milestone.

@mixxxbot
Copy link
Collaborator Author

Commented by: daschuer
Date: 2018-07-02T21:15:00Z


I think what we really need is to support the album gain. Thid can be considered as the real value, because only this sets the track in relation to other tracks and will finally play "silence is sexy" with the right gain value.

Since It is hard for Mixxx to calculate the album gain, we can use this as a value for manual adjusting until we have a album gain analysis.

@mixxxbot
Copy link
Collaborator Author

Commented by: daschuer
Date: 2018-07-02T21:16:41Z


This is the album gain bug https://bugs.launchpad.net/mixxx/+bug/1752654

@mixxxbot
Copy link
Collaborator Author

Commented by: Be-ing
Date: 2018-07-02T21:40:12Z


Yes, we should support album gain, but I don't understand what that has to do with this feature.

@mixxxbot
Copy link
Collaborator Author

Commented by: daschuer
Date: 2018-07-02T22:10:56Z


This bugs complains about the Track Replaygain not working. Everything we have discussed so far will be fixed by a correct detected album gain.

Mixxx cannot calculate the album gain yet, but we can allow to edit the album Gain in Mixxx to the correct value.

This way both bugs are fixed. Or do I miss something?

@mixxxbot
Copy link
Collaborator Author

Commented by: Be-ing
Date: 2018-07-02T22:44:24Z


This has nothing to do with album gain. This bug is for making manual, permanent adjustments to the analyzed track gain.

@mixxxbot
Copy link
Collaborator Author

Commented by: daschuer
Date: 2018-07-02T23:11:47Z


The question here is: What is your use csse?

@mixxxbot
Copy link
Collaborator Author

Commented by: macrophone
Date: 2019-09-24T13:27:36Z


Hi. I would like also to have a manual gain adjustment for some tracks.

My use case :

I use in my mixes some nature field recordings, like this rain track :
https://cloud.macrophone.fr/owncloud/index.php/s/YA3MMMT63tYXRfX

This track got's a lots of dynamic and contains some very quick transients peaks (aka rain drops).

In my Mixxx, the loudness setting is at -18 LUFS witch is correct for most of my tracks.
With this setting there a lot of cliped peaks and globally the loudness level is very high.

If I want to make the clipping disapear I have to set the loudness level to -27 LUFS, witch is very low.

For me it would be great to be able to set an "offset gain" value of -9db that I can store in the track properties of this one in order to don't think of the gain of this one anymore.

@mixxxbot
Copy link
Collaborator Author

Commented by: macrophone
Date: 2019-09-26T12:12:00Z


Another track with a lot of dynamics witch clips at -18db LUFS :
https://cloud.macrophone.fr/owncloud/index.php/s/tTxHoZDNHbtR3jN

@mixxxbot
Copy link
Collaborator Author

Commented by: daschuer
Date: 2021-06-13T22:17:03Z


#3990

@mixxxbot
Copy link
Collaborator Author

Commented by: ywwg
Date: 2021-06-13T22:52:17Z


For this first implementation I'm not going to address the questions of combining the replaygain and track gain UI elements. I think that could get confusing very quickly. So to start, I think it's sufficient to just support the direct editing of the saved ReplayGain value. I don't think it's realistic to "solve this bug" by somehow fixing replaygain so it's never ever wrong :). Mixxx has always been a combination of auto-detection and user tweaks. We should allow the greatest flexibility for users, and sometimes that means tweaking a value manually.

@mixxxbot mixxxbot transferred this issue from another repository Aug 24, 2022
@ronso0
Copy link
Member

ronso0 commented Mar 22, 2023

#4031 Adjust ReplayGain: Allow user to update the replaygain value based on a deck pregain value

@daschuer daschuer added this to the 2.4.0 milestone Mar 23, 2023
@daschuer
Copy link
Member

I think we can close this, since the underlying use-case is covered by #4031

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants