| From Steve the Fiddle <stevethefiddle@...>
| Sat, 11 Jun 2011 12:41:44 +0100
| Subject: [Audacity-quality] Proposal to rationalize and improve Normalize, Amplify & DC
> On Sat, Jun 11, 2011 at 10:59 AM, Peter Sampson
> <petersampson48@...> wrote:
> > Just tested the 10Jun nightly build on XP-HE-SP - the new Normalize appears
> > to work fine on this platform. I tested it using linked stereo tracks and
> > then created an artificially very unbalance pair and used the independent
> > channel Normalization - to my ears this appeared to restore the balance (but
> > the recording was BBC off-air FM so probably well balanced by the BBC
> > engineers to start with - and compressed).
> > 1) I agree with Steve's earlier comments in this this thread:
> > 1.1) I think that we should only allow negative numbers to be entered (so
> > that this function will never induce clipping).
> > 1.2) Negative zero should not be displayed, if the user types that in it
> > should just be replaced with 0.0
> > 1.3) On first use after installing 1.3.14/2.0 the default Normalization
> > should be set to zero (to avoid the carry-through of peoples previous
> > "positive" settings, caused by having the minus sign outside the box).
> As I posted previously, I think that "numbers greater than 0 not
> allowed" will save a lot of support questions.
> 1.2) I don't see any problem with "-0.0" (it is a valid number that
> may be used in other effects), and as Gale wrote it would be
> convenient if -0.0 was the initial default value with the cursor
> placed between to minus and the 0 (-|0.0). I don't know if the default
> cursor placement is possible, but I don't think this is a big deal -
> just a minor enhancement if it is possible. (I doubt that it's
> possible on Linux as focus has never been successfully moved to any of
> the controls for Audacity effects on Linux). For an initial default
> value I have a slight preference for -0.0 rather than unsigned 0.0 as
> the signed version gives an indication to users that a negative number
> is expected.
As to David's concern that screen readers will not indicate partial
selections, I think that is supposition unless we try it (though a very
reasonable supposition). I only have NVDA, but it does read out
if you actively select part of the text in a box. In any case I see
Martyn has disallowed double negatives being treated as positive,
so "--3" dB gives you 0 dB rather than +3 dB.
However "cursor after the minus sign" is somewhat non-standard
so I'd be happy to settle for something else. If we disallow clipping
I think it's got to be transparent, e.g. OK is greyed out and text
appears explaining why input is not being processed (see
Truncate Silence for an example).
On the whole I would prefer not to disallow clipping. My idea of
the minus sign in the box was to avoid adding permanent text like
"(positive value allows clipping)" or an "Allow clipping" box.
> 1.3) We need to be careful here. When a new Audacity session is
> started, it should remember to setting last used (as now). I think
> that the suggestion here is regarding the first use of Normalize after
> updating to 1.3.14. Perhaps the easiest way to handle this would be:
> If the saved default value is positive, then Normalize should read
> that number with the sign reversed. Thus, if the last use of Normalize
> in Audacity 1.3.13 had the value "3.0" (minus 3 is implied by the
> minus sign in the GUI), then Normalize in Audacity 1.3.14 should read
> that as minus 3.0.
Can it be done? It would then have to switch over on second use
to treating a non-negative as positive. If not, then perhaps you
might only allow Normalize to treat a value as positive if "+"
precedes the value, though I don't really like that.
If we want to allow clipping we may have to accept Normalize
will be slightly more interactive/complex.
> Question: Would it be possible to have a minus sign in the text box
> that is not editable?
> > This way Normalize should be (remain) the amplitude adjustment tool of
> > choice for most folk - with Amplify designed for the use of more
> > sophisticated/experienced users who know about and understand clipping
That's if the novices can find Normalize. A sizable minority can only
> > 2) When both of the action check boxes are un-ticked (DC removal and
> > Normalize) then the Preview and OK buttons should be greyed out and made
> > inoperable. Otherwise null processing is allowed which makes no sense.
> > This is not a new issue it has always been the case, but I have only just
> > noticed this in today's testing.
> I agree that the OK and Preview buttons should be greyed out when no
> action is selected.
> > 3) Cosmetically I think it would look better if the data box for the
> > required dB level could be centred or possibly left justified with the text
> > rather than with the check boxes. Or maybe even placed to the right of the
> > "Normalize maximum amplitude to:" text - on my screen there appears to be
> > ample space to do this, but would it cause a problem on low resolution
> > screens?
> > Of the above:
> > 3: is a feature request and I am happy to let the layout rest as it is (the
> > functionality is far more important than the image)
> > 2: is in my view a low-P long-standing bug - it doesn't cause any problems,
> > but is worth noting on Bugzilla and should be easily fixable
> > 1: fixing 1.1 and 1.3 will save us a lot of support issues on the forum and
> > on @feedback and so is well worth doing in my view if this can be managed.
> > Your coding work on this is very much appreciated Martyn.
> > Thanks,
> > Peter
> > ________________________________
> > From: Steve the Fiddle <stevethefiddle@...>
> > To: Gale Andrews <gale@...>; audacity-quality
> > <audacity-quality@...>
> > Sent: Sat, June 11, 2011 2:55:13 AM
> > Subject: Re: [Audacity-quality] Proposal to rationalize and improve
> > Normalize, Amplify & DC
> > On Fri, Jun 10, 2011 at 8:14 PM, Gale Andrews <gale@...> wrote:
> >> | From Martyn Shaw <martynshaw99@...>
> >> | Fri, 10 Jun 2011 00:24:06 +0100
> >> | Subject: [Audacity-quality] Proposal to rationalize and improve
> >> Normalize, Amplify & DC
> >>> OK, so I committed a fix for what was asked for / agreed.
> >>> Commit log says:
> >>> Move minus sign to text box.
> >>> Allow stereo normalising.
> >>> Default to stereo normalising.
> >>> Speedup (maybe 20%) by use of track->GetMinMax instead of an expensive
> >>> conditional in a tight loop.
> >>> I have only tested on Win 7 so would appreciate more platforms.
> >>> I'm much happier with it now, what about you?
> >> Many thanks, Martyn.
> >> I haven't tested anything about speed or actual behaviour of the new
> >> "stereo normalize" yet, but as the negative sign is a logged bug, I've
> >> commented on that in the appropriate place:
> >> http://bugzilla.audacityteam.org/show_bug.cgi?id=402
> >> I fancy we will have support issues with novices upgrading unless
> >> we do physically put the negative sign in the box (or otherwise
> >> warn about clipping). As I see it this is one issue we would not
> >> have with a single effect (the "Allow clipping" bow would take
> >> care of it).
> >> I think my vote as things are now is that we should live with
> >> initialising to "-0.0", cursor after the minus, "0.0" selected, if
> >> that is possible.
> > I also expect that there will be a brief flurry of support issues -
> > the main point being that if a user was previously using a non-zero
> > Normalize level in Audacity 1.3.13 (or earlier), after upgrading they
> > will automatically have a positive Normalize level.
> > A simple feature request that would prevent this issue would be to
> > simply disallow positive Normalize levels. In "ordinary" usage,
> > Normalizing to a positive dB value would never be required. The few
> > "extraordinary" cases where a user may want to amplify above 0 dB are
> > covered by the Amplify effect.
> > Although this is clearly a "feature request" and is not addressing a
> > bug, it may be in our interests to consider disallowing positive
> > Normalize levels sooner rather than later, so as to avert most of
> > these anticipated support cases.
> > I would expect the code change necessary to limit the Normalize level
> > input to <= 0.0 dB would be trivial. Can anyone confirm or contradict
> > that assumption? Does anyone have a better suggestion of how to deal
> > with positive Normalize levels?
> > Steve
> >>> PS I don't like the presets in audacity.cfg to be in CsPresets, since
> >>> the 'CS' prefix is meaningless in most cases, but that is for another
> >>> thread.
> >> +1 on ripping out CleanSpeech but retaining the functionality of its
> >> presets.
> >> Gale