Re: [Audacity-quality] high pitched scrubbing

[Peter S. <pet...@gm...>]

WOW! that Reaper example of Steve's is *exactly* the type of scrubbing that
I have been trying to descibe as "basic scrubbing" with my analogiesof
reel-to-reel tape decks to navigate the recorded audio and vertical scroll
barswith
draggable thingys to navigate documents.

I'd prefer it even more if the playhead kept up even closer with the
draggable
"hand" (in our case the double-headed green triangle - but I do like the
hand
it implis "pich uo and drag to me)

And thanks to David Bailes for suggesting that we look at how Reaper does
it.

If we could have such scrubbing in Audacity that would be absolutely
wonderful,
what many folk have been wanting for years - and I'm pretty sure it would
keep
Koz very happy too.

If we do manage to implement this then this form is the one that really
deserves
the basic name of just "Scrubbing".

That's not to say that we shouldn't, as I have opined before, also retain
the other
more complex forms of scrubbing that Paul currently has - we can keep them
but
just rename them slightly.

But I'm betting that if we did manage to get this then the
Reaper-type-scrubbing would
be far and away the most popular and the most used.

Cheers,
Peter

On Fri, May 13, 2016 at 1:19 PM, Steve the Fiddle <ste...@gm...>
wrote:

> In contrast to the video in my last post, this is the type of
> scrubbing effect that I would expect:
> https://youtu.be/TqkkMf_phFs
>
> Steve
>
> On 13 May 2016 at 12:28, Steve the Fiddle <ste...@gm...>
> wrote:
> > Is this what's intended?
> > https://youtu.be/3_LqwItu0yc
> >
> > In this simple example I can see that the audio is not a series of
> > separate tones, but with real-world audio, how are users to make sense
> > of what they hear?
> >
> > Steve
> >
> > On 12 May 2016 at 16:33, Paul Licameli <pau...@gm...> wrote:
> >>
> >>
> >> On Thu, May 12, 2016 at 4:19 AM, Peter Sampson
> >> <pet...@gm...> wrote:
> >>>
> >>> Paul wrote:
> >>> >Should some speed more than 1x be allowed, but with some limit?  The
> >>> > arbitrary limit now is 32x.  But Peter complains that zoomed out
> >very far
> >>> > in a long track, even this limit is easily exceeded, and the play
> head lags
> >>> > the mouse, which is not what he wants in a good drag >scrub.
> >>> >
> >>> >Should there be no limit?  With no limit, we would get useless dog
> >>> > whistles if we really try to play the resampled sound at such high
> >speed.
> >>> >
> >>> >Should there be no speed limit for playhead movement, but the audio
> >>> > playback will change at some threshold?  That might satisfy Peter.
> >>>
> >>> You misunderstand me Paul - I did point out that I was doing extreme
> >>> testing.  I would not expect many sensible forlk to be
> >>> doing real life drag-scrubbing at zoom levels out side the range of
> Zoom
> >>> normal +/- 2 - otherwise the sound becomes incomprehensible
> >>> and the scrubbing becomes hard to use to the point of uselessness.
> >>
> >>
> >> I don't misunderstand.  Something consistent should be done when zoomed
> far
> >> out.  But it need not be variable speed play.  Sensible folk may expect
> that
> >> "scrubbing" at far out levels really means seeking.  This is what I
> attempt
> >> to do in the latest.
> >>
> >> So now it seeks consistently when you drag, playing small snips, but it
> >> never plays more than 1x speed.
> >>
> >> For now to get more than 1x, you must do the click scrub instead of the
> drag
> >> scrub, and use the scroll wheel.
> >>
> >>>
> >>> Notwitstanding that I still think that drag-scrub should be uniformly
> >>> consistent in what it does, regardless of the zoom level
> >>> the user has currently chosen; no limit on maximum speed and nor limit
> of
> >>> zoom levels that mat be used for drag-scrubbing.
> >>
> >>
> >> I have made it consistent.  But consistent with a limit.  Consistency
> >> without the limit is objectionable to Steve's ears and mine too
> >> increasingly.
> >>
> >>>
> >>>
> >>>
> >>> Back to the analogy of the vetrical scroll bar that I see in gmail at
> the
> >>> right of this long email thread - I can drag the positioning
> >>> tool (the square/rectangular thingy) and drag it slowly upwards to
> scroll
> >>> steardily back looking at ecah emailas I go looking for something
> someone
> >>> said - or I can now that it was very early on and near the top sao I
> can
> >>> just grab that thingy and drag it straight up to the top.
> >>> The thread then goes by unreadably fast, but I get to where I need to
> be
> >>> quicker.  And yes I know I can also click in the vertical scroll-bar
> near
> >>> the top to reposition - and I can do similar with clickin in the scrub
> bar.
> >>> But the point is, as a user, I have both choices.
> >>>
> >>>
> >>> We really should do our utmost to keep drag-scrubbing as simple and as
> >>> straightforward as possible - it is the basic "scrub" that
> >>> most users who have worked with analog tape and video editors would
> >>> expect.
> >>
> >>
> >> Do audio editors expect "scrubbing" in software to play back frames at
> >> normal speed, but skipping many frames?  This is not the analogy with
> >> scrubbing reel to reel tape, but it is still a useful thing in software.
> >> Now we don't have frame divisions, but now my drag scrubbing is doing
> >> something like that.
> >>
> >>>
> >>>
> >>> For my money this means that I would much prefer this to be the basic
> >>> scrub that we offer, so not controlled by right-click and drag
> >>> but just simply controlled by clicking on the scrub bar widget and then
> >>> dragging on it.
> >>
> >>
> >> "Right click and drag" does nothing special.  Perhaps it ought to.
> Right
> >> click and immediate mouse up for menu might be distinguished from right
> >> drag.
> >>
> >> Or maybe we should map all the varieties of scrubbing to various clicks
> and
> >> drags, and eliminate the scrubbing menu?  One less triangle button, and
> a
> >> little more space for labels on the buttons.
> >>
> >> Please note what is available now, please test each thing regardless
> what
> >> your preferences are for the most useful of them, and tell me if you
> >> understand that each might be useful to someone.  All of this is left
> button
> >> only:
> >>
> >> 1 Click in scrub bar, move: this is the old scrubbing, and then mouse
> wheel
> >> can change the speed, with a number appearing, and holding mouse
> switches to
> >> seeking.
> >>
> >> 2 Double click in scrub bar and move:  this is scroll scrubbing.  Mouse
> >> position relative to the centerline determines speed, with a wide zone
> for
> >> 1x speed, but mouse wheel also affects the maximum speed.  I LIKE THIS
> >> BECAUSE YOU CAN ZOOM IN FIRST, THEN FIND WHAT YOU WANT.  Which is not
> >> possible with the drag scrub.  YOU CAN ALSO CHANGE MAGNIFICATION during
> >> scrub, with ctrl-mousewheel.
> >>
> >> 3 Holding the button during scroll scrub switches to scroll-seeking in
> which
> >> the "speed" is the distance between skips.  THIS LETS YOU SKIP AT A
> UNIFORM
> >> RATE -- and there is no other easy way to do that.
> >>
> >> 4 Start a drag in the ruler.  This is new drag scrub (or seek).  This
> >> changes the selection at mouse up -- the previous do not change
> selection.
> >> Holding shift at mouse-up time extends the selection instead of setting
> a
> >> point selection.
> >>
> >> 5 Double click and drag.  This is drag scrub with scrolling.
> >>
> >> I think each of these variations has its uses.  We can argue whether to
> >> remap all of these things to different mouse clicks and drags.  A
> challenge
> >> is making them all discoverable with appropriate status messages and
> hover
> >> tips.
> >>
> >> PRL
> >>
> >>>
> >>>
> >>> You can then use the right-click and scrub to invoke the form of
> scrubbing
> >>> that you currently have in the menu as "Scrubbing" where
> >>> you drag the scrub bar widget and the playhead follows at the speed
> >>> dictated by the mousewheel (default = x1).  I can see that
> >>> some people want and need this form of scrubbing so we should probably
> not
> >>> lose it - but offer it instead as a more subtle, a litlle
> >>> more complex, a little richer maybe, alternative.
> >>>
> >>> Peter
> >>>
> >>>
> >>> On Thu, May 12, 2016 at 6:36 AM, Paul Licameli <
> pau...@gm...>
> >>> wrote:
> >>>>
> >>>>
> >>>>
> >>>> On Wed, May 11, 2016 at 6:26 PM, Paul Licameli <
> pau...@gm...>
> >>>> wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Wed, May 11, 2016 at 5:24 AM, Steve the Fiddle
> >>>>> <ste...@gm...> wrote:
> >>>>>>
> >>>>>> On 11 May 2016 at 08:20, Paul Licameli <pau...@gm...>
> wrote:
> >>>>>> > Steve, try this.  FInd this in Scrubbing.cpp, now at line 288.
> >>>>>> >
> >>>>>> >             mMaxScrubSpeed = options.maxScrubSpeed =
> >>>>>> >
> >>>>>> >                mDragging ? AudioIO::GetMaxScrubSpeed() : 1.0;
> >>>>>> >
> >>>>>> >
> >>>>>> > Make that
> >>>>>> >
> >>>>>> >             mMaxScrubSpeed = options.maxScrubSpeed = 1.0;
> >>>>>>
> >>>>>> That makes it usable. I can now make sense of what's playing,
> whereas
> >>>>>> at super-fast play speed it is almost unintelligible.
> >>>>>>
> >>>>>> Am I right in thinking that you intend the speed of this type of
> >>>>>> scrubbing to be variable?
> >>>>>> If so, that does not seem to be happening correctly. It's playing
> very
> >>>>>> fast almost straight away (after just a few pixels from the play
> >>>>>> position). That's the problem that I was hoping to show in the
> video.
> >>>>>> Here's another video that may show it more clearly (the audio is a
> 440
> >>>>>> Hz sine tone):
> >>>>>> https://youtu.be/jJhoBrYos_g
> >>>>>>
> >>>>>> What would make me happy would be if the play speed was variable
> >>>>>> relative to the distance between the play position and the mouse
> >>>>>> position (rather than relative to the distance between the mouse
> >>>>>> position and the middle of the track). I think that by default this
> >>>>>> should be with the "scrolling" type behavior, though it may also be
> >>>>>> useful to have a non-scrolling option that confines the scrub region
> >>>>>> to the currently displayed waveform by taking the minimum and
> maximum
> >>>>>> mouse positions as the left and right ends of the visible waveform.
> >>>>>>
> >>>>>> You've got all the elements necessary to make a really nice scrub
> >>>>>> feature. It's now just a matter of how the pieces are put together.
> >>>>>> (that's intended to sound encouraging ;-)
> >>>>>>
> >>>>>> Steve
> >>>>>
> >>>>>
> >>>>> That's good.  I thought from other remarks that you were very
> doubtful
> >>>>> about this effort.
> >>>>>
> >>>>> I think we are exposing a big unsettled question about what
> drag-scrub
> >>>>> ought to do when you are very zoomed out, and we (more than two)
> don't
> >>>>> agree.
> >>>>>
> >>>>> Should it play no more than 1x? That was the simple modification I
> >>>>> suggested to you.
> >>>>>
> >>>>> Robert's example of counting in Italian suggests that is not what he
> >>>>> expects.  He would want some more than normal speed.  That would be
> the
> >>>>> analogy with real physical tape scrubbing.  Is the problem then that
> I just
> >>>>> don't have the mouse control working quickly and finely enough?
> >>>>>
> >>>>> Should some speed more than 1x be allowed, but with some limit?  The
> >>>>> arbitrary limit now is 32x.  But Peter complains that zoomed out
> very far in
> >>>>> a long track, even this limit is easily exceeded, and the play head
> lags the
> >>>>> mouse, which is not what he wants in a good drag scrub.
> >>>>>
> >>>>> Should there be no limit?  With no limit, we would get useless dog
> >>>>> whistles if we really try to play the resampled sound at such high
> speed.
> >>>>>
> >>>>> Should there be no speed limit for playhead movement, but the audio
> >>>>> playback will change at some threshold?  That might satisfy Peter.
> >>>>>
> >>>>> Then what should such a play change to?  Just silence, or a skipping
> >>>>> play?
> >>>>
> >>>>
> >>>> Rather than wait for your answers, I just did something to replace the
> >>>> unacceptable high pitched scrubbing.
> >>>>
> >>>> Now, the drag-scrub will really seek, making a skipping play at no
> more
> >>>> than 1x speed if you drag fast or zoomed far out.  If you zoom in, it
> may
> >>>> play at less than unit speed.
> >>>>
> >>>> PRL
> >>>>
> >>>>
> >>>>>
> >>>>>
> >>>>> Does "scrubbing" really mean a well defined thing in other
> programs?  I
> >>>>> can easily find examples in various videos of some programs with the
> 1x
> >>>>> speed limit with play lagging the mouse, and others with skipping
> playback
> >>>>> at 1x but with close following of the mouse.  The Do we want to let
> the user
> >>>>> do one or another depending on the gesture or the menu item?
> >>>>>
> >>>>> More imaginatively, I see how scrolling gestures work through long
> text
> >>>>> with the Macbook touch pad.  You can send the text moving fast, and
> it slows
> >>>>> down as if with "friction."  You might imaging skimming through a
> long track
> >>>>> in some analogous way.  I'll leave that to a future release cycle
> perhaps.
> >>>>>
> >>>>> PRL
> >>>>>
> >>>>>
> >>>>>>
> >>>>>>
> >>>>>> >
> >>>>>> >
> >>>>>> >
> >>>>>> > Now drag-scrub like click-scrub will observe the maximum speed
> limit
> >>>>>> > of 1.
> >>>>>> > Drag scrub like click scrub may lag the mouse position, so it's
> not
> >>>>>> > what I
> >>>>>> > would describe as dragging the playhead.  The difference will be
> in
> >>>>>> > handling
> >>>>>> > the selection.
> >>>>>> >
> >>>>>> > Should we rather have a switch to stuttering seek when the mouse
> >>>>>> > moves fast,
> >>>>>> > and playback at variable speed less than one when movement is
> slow?
> >>>>>> > That
> >>>>>> > would involve more work than one line.  This would act more like a
> >>>>>> > drag but
> >>>>>> > not get high pitched.  This would not simulate dragging of a
> physical
> >>>>>> > tape
> >>>>>> > over a head.  But the point may not be to do exactly that.
> >>>>>> >
> >>>>>> > PRL
> >>>>>> >
> >>>>>> >
> >>>>>> > On Tue, May 10, 2016 at 7:47 PM, Paul Licameli
> >>>>>> > <pau...@gm...>
> >>>>>> > wrote:
> >>>>>> >>
> >>>>>> >> So what remedy would you like to see?
> >>>>>> >>
> >>>>>> >> If it's "scrubbing" not "seeking," isn't play at varying speed
> what
> >>>>>> >> you
> >>>>>> >> expect?
> >>>>>> >>
> >>>>>> >> PRL
> >>>>>> >>
> >>>>>> >>
> >>>>>> >> On Tue, May 10, 2016 at 6:26 PM, Steve the Fiddle
> >>>>>> >> <ste...@gm...> wrote:
> >>>>>> >>>
> >>>>>> >>> This video shows the behaviour on a default 30 second 440 to
> 1320
> >>>>>> >>> Hz
> >>>>>> >>> "chirp"
> >>>>>> >>> https://youtu.be/Kz_EoSJkaaM
> >>>>>> >>>
> >>>>>> >>> Steve
> >>>>>> >>>
> >>>>>> >>> On 10 May 2016 at 20:46, Paul Licameli <pau...@gm...
> >
> >>>>>> >>> wrote:
> >>>>>> >>> > The scrub of 2.1.2 observes a speed limit that is 1x unless
> you
> >>>>>> >>> > change
> >>>>>> >>> > that
> >>>>>> >>> > with the scroll wheel.  But then the play head may lag far
> behind
> >>>>>> >>> > the
> >>>>>> >>> > mouse.
> >>>>>> >>> >
> >>>>>> >>> > The play head does not lag if you seek instead of scrubbing.
> >>>>>> >>> >
> >>>>>> >>> > But I understand that we want drag scrub to be different from
> >>>>>> >>> > either,
> >>>>>> >>> > playing at varying speed but also not lagging far behind the
> >>>>>> >>> > mouse.
> >>>>>> >>> >
> >>>>>> >>> > That means there should not be such a speed limit, or at least
> >>>>>> >>> > the
> >>>>>> >>> > limit
> >>>>>> >>> > should be much higher than 1x.  Right now it is arbitrarily
> 32x.
> >>>>>> >>> > If
> >>>>>> >>> > you are
> >>>>>> >>> > zoomed out far you can easily attain that limit.  At closer
> >>>>>> >>> > magnification,
> >>>>>> >>> > this would be less likely.
> >>>>>> >>> >
> >>>>>> >>> > What should be correct behavior?
> >>>>>> >>> >
> >>>>>> >>> > Should there be some arbitrary speed at which drag scrubbing
> just
> >>>>>> >>> > goes
> >>>>>> >>> > silent?
> >>>>>> >>> >
> >>>>>> >>> > PRL
> >>>>>> >>> >
> >>>>>> >>> >
> >>>>>> >>> > On Tue, May 10, 2016 at 3:28 PM, Steve the Fiddle
> >>>>>> >>> > <ste...@gm...>
> >>>>>> >>> > wrote:
> >>>>>> >>> >>
> >>>>>> >>> >> Click and drag while holding down the left mouse button
> scrubs
> >>>>>> >>> >> with
> >>>>>> >>> >> very  high pitch. I'm guessing that is a "new feature" but
> not
> >>>>>> >>> >> as
> >>>>>> >>> >> intended.
> >>>>>> >>> >>
> >>>>>> >>> >> Steve
> >>>>>> >>> >>
> >>>>>> >>> >>
> >>>>>> >>> >>
> >>>>>> >>> >>
> >>>>>> >>> >>
> ------------------------------------------------------------------------------
> >>>>>> >>> >> Mobile security can be enabling, not merely restricting.
> >>>>>> >>> >> Employees who
> >>>>>> >>> >> bring their own devices (BYOD) to work are irked by the
> >>>>>> >>> >> imposition of
> >>>>>> >>> >> MDM
> >>>>>> >>> >> restrictions. Mobile Device Manager Plus allows you to
> control
> >>>>>> >>> >> only
> >>>>>> >>> >> the
> >>>>>> >>> >> apps on BYO-devices by containerizing them, leaving personal
> >>>>>> >>> >> data
> >>>>>> >>> >> untouched!
> >>>>>> >>> >> https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
> >>>>>> >>> >> _______________________________________________
> >>>>>> >>> >> Audacity-quality mailing list
> >>>>>> >>> >> Aud...@li...
> >>>>>> >>> >>
> https://lists.sourceforge.net/lists/listinfo/audacity-quality
> >>>>>> >>> >
> >>>>>> >>> >
> >>>>>> >>> >
> >>>>>> >>> >
> >>>>>> >>> >
> >>>>>> >>> >
> ------------------------------------------------------------------------------
> >>>>>> >>> > Mobile security can be enabling, not merely restricting.
> >>>>>> >>> > Employees who
> >>>>>> >>> > bring their own devices (BYOD) to work are irked by the
> >>>>>> >>> > imposition of
> >>>>>> >>> > MDM
> >>>>>> >>> > restrictions. Mobile Device Manager Plus allows you to control
> >>>>>> >>> > only the
> >>>>>> >>> > apps on BYO-devices by containerizing them, leaving personal
> data
> >>>>>> >>> > untouched!
> >>>>>> >>> > https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
> >>>>>> >>> > _______________________________________________
> >>>>>> >>> > Audacity-quality mailing list
> >>>>>> >>> > Aud...@li...
> >>>>>> >>> > https://lists.sourceforge.net/lists/listinfo/audacity-quality
> >>>>>> >>> >
> >>>>>> >>>
> >>>>>> >>>
> >>>>>> >>>
> >>>>>> >>>
> ------------------------------------------------------------------------------
> >>>>>> >>> Mobile security can be enabling, not merely restricting.
> Employees
> >>>>>> >>> who
> >>>>>> >>> bring their own devices (BYOD) to work are irked by the
> imposition
> >>>>>> >>> of MDM
> >>>>>> >>> restrictions. Mobile Device Manager Plus allows you to control
> only
> >>>>>> >>> the
> >>>>>> >>> apps on BYO-devices by containerizing them, leaving personal
> data
> >>>>>> >>> untouched!
> >>>>>> >>> https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
> >>>>>> >>> _______________________________________________
> >>>>>> >>> Audacity-quality mailing list
> >>>>>> >>> Aud...@li...
> >>>>>> >>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
> >>>>>> >>
> >>>>>> >>
> >>>>>> >
> >>>>>> >
> >>>>>> >
> >>>>>> >
> ------------------------------------------------------------------------------
> >>>>>> > Mobile security can be enabling, not merely restricting. Employees
> >>>>>> > who
> >>>>>> > bring their own devices (BYOD) to work are irked by the
> imposition of
> >>>>>> > MDM
> >>>>>> > restrictions. Mobile Device Manager Plus allows you to control
> only
> >>>>>> > the
> >>>>>> > apps on BYO-devices by containerizing them, leaving personal data
> >>>>>> > untouched!
> >>>>>> > https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
> >>>>>> > _______________________________________________
> >>>>>> > Audacity-quality mailing list
> >>>>>> > Aud...@li...
> >>>>>> > https://lists.sourceforge.net/lists/listinfo/audacity-quality
> >>>>>> >
> >>>>>>
> >>>>>>
> >>>>>>
> ------------------------------------------------------------------------------
> >>>>>> Mobile security can be enabling, not merely restricting. Employees
> who
> >>>>>> bring their own devices (BYOD) to work are irked by the imposition
> of
> >>>>>> MDM
> >>>>>> restrictions. Mobile Device Manager Plus allows you to control only
> the
> >>>>>> apps on BYO-devices by containerizing them, leaving personal data
> >>>>>> untouched!
> >>>>>> https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
> >>>>>> _______________________________________________
> >>>>>> Audacity-quality mailing list
> >>>>>> Aud...@li...
> >>>>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>>
> ------------------------------------------------------------------------------
> >>>> Mobile security can be enabling, not merely restricting. Employees who
> >>>> bring their own devices (BYOD) to work are irked by the imposition of
> MDM
> >>>> restrictions. Mobile Device Manager Plus allows you to control only
> the
> >>>> apps on BYO-devices by containerizing them, leaving personal data
> >>>> untouched!
> >>>> https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
> >>>> _______________________________________________
> >>>> Audacity-quality mailing list
> >>>> Aud...@li...
> >>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
> >>>>
> >>>
> >>>
> >>>
> >>>
> ------------------------------------------------------------------------------
> >>> Mobile security can be enabling, not merely restricting. Employees who
> >>> bring their own devices (BYOD) to work are irked by the imposition of
> MDM
> >>> restrictions. Mobile Device Manager Plus allows you to control only the
> >>> apps on BYO-devices by containerizing them, leaving personal data
> >>> untouched!
> >>> https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
> >>> _______________________________________________
> >>> Audacity-quality mailing list
> >>> Aud...@li...
> >>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
> >>>
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >> Mobile security can be enabling, not merely restricting. Employees who
> >> bring their own devices (BYOD) to work are irked by the imposition of
> MDM
> >> restrictions. Mobile Device Manager Plus allows you to control only the
> >> apps on BYO-devices by containerizing them, leaving personal data
> untouched!
> >> https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
> >> _______________________________________________
> >> Audacity-quality mailing list
> >> Aud...@li...
> >> https://lists.sourceforge.net/lists/listinfo/audacity-quality
> >>
>
>
> ------------------------------------------------------------------------------
> Mobile security can be enabling, not merely restricting. Employees who
> bring their own devices (BYOD) to work are irked by the imposition of MDM
> restrictions. Mobile Device Manager Plus allows you to control only the
> apps on BYO-devices by containerizing them, leaving personal data
> untouched!
> https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
> _______________________________________________
> Audacity-quality mailing list
> Aud...@li...
> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>