smooth replay gain change is broken
Bug #1088230 reported by
Daniel Schürmann
This bug affects 1 person
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Mixxx |
Fix Released
|
Low
|
Daniel Schürmann | ||
Bug Description
I think it is broken since lp:mixxx/1.11 #3576
Note: the commends are misleading since the replay gain is not adopted after analysis if a track is already playing.
You can test it like that:
* Put default gain to maximum in the preferences
* Toggle enable replay gain checkbox.
-> the change is adopted without ramp
We may consider to remove this feature for saving CPU
Revision history for this message
| RJ Skerry-Ryan (rryan) wrote | #1 |
| Changed in mixxx: | |
| milestone: | none → 1.11.0 |
| Changed in mixxx: | |
| milestone: | 1.11.0 → 1.11.1 |
| Changed in mixxx: | |
| importance: | Undecided → Low |
| status: | New → Confirmed |
| Changed in mixxx: | |
| status: | Confirmed → Fix Committed |
| assignee: | nobody → Daniel Schürmann (daschuer) |
| milestone: | 1.11.1 → 1.12.0 |
| Changed in mixxx: | |
| status: | Fix Committed → Fix Released |
Revision history for this message
| Swiftb0y (swiftb0y) wrote | #2 |
| lock status: | Metadata changes locked and limited to project staff |
To post a comment you must log in.
Hm, could be wrong but I thought I only changed the timing code to use PerformanceTimer.
There was also a hole in the logic that set the replaygain to 1 right when the smoothfade completed because the gain was not being set in the smoothfade=false branch of the logic. This was what caused a glitch in the waveform as it was growing/shrinking (and technically dropped the replaygain for one process() call in the engine though I could never hear it).
I'm pretty sure that checking/unchecking the replaygain enabled checkbox always had the immediate-change behavior.