[CLAM] synthesizing SMS models in Pd
Xavier Amatriain
xavier at amatriain.net
Wed Dec 19 09:23:01 PST 2007
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
>
>
More information about the clam-users
mailing list