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 <[EMAIL PROTECTED]> 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 > > > <[EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]> > > > <mailto:[EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]>>> 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 > > > [email protected] <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>> > > > http://www.iua.upf.es/mtg/clam > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > _______________________________________________ > > > CLAM mailing list > > > [email protected] <mailto:[email protected]> > > > http://www.iua.upf.es/mtg/clam > > > > > >
_______________________________________________ CLAM mailing list [email protected] http://www.iua.upf.es/mtg/clam
