The a-z analogy is just my invention. Any linear algebra book will explain
more than that and the closest example algorithm is the pseudo inverse.
As for the phase vocoder, there is probably just no need to clear the presum
up. The pv is a time-variant reverb; the presum is a time-invariant. Now
that you have to bear with one reverb already, the other becomes easier to
swallow. Even beneficial sometimes, because if the pv reverb is large enough
to be an echo (double transients that is), more reverbs can smear it up.
w.x.
-----Original Message-----
From: Domagoj Saric
Sent: Monday, May 14, 2012 10:36 AM
To: music-dsp@music.columbia.edu
Subject: Re: [music-dsp] Window presum synthesis
Hi, everyone, apologies for the delay...was on a short vacation ;)
On 25 April 2012 02:22, Wen Xue <mr.x....@gmail.com> wrote:
Yes, it's very right that you can't recover a and b from a+b alone - half
the information is missing.
However, if we remember the frames overlap, things are a little different.
Say you also know b+c, then to guess a, b and c from a+b and b+c, only 1/3
information is missing. If you know all the way through to y+z, then only
1/26 is missing, from that you can make a pretty good guess at a--z.
Perfect
recovery can be achieved with a minor trick, e.g. fade-in your sequence so
that a=0.
Whether or not the application tries to recover a--z is another matter.
Even
if it doesn't, a--z plus a reverb probably sounds fairly like a--z. But if
it wants to, it can.
Thanks, clever insight :)
I haven't fully wrapped my head around the procedure in the OLA case [i.e.
how
to do it in real time when you have a stream of partially overlapping frames
(a,
b, c, ..., z) w/o having to remember a large amount/all of the signal's
history], I can only guess that the sinc pass tries to do/approximate just
this...
In addition, even though I can see how this procedure/idea could work with
an
unmodified signal I'm not so sure how it would work in the general/phase
vocoder
case:
- if a' marks a modified frame a (i.e. frame a that went through a PV and
was
for example pitch shifted)
- if we 'turn on' "window presum" (with the window twice the size of the
DFT),
then we no longer pass single frames through the DFT and PV but rather time
aliased frames: IOW we have a+b on input and (a+b)' on output
- now it is no longer clear (to me) how we could get the stream a', b',
c'...
from the (a+b)', (b+c)', (c+d)'... stream (especially if we consider that
the PV
modification can change between each frame, e.g. the pitch shift amount)...
Do you perhaps know a paper/book/... that explains/explores this a--z idea
in
more depth (with some nice pseudo code of course ;D)?
Domagoj Saric
Software Architect
www.LittleEndian.com
--
dupswapdrop -- the music-dsp mailing list and website:
subscription info, FAQ, source code archive, list archive, book reviews, dsp
links
http://music.columbia.edu/cmc/music-dsp
http://music.columbia.edu/mailman/listinfo/music-dsp
--
dupswapdrop -- the music-dsp mailing list and website:
subscription info, FAQ, source code archive, list archive, book reviews, dsp
links
http://music.columbia.edu/cmc/music-dsp
http://music.columbia.edu/mailman/listinfo/music-dsp
