[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