23 Mar
2004
23 Mar
'04
6:42 p.m.
pleased to announce the new DSP package 'pvoc'. at its core, it
features the CARL phase vocoder.
there are three LADSPA units in this package (Exaggerate, Transpose,
Accumulate) plus a commandline utility for time compression and
expansion of n-channel audio data streams.
compilation of this package will probably be an even rougher ride than
with the initial release of caps (pvoc depends on FFTW3 and sndfile)
but i'll be happy to help should you run into problems.
http://quitte.de/dsp/pvoc.html
----------------------------------------------------------------------
in other news, the caps plugin collection has moved to version 0.1.11,
with refinements pertaining to the amplifier emulation plugins and the
SweepVF filter.
http://quitte.de/dsp/caps.html
as always, your feedback is welcome.
enjoy,
tim
24 Mar
24 Mar
12:20 a.m.
On tis, 2004-03-23 at 23:31, Tim Goetze wrote:
pleased to announce the new ... [vocoder]
there are three LADSPA units in this package (Exaggerate, Transpose,
Accumulate) plus a commandline utility for time compression and
expansion of n-channel audio data streams.
I believe I understand exaggerate & transpose, but what is accumulate in
vocoder domain?
mvh // Jens MAndreasen
compilation of this package will probably be an even rougher ride than
with the initial release of caps (pvoc depends on FFTW3 and sndfile)
but i'll be happy to help should you run into problems.
http://quitte.de/dsp/pvoc.html
----------------------------------------------------------------------
in other news, the caps plugin collection has moved to version 0.1.11,
with refinements pertaining to the amplifier emulation plugins and the
SweepVF filter.
http://quitte.de/dsp/caps.html
as always, your feedback is welcome.
enjoy,
tim
7:10 a.m.
[Jens M Andreasen]
On tis, 2004-03-23 at 23:31, Tim Goetze wrote:
the algorithm 'accumulates' energy from the pvoc frame bins into a
'static' pvoc frame, thus the basic effect sounds a bit like an echo
or reverberation. (in fact i think it could be made to produce a
real nice reverb tail, with a _lot_ of tweaking though.)
of course this is combined with a decay mechanism so the stored energy
doesn't stay around forever. also, for some sound effects of the
stranger kind, Accumulate can also move the stored frequency
coefficients around, resulting in constant glissando of the 'sound
tail'.
tim
pleased to announce the new ... [vocoder]
there are three LADSPA units in this package (Exaggerate, Transpose,
Accumulate) plus a commandline utility for time compression and
expansion of n-channel audio data streams.
I believe I understand exaggerate & transpose, but what is accumulate in
vocoder domain?
9:33 a.m.
[Jens M Andreasen]
On ons, 2004-03-24 at 11:41, Tim Goetze wrote:
...
...
i've never used a harmonizer, so i can't tell. in any event, rather a
mix of delay and reverb than reverb alone. best you simply try the
plugin if you're eager to find out. :)
(i reckon the plugin should run rt on a pII-400.)
tim
Accumulate can also move the stored frequency
coefficients around, resulting in constant glissando of the 'sound
tail'.
Mmmm ... A bit like having a reverb, feedback coupled thru a harmonizer? 
3:06 p.m.
Tim Goetze wrote on Wed, 24-Mar-2004:
the algorithm 'accumulates' energy from the
pvoc frame bins into a
'static' pvoc frame, thus the basic effect sounds a bit like an echo
or reverberation. (in fact i think it could be made to produce a
real nice reverb tail, with a _lot_ of tweaking though.)
of course this is combined with a decay mechanism so the stored energy
doesn't stay around forever. also, for some sound effects of the
stranger kind, Accumulate can also move the stored frequency
coefficients around, resulting in constant glissando of the 'sound
tail'.
This is pretty much what FreqTweak's Delay module does, although
I could not reproduce the exact Accumulate effect sound in FT upon
some basic tweaking. Of course, FT has absurdly more control :)
I've been waiting for someone to post a preset for FT that they
hand built to produce a good reverb tail, but it appears no one's
up to the challenge.....
The pitch scaling algorithm sounds quite similar to the one in
FT (which is basically the Sprengler algo from SWH's pitch scaler),
but Tim's sounds better, so I'm going to go code diving.
jlc
5:10 p.m.
[Jesse Chappell]
Tim Goetze wrote on Wed, 24-Mar-2004:
it does indeed :)
the algorithm 'accumulates' energy from
the pvoc frame bins into a
'static' pvoc frame, thus the basic effect sounds a bit like an echo
or reverberation. (in fact i think it could be made to produce a
real nice reverb tail, with a _lot_ of tweaking though.)
of course this is combined with a decay mechanism so the stored energy
doesn't stay around forever. also, for some sound effects of the
stranger kind, Accumulate can also move the stored frequency
coefficients around, resulting in constant glissando of the 'sound
tail'.
This is pretty much what FreqTweak's Delay module does, although
I could not reproduce the exact Accumulate effect sound in FT upon
some basic tweaking. Of course, FT has absurdly more control :) I've been waiting for someone to post a preset for
FT that they
hand built to produce a good reverb tail, but it appears no one's
up to the challenge.....
i don't know how you feel about this, but my personal impression is
that the classic all-pass/comb reverbs are capable of producing very
fine sounding tails (especially with a slowly modulated delay line),
it's more the early and distinct reflections that i see as a weak
point.
so, seeing the dramatic difference in CPU usage between the two
techniques, using FT/pvoc to produce a reverb tail would seem a rather
academic exercise to me. though, of course, "you won't know if you
don't go", maybe it's a particularly enlightening experience.
The pitch scaling algorithm sounds quite similar to the
one in
FT (which is basically the Sprengler algo from SWH's pitch scaler),
but Tim's sounds better, so I'm going to go code diving.
it would be more accurate to call it Richard's than mine -- i only
re-packaged the code from Richard Dobson's pvplugs in LADSPA shape.
(actually, the whole pvoc package is just a by-product; i needed the
phase vocoder for something completely different but found the plugins
good fun, and the stretch utility worth writing.)
to tell the truth, i haven't even spent much time deciphering the
Transpose algorithm. it did sound kind of OK with the guitar so it got
green light for shipping. :)
tim
4:02 p.m.
Tim Goetze wrote on Tue, 23-Mar-2004:
pleased to announce the new DSP package
'pvoc'. at its core, it
features the CARL phase vocoder.
there are three LADSPA units in this package (Exaggerate, Transpose,
Accumulate) plus a commandline utility for time compression and
expansion of n-channel audio data streams.
compilation of this package will probably be an even rougher ride than
with the initial release of caps (pvoc depends on FFTW3 and sndfile)
but i'll be happy to help should you run into problems.
The stretch program was not properly clamping the output from
-1.0 -> 1.0 yielding to terrible cracks upon writing as 16bit
wave files when the output is clipped. The fact that non-clipping
(but very close to) input yielded clipping output is another issue,
but not crucial.
I've attached a patch that fixes the problem.
Other than that, this sounds pretty darn good compared to soundtouch
(a time domain algorithm) at more extreme stretch factors.
jlc
5 p.m.
[Jesse Chappell]
Tim Goetze wrote on Tue, 23-Mar-2004:
> pleased to announce the new DSP package 'pvoc'. at its core, it
> features the CARL phase vocoder.
[...]
The stretch program was not properly clamping the
output from
-1.0 -> 1.0 yielding to terrible cracks upon writing as 16bit
wave files when the output is clipped. The fact that non-clipping
(but very close to) input yielded clipping output is another issue,
but not crucial.
I've attached a patch that fixes the problem.
applied, thanks.
the current release is 0.1.5; it also offers a new -a/--amplify option
taking a linear scaling factor to apply to the output signal(s).
unfortunately, i can't come up with an algorithm giving the perfect
scale factor for the stretching algorithm. ideas welcome, of course.
Other than that, this sounds pretty darn good compared
to soundtouch
(a time domain algorithm) at more extreme stretch factors.
my impression too. for one obvious reason, it's much better at
handling signal phase (no cancellation as with soundtouch). to my
surprise, i also find it's better at handling transients, but not
quite perfect in this regard.
it's good enough for extended score transcription sessions without
risking ear-damage en tout cas. :)
tim
5:09 p.m.
Tim Goetze wrote on Wed, 24-Mar-2004:
I just realized that you may not want to clamp if your output
is a 32 bit float or double, as it is fully capable of handling
the value as produced. For instance, if (well, when) we suck this
algorithm into ardour we don't need to clamp, as our internal
format is float.
[Jesse Chappell]
The stretch
program was not properly clamping the output from
-1.0 -> 1.0 yielding to terrible cracks upon writing as 16bit
wave files when the output is clipped. The fact that non-clipping
(but very close to) input yielded clipping output is another issue,
but not crucial.
I've attached a patch that fixes the problem.
applied, thanks. unfortunately, i can't come up with an algorithm
giving the perfect
scale factor for the stretching algorithm. ideas welcome, of course.
Hmm, this is a tough one.... even soundtouch doesn't get it right,
and it doesn't have the same issues as the FFT approach....
jlc
5:20 p.m.
[Jesse Chappell]
maybe i'll come up with something when i find the time to really work
with the phase vocoder, which will probably give a bunch of insights.
too much to do right now to really dive into it (i feel that the pvoc
package is just scratching the surface).
tim
Tim Goetze wrote on Wed, 24-Mar-2004:
I just realized that you may not want to clamp if your output
is a 32 bit float or double, as it is fully capable of handling
the value as produced. For instance, if (well, when) we suck this
algorithm into ardour we don't need to clamp, as our internal
format is float.
true. i'll make it an option.
[Jesse Chappell]
The
stretch program was not properly clamping the output from
-1.0 -> 1.0 yielding to terrible cracks upon writing as 16bit
wave files when the output is clipped. The fact that non-clipping
(but very close to) input yielded clipping output is another issue,
but not crucial.
I've attached a patch that fixes the problem.
applied, thanks. unfortunately,
i can't come up with an algorithm giving the perfect
scale factor for the stretching algorithm. ideas welcome, of course.
Hmm, this is a tough one.... even soundtouch doesn't get it right,
and it doesn't have the same issues as the FFT approach.... 
6:12 p.m.
On Wed, 24 Mar 2004 22:09:46 +0100 (CET)
Tim Goetze <tim(a)quitte.de> wrote:
[Jesse Chappell]
Correct me if I'm wrong, but isn't clipping only a problem when
converting to integer PCM sound file. If that is the case, you
can leave the data unclipped and let libsndfile do the clipping
by using this:
http://www.mega-nerd.com/libsndfile/command.html#SFC_SET_CLIPPING
Erik
--
+-----------------------------------------------------------+
Erik de Castro Lopo nospam(a)mega-nerd.com (Yes it's valid)
+-----------------------------------------------------------+
"In my opinion, shareware tends to combine the worst of
commercial software (no sources) with the worst of free
software (no finishing touches). I simply do not believe
in the shareware market at all." -- Linus Torvalds
Tim Goetze wrote on Wed, 24-Mar-2004:
I just realized that you may not want to clamp if your output
is a 32 bit float or double, as it is fully capable of handling
the value as produced. For instance, if (well, when) we suck this
algorithm into ardour we don't need to clamp, as our internal
format is float.
true. i'll make it an option. [Jesse Chappell]
The
stretch program was not properly clamping the output from
-1.0 -> 1.0 yielding to terrible cracks upon writing as 16bit
wave files when the output is clipped. The fact that non-clipping
(but very close to) input yielded clipping output is another issue,
but not crucial.
I've attached a patch that fixes the problem.
applied, thanks.
6:27 p.m.
Erik de Castro Lopo wrote on Thu, 25-Mar-2004:
Correct me if I'm wrong, but isn't clipping only a problem when
converting to integer PCM sound file. If that is the case, you
can leave the data unclipped and let libsndfile do the clipping
by using this:
http://www.mega-nerd.com/libsndfile/command.html#SFC_SET_CLIPPING
Beautiful! Erik to the rescue, this is the correct solution.
Throw out my patch and replace with a call to do that.
jlc
I just realized that you may not want to clamp if your
output
is a 32 bit float or double, as it is fully capable of handling
the value as produced. For instance, if (well, when) we suck this
algorithm into ardour we don't need to clamp, as our internal
format is float.
true. i'll make it an option.
6:48 p.m.
[Jesse Chappell]
Erik de Castro Lopo wrote on Thu, 25-Mar-2004:
Correct me if I'm wrong, but isn't clipping only a problem when
converting to integer PCM sound file. If that is the case, you
can leave the data unclipped and let libsndfile do the clipping
by using this:
http://www.mega-nerd.com/libsndfile/command.html#SFC_SET_CLIPPING
Beautiful! Erik to the rescue, this is the correct solution.
Throw out my patch and replace with a call to do that.
yes, but ... :)
stretch isn't using sndfile for piped I/O which needs clipping too (i
wish i could use it but sndfile doesn't like pipes, at least not the
versions that compile in ancient build environments like mine).
pvoc-0.1.6 (current) adds a new -l (--limit) option that turns on
clipping. later versions' man page will recommend its use with int
output.
tim
I just realized that you may not want to clamp if your
output
is a 32 bit float or double, as it is fully capable of handling
the value as produced. For instance, if (well, when) we suck this
algorithm into ardour we don't need to clamp, as our internal
format is float.
true. i'll make it an option.
7346
days inactive
7347
days old
linux-audio-dev@lists.linuxaudio.org
14 comments
4 participants
participants (4)
-
Erik de Castro Lopo -
Jens M Andreasen -
Jesse Chappell -
Tim Goetze