2
$\begingroup$

I'm applying at each 2048 samples the pitch synchronous algorithm to pitch scale some audio files, everything seems to occur well, but I've noticed some glitches, artifacts, clicks between every boundary frame!

I'm testing off-line in large áudio files(I'm processing frame-by-frame), what I tried to do was keep the old, current and the next frame to pitch synchronous computation (then I pitch scale 2048*3 samples), but does not seem to be working as expected.

What are the known ways to eliminate frame boundary discontinuity?

Improve this question
$\endgroup$
7
  • $\begingroup$ i probably should ask, by "pitch scale some audio files", do you mean you are pitch shifting this audio? and are you using some FFT-based method like the phase vocoder? if so, there could be another reason for the glitch artifacts. $\endgroup$
    – robert bristow-johnson
    May 18, 2014 at 2:46
  • $\begingroup$ yeah I am pitch shifting this audio, I using just time domain methods for both (pitch track and Pitch shift) .. $\endgroup$
    – user2721828
    May 18, 2014 at 11:59
  • $\begingroup$ how are you "pitch track[ing]"? something related to autocorrelation? well, then, if your sample rate is 44.1 kHz, then you probably need to be freshly determining the period length more often than 2048 samples. perhaps every 512 samples. i presume you're splicing in extra whole periods upshifting and splicing out whole periods when downshifting, right? are you cross-fading these splices? $\endgroup$
    – robert bristow-johnson
    May 18, 2014 at 13:11
  • $\begingroup$ yeah exactly in all points pitch track is autocorrelation based, I not cross-fade, i just concatenate each processed frame ... $\endgroup$
    – user2721828
    May 18, 2014 at 14:12
  • $\begingroup$ "... i just concatenate each processed frame." <--> and you're wondering why you're getting some glitches or pops? $\endgroup$
    – robert bristow-johnson
    May 18, 2014 at 17:58

1 Answer 1

Reset to default
1
$\begingroup$

Windowing is the first line of defense. you may need the windowing to be complementary, which is that all window functions (at their various frame delays) add to 1. the Hann window is an example. the Hamming window (which might have better sidelobe behavior than the Hann) is sorta complementary, but it adds to 1.08 (just a simple scaling issue).

if your window use is only for analysis (and not for synthesis) you might not need it to be complementary, so you could use a Kaiser window or a Gaussian window, both which have some useful mathematical properties in analysis.

the second line of defense is to use your 2048-sample as just buffers and space your frames (and the analysis windows that come with), by the detected period and adaptively advance the frame locations by a period each frame process. that's a little weirder because you need to have, a priori, some knowledge of the period which what your pitch synchronicity is all about.

the most weirdest line of defense, is to advance each frame by a well-chosen "random" value between $L$ and $2L$ (where $2L$ is longer than the longest anticipated period) to scramble up whatever effect of the boundary discontinuity.

as we might say on comp.dsp, "you'll have to pay for more information".

Improve this answer
$\endgroup$
1
  • $\begingroup$ I used a hamming window into the frame (and not occur artifacts inside each frame), maybe if I apply a windowing (hann, hamming, etc) between the frames the glitches can disappear .... $\endgroup$
    – user2721828
    May 18, 2014 at 12:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.