Bugzilla – Bug 843
Incorrect preview in Noise Reduction, Compressor and Leveler when Pan or Gain are not defaults
Last modified: 2018-08-20 11:45:56 UTC
Probably borderline P3, but we've been living with this forever with very few complaints, so set at P4. Essentially the problem is that processing tracks when applying an effect is handled differently from when previewing an effect. Additional detail below in case this needs to be release noted: Audacity is able to apply an effect to multiple selected tracks. It does so by selecting each track in turn, and applying the effect to the audio data in that track, then moves onto the next track. The way that preview works is that a few seconds of audio are taken from the start of each selected track, mixed to a single temporary track, and then the effect is applied to that temporary track, and the result played. The track Pan and Gain controls are taken into account when mixing the temporary track. So when applying an effect and then playing, Gain and Pan are applied post-processing whereas when previewing, Track Gain and Pan are applied pre-processing. The workaround is to set Pan and Gain to centre position (default) before previewing the effect.
Similar problem in Compressor and Leveler effects. Bug title updated.
So, this is not a defect in the code for the several effects named. It is a defect in the general Effect::Preview() function. As you said, Preview mixes down first and then computes the effect only once (or twice, once per channel) whereas applying the effect computes separately for each selected track. Results are equivalent if an effect depends linearly on the waveform, such as highpass, change speed, reverse, etc. etc. etc, and this saves some computation in the preview. Results are not equivalent for nonlinear effects, which include those named, but probably many others too, like truncate silence, Normalization, etc. -- any effects with threshold controls. I think the solution is that each subclass of Effect needs to override a protected virtual IsLinear() method appropriately, so Effect::Preview() can still save computation when it can, but otherwise do the more correct, general thing. EffectNyquist would need the pessimistic assumption that effects are not linear, so we would lose the efficiently for some like highpass.
Generalizes bug 775 ?
(In reply to comment #3) Yes I think so.
This bug appears to be fixed.
Tests ok on W10 audacity-win-4a0fbf8-2.2.0-beta-26Sep17
And tests ok on macOS Sierra 10.12.6 27SEp17 nightly build
