[CLAM] synthesizing SMS models in Pd

[Rich E]

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-0002.htm>