variable speed playback & smoothing

Hello. I've been advised to ask about smoothing and how it
might relate 
to a variable-speed playback control.

Would the purpose of such a technique would be to reduce the
jarring 
effect of a sudden change in playback rate? Alternatively,
is the 
purpose to reduce the (possibly) inevitable clicking noise
that seems to 
result from any unnatural playback?

How is such an effect accomplished? A linear fade-out of the
new 
playback-state and fade-in of the new playback-state would
seem to solve 
the problem to me, but I may not be understanding exactly
what the 
problem is. Any suggestions of where to start thinking about
this?

Thanks,
Michael

------------------------------------------------------------
-------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216
239;13503038;w?http://sf.net/marketplace
_______________________________________________
Audacity-devel mailing list
Audacity-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/audacity
-devel

On Fri, 2008-03-28 at 01:37 -0400, Michael Brooks wrote:
> Hello. I've been advised to ask about smoothing and how
it might relate 
> to a variable-speed playback control.
> 
> Would the purpose of such a technique would be to
reduce the jarring 
> effect of a sudden change in playback rate?
Alternatively, is the 
> purpose to reduce the (possibly) inevitable clicking
noise that seems to 
> result from any unnatural playback?

Playing back at a different rate doesn't have to result in
clicks if a
speed change algorithm is being used (as with the time
track). However
is the user is directly controlling the playback speed with
a fader,
then the input is not smooth (as with the time track
envelope) but jumps
from point to point.

I think what is being got at is that some sort of smoothing
will be
needed so that when the user asks for the playback speed to
suddenly
double, it in fact accelerates up to double speed smoothly.
It needs to
change quite quickly, but not a jerkily. Think of the effect
of changing
the speed switch on a record player - because of the inertia
of the
table, it doesn't change speed instantly.

This is more complicated for doing scrubbing of the playback
cursor,
because the "speed" will have to be obtained by
differentiating the
position of the cursor, and so will be a much noisier
signal.

> How is such an effect accomplished? A linear fade-out
of the new 
> playback-state and fade-in of the new playback-state
would seem to solve 
> the problem to me, but I may not be understanding
exactly what the 
> problem is. Any suggestions of where to start thinking
about this?
 You aren't fading the audio at all, but putting something
(a "change
controller") between the user input and the actual
algorithm doing the
speed changing for playback. This has to convert the noisy
input into
something that the algorithm can 1) cope with and 2) sound
decent when
doing.

Quick example - if I try to push the cursor along at twice
normal speed,
but my mouse skills aren't great, it moves in a series of
jerks (on a
small scale, it's unavoidable). if you try and actually
follow my mouse
movements, you'll alternate, playing at 4 times normal speed
half the
time and zero speed the rest, which isn't what I wanted at
all.

Richard


------------------------------------------------------------
-------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216
239;13503038;w?http://sf.net/marketplace
_______________________________________________
Audacity-devel mailing list
Audacity-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/audacity
-devel

On Fri, 2008-03-28 at 11:35 -0400, Michael Brooks wrote:
> So, is the "poor man's scrubbing"
functionally the same as just
> restarting play at a time slightly ahead?
Yes. Works like the search buttons on a CD player, playing
short
sections of audio skipping other sections.

> For true scrubbing with the playback cursor, I would
think a more
> continuous approach is needed. Either that or a faster
interface with
> the audio thread.
> The other approach to this problem is to play the
'scrubbed-over'
> audio at a higher speed, but still to play it, rather
than jumping to
> the new position of the cursor. If I can get a dynamic
variable speed
> controller to work, this should be possible as well.
Most users with a tape background would expect the audio to
play
continually, speed-ed up. This would mean sample rate
converting the
audio back to the playback rate in order to play the samples
quicker.
Could become very CPU intensive (effectively playback at
several times
the project rate and a sample rate conversion from up to a
couple of
hundred kilohertz).

Whether this is actually the most useful implementation is
open to
question - maybe pushing the data through the change tempo
effect would
be more useful, because the pitch wouldn't get distorted by
the
acceleration process.

Richard


------------------------------------------------------------
-------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216
239;13503038;w?http://sf.net/marketplace
_______________________________________________
Audacity-devel mailing list
Audacity-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/audacity
-devel

On Sat, 2008-03-29 at 16:14 -0400, Michael Brooks wrote:
> Richard Ash wrote: 
> > Most users with a tape background would expect the
audio to play
> > continually, speed-ed up. This would mean sample
rate converting the
> > audio back to the playback rate in order to play
the samples quicker.
> > Could become very CPU intensive (effectively
playback at several times
> > the project rate and a sample rate conversion from
up to a couple of
> > hundred kilohertz).
> >   
> Good point. Would it be any more CPU intensive than the
current
> speed-up done by the Transcription Toolbar?
Don't know. Not many people use the Transcription Toolbar,
an almost
always they do so on a one-track project. If you start using
the same
process for scrubbing, then people will want to do it in
multi-track
projects, so it needs to scale to N tracks gracefully -
maybe some sort
of controlled degradation if the system can't cope?

>  At the lowest level, would the sound processor just
skip every other
> sample to play twice as fast?
Not using the standard sample rate conversion libraries,
they will
process all the input samples through a multi-stage digital
filter in
order to perform the Sinc interpolation process, so doubling
the input
rate doubles the number of floating point multiplies to be
done (I
think, it's a while since I worked on this).
 
> Interesting alternative. I haven't looked at the change
tempo effect
> yet. Would that kind of automatic/streaming processing
of the audio be
> difficult to implement?
No idea. Depends what libsoundtouch implements as
interfaces. Have a
look at their documentation.

Richard


------------------------------------------------------------
-------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216
239;13503038;w?http://sf.net/marketplace
_______________________________________________
Audacity-devel mailing list
Audacity-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/audacity
-devel