[CLAM] synthesizing SMS models in Pd
Rich E
reakinator at gmail.com
Sun Dec 30 11:00:21 PST 2007
I've been digging through the CLAM code trying to figure this out again.. I
have much work to do. Now there are four things I know of that I am not
doing:
a) the circular shift
b) multiplying by an 'inverse' Blackmann window(not comprehending the
reasoning behind this yet)
c) any normalization (although I don't see this in SpectralSynthesis.cxx
d) undo the zero padding?
But first is first; the circular shift. Is it a simple rotation of the
samples by half the audio block?
On Dec 19, 2007 6:23 PM, Xavier Amatriain <xavier at amatriain.net> wrote:
> Sorry, that should have been IFFT not SFFT.
>
> About the windowing you are doing on the residual: are you multiplying
> by the *inverse*? Is this window normalized?
>
> Rich E wrote:
> > Xavier,
> >
> > Its starting to get clearer, but I still have a couple questions as I
> > am definetaly not doing the resynthesis correct yet (I am getting a
> > periodic pitch.. not sound).
> >
> > The analysis window, which by default is a BlackmanHarris92
> > with a 75% overlap. You need to multiply by the
> > inverse of this window after the SFFT.
> >
> >
> > sorry for having to ask, but what is an SFFT? If it is the same as an
> > STFT or FFT, at which point do I do this? I was under the impression
> > from one of Serra's publications that all I had to do with
> > resynthesize the residual FFT, but don't have to do any more FFTing.
> >
> > If this is an IFFT, my attempt is on the right track, but I am still
> > not getting a noise sound. I am windowing the residual IFFT by a 75%
> > overlap and multiplying it by the BlackmanHarris92 window, then
> > re-windowing the result with a 50% overlap and multiplying by a
> > triangle window. But my result is pitched, and this changes if I
> > change the overlap.
> >
> > Can anyone see what I am doing wrong?
> >
> > regards,
> > rich
> >
> > And then a completely independent
> > triangular window with a size equal to twice
> > the analysis hop and overlap 50%. This is the one in charge of
> > getting a
> > smooth overlap and add process in place.
> >
> > Hope it helps.
> >
> > X
> >
> > Rich E wrote:
> > > Okay, I didn't think of looking for the overlap size by checking
> the
> > > timestamps, but that seems obvious now.. thanks! I have found
> there
> > > are many things preventing the SDIF files from being used in
> > real-time
> > > (such as the 1TRC frames not containing birth and death
> > information).
> > > So I am already buffering the data in a format that can be used in
> > > real-time, so finding the overlap before sysnthesis-time
> > shouldn't be
> > > a problem.
> > >
> > > However, I do not see the 1WIN matrix within the SMS-produced
> files.
> > > I assumed it is a triangle window with an overlap factor of 2
> > (this is
> > > the default settings in SMSTools), but of course this can be
> > changed,
> > > in which case I would not know how to find the windowing function.
> > > But I tried these settings without success (in comparison to
> > > SMSTools-produced residual sound), so I am still looking for the
> > > correct ones.
> > > cheers,
> > > rich
> > > On Dec 14, 2007 6:30 PM, Richard Dobson
> > > <richarddobson at blueyonder.co.uk
> > <mailto:richarddobson at blueyonder.co.uk>
> > > <mailto:richarddobson at blueyonder.co.uk
> > <mailto:richarddobson at blueyonder.co.uk>>> wrote:
> > >
> > > Rich E wrote:
> > > > Okay, sorry for getting into too much pd stuff... I
> > basically just
> > > > need to know what needs to be done to the 1STF data before
> > I can
> > > > synthesize it. Is it ready to go, or is windowing still
> > necessary?
> > > > Should the frames be overlapped?
> > > >
> > >
> > > It's plain real/imaginary DFT data. SO in that sense yes it is
> > > ready to
> > > go straight into the IFFT. It will almost certainly require
> > windowing.
> > > If you haven't already done so, you will neded to check the
> > formal
> > > definition of the 1STF format e.g. at:
> > >
> > > http://www.cnmat.berkeley.edu/SDIF/FrameTypes.html#1STF
> > >
> > > SDIF is famous/notorious for being particularly "loose" about
> > > definitions and content. In short, each frame (matrix) is
> > time-stamped
> > > (from the centre of the window, because they like doing
> > things that
> > > way), and you have to determine the overlap from that (which
> > means you
> > > have to read at least two frames before you can start
> rendering,
> > > so this
> > > is not a true real-time streaming format; one would assume
> the
> > > overlap
> > > is constant, but the format does not see the need to mandate
> > it);
> > > there
> > > should be a 1WIN matrix that defines the window to use. Beyond
> > > that, all
> > > I can say is "good luck"!
> > >
> > >
> > > Richard Dobson
> > >
> > >
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > CLAM mailing list
> > > CLAM at iua.upf.es <mailto:CLAM at iua.upf.es>
> > <mailto:CLAM at iua.upf.es <mailto:CLAM at iua.upf.es>>
> > > http://www.iua.upf.es/mtg/clam
> > >
> > >
> > >
> >
> ------------------------------------------------------------------------
> > >
> > > _______________________________________________
> > > CLAM mailing list
> > > CLAM at iua.upf.es <mailto:CLAM at iua.upf.es>
> > > http://www.iua.upf.es/mtg/clam
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.clam-project.org/pipermail/clam-users-clam-project.org/attachments/20071230/2eaceb2f/attachment.html>
More information about the clam-users
mailing list