Sorry this is so long, compared to input. I wanted to leave the
On 08/04/2013 17:29, Steve the Fiddle wrote:
> On 8 April 2013 00:50, Martyn Shaw <martynshaw99@...> wrote:
>> Hi Steve
>> I see that James has now committed this, but there are still
>> outstanding issues...
>>>> Are BASS_MIN, BASS_MAX etc actually being adhered to? If not, what
>>>> are they for? I can type -1555 into the 'Bass (dB)' box and get a
>>>> flat-line out.
>>> BASS_MIN and BASS_MAX set the slider ranges.
>> OK, but there is a factor of 10 there not noted. Magic numbers in
>> use. Typical of these controls, perhaps.
> Because wxSlider has integer divisions the slider range needs to be at
> least x10 of the desired range so that we can get one decimal place.
> Looking at other effects I don't think I'm doing anything unusual
No you are not, and sorry I was being over picky. That looks right.
> The "->SetPageSize(30);" is not actually necessary in this case as the
> slider will default to "Page Size" of 30, (at least, that is the case
> on Linux) but it does no harm. If we wanted more or less slider
> movement on Page Up/Down then "->SetPageSize()" would be required. I
> think +/- 3 dB steps are about right for the Page Up/Down buttons, but
> if, for example +/- 1 dB steps were preferred then it just requires
>>> I'm not 100% convinced that it is a good idea to allow text input to
>>> override these settings, but I agree with Gale's arguments that (a)
>>> some users may find it useful/convenient to be able to enter values
>>> outside of the slider range, and (b) several other built in effects
>>> allow this.
>>> The problem is, if we do allow text entry beyond the slider range,
>>> then to apply any limit that defines a "valid" range is purely
>>> arbitrary. +/- 48 dB might seem like a generous limit for text entry,
>>> but why not allow -50 dB? Why not -51 dB?
>> So what are BassTrebleDialog::OnBassText/OnTrebleText doing?
>> Restricting the range of mBassS/mTrebleS but are they actually used?
>> I didn't probe further.
OK, I see now. The sliders (mBassS) are, effectively, the 'slaves'
here and the value in the text box (mBassT) is what is actually used
for filtering, saving etc..
>>> Generally I think that we all like to see consistency in Audacity, so
>>> if we say that text input values need to be restricted to the same as
>>> the slider range, then we should really apply that to other built in
>>> effects that have text input and sliders.
>> Such as?
> Such as:
> Change Pitch
> Change Speed
> Change Tempo
Those do disallow/grey out the 'ok' button if the text box is outside
the slider range though.
> Noise Removal
That appears to allow any numbers in the text boxes, and now I'm
waiting for it to complete as a result of my experiment! I cancelled
it in the end.
I think that we can take these on a case-by-case basis, and that may
be more important than consistency between them.
> Sliding Time Scale / Pitch Shift
> Of the effects that have sliders and text input for the same control,
> the ones that do not allow text input beyond the slider range are:
> Click Removal
>>>> I think that
>>>> is slightly flawed, and uses 'magic numbers' (1.4) that aren't explained.
>>> I provided a (brief) comment about that:
>>> // Allow headroom for integer format samples
>>> The issue is that for TwoPassSimpleMono effects, if the track is
>>> integer format, the waveform can clip on the first pass (now logged as
>>> bug 619).
>> OK, that is a problem that we shouldn't have.
>>> In order to avoid this clipping, it is necessary (for integer format
>>> tracks) to amplify the waveform low enough to ensure that clipping
>>> does not occur, and then the waveform can be amplified back up on the
>>> second pass. However, we don't want to amplify the track down more
>>> than necessary as this will adversely affect the sound quality, which
>>> is especially noticeable as by default Audacity adds dither noise
>>> which will then be amplified on the second pass.
and see below
>>> The amount of (negative) amplification that is applied on the first
>>> pass and then reversed in the second pass is the "mPreGain" factor.
>>> The amount of PreGain headroom required to prevent clipping is
>>> proportional to the amount of gain being applied - that is, the more
>>> the filter gain, the more headroom is required to avoid clipping.
>> OK, when gain is being applied.
>>> Negative filter gain can also create clipping (try applying a 250 Hz
>>> high pass filter to a 1 kHz square wave), though the amount of
>>> clipping is less than for positive filter gain.
>> (I'm sure you meant 2.5kHz there for the HPF.)
> No, I meant a 250 Hz high pass filter.
> A 6 dB/Octave IIR high pass filter at 250Hz applied to a 1 kHz square
> wave results in +5 dB amplitude gain.
My mistake, sorry! Yes I can get some amplitude gain doing that, I
was thinking in the frequency domain where the amplitudes clearly
don't change much, and using the FIR Equalization effect for testing,
but this is about phase not amplitude.
>> Very true, but what is the worst-case here, for negative gain? Let's
>> not go working that out, as I'm sure somebody has done so before, and
>> I'm sure it isn't 10s of dBs. It is 'a bit' but it isn't 'a great deal'.
> My guess would be +6 dB as a worst case figure (anyone know better?)
If I had the time I might like to cover all the cases and work this
out, but let's go with the 6dB, unless somebody comes up with a better
>>> I'm not sure of the exact amount of headroom that is required to avoid
>>> clipping, but for positive filter gain it is more than the filter
>>> gain. A factor of (filter gain x 1.4) avoided clipping (with a little
>>> extra headroom) in all my (and Gale's) test cases.
>> OK, I can live with that.
>> A factor equal to
>>> the absolute filter gain worked for all negative filter gain settings.
>> It would, I think, but it's far too much for many values of
>> 'negative', like -50 or -90dB. And then we get the dither problem.
>> Like I said above. Maybe a fixed factor here of, say, 6dB?
> I suspect 6 dB is the maximum required, though for small amounts of
> negative gain that is more than enough.
6dB isn't going to be harmful.
> I don't think that treble cut ever causes an increase in amplitude
> (anyone know different?)
In my FIR world, cutting all the harmonics over the fundamental of a
square wave does. lowpass.ny does on a 1kHz square with 48dB/octave
and a 2kHz cutoff, by about 2dB. 6dB is probably safe/reasonable here
as well, I guess.
> I'll run some tests - I'm sure you're right that this part can be improved.
>>> Ideally the first pass should remain in 32 bit float format, then this
>>> workaround can be removed, but that's a different issue.
>> Indeed. Any ideas there?
> It looks to me like the data is copied back to a track between passes
> by Effect::CopyInputTracks in Effect.cpp, but I get lost at that
I wish that I had time to look into that, but I really don't.
> Minimize network downtime and maximize team effectiveness.
> Reduce network management and security costs.Learn how to hire
> the most talented Cisco Certified professionals. Visit the
> Employer Resources Portal
> audacity-devel mailing list