C++ Simple Pitch Shift

Hey,
My name is Owen and I am currently working on a project for my University
Degree. I am a complete newbie to the world of DSP. I am basically looking
for *basic* algorithms (or as basic as possible) for simple pitch shifting

and time shifting. I'm not overly fussed with having the best possible
sound, I just generally need help with where to begin coding for a time
and pitch shifter. The signal processing will be applied to a single voice
only, so no orchestra/drums and other such things which can cause issues
with pitch and time shifting.

If anyone knows of any links for either basic C++ code or algorithms of
how to create such effects then that would be greatly appreciated.

Thank you in advance,
Owen (OJB)

OJB wrote:

   ...

> If anyone knows of any links for either basic C++ code or algorithms of
> how to create such effects then that would be greatly appreciated.

Try these:
Pitch: http://www.dspdimension.com/
Rate: http://www.mega-nerd.com/SRC/

Jerry
-- 
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������

OJB wrote:
> Hey,
> My name is Owen and I am currently working on a project for my University
> Degree. I am a complete newbie to the world of DSP. I am basically looking
> for *basic* algorithms (or as basic as possible) for simple pitch shifting
> 
> and time shifting. I'm not overly fussed with having the best possible
> sound, I just generally need help with where to begin coding for a time
> and pitch shifter. The signal processing will be applied to a single voice
> only, so no orchestra/drums and other such things which can cause issues
> with pitch and time shifting.
> 

Use ring buffer. Write at constant "speed" but read faster or slower than
you write. If you read faster pitch goes up and if you read slower pitch
goes down. Sound quality is pretty horrible due to the phase
discontinuities (i.e. phases don't match when read and write passes each
other) but it works. The length of the ring buffer is crucial parameter for
satisfactory results.

-- 
Jani Huhtanen
Tampere University of Technology, Pori

>Hey,
>My name is Owen and I am currently working on a project for my
University
>Degree. I am a complete newbie to the world of DSP. I am basically
looking
>for *basic* algorithms (or as basic as possible) for simple pitch
shifting
>
>and time shifting. I'm not overly fussed with having the best possible
>sound, I just generally need help with where to begin coding for a time
>and pitch shifter. The signal processing will be applied to a single
voice
>only, so no orchestra/drums and other such things which can cause issues
>with pitch and time shifting.
>
>If anyone knows of any links for either basic C++ code or algorithms of
>how to create such effects then that would be greatly appreciated.
>
>Thank you in advance,
>Owen (OJB)
>
>
>

Try this one :)
http://www.surina.net/soundtouch/

Jani Huhtanen wrote:
> OJB wrote:
> > Hey,
> > My name is Owen and I am currently working on a project for my University
> > Degree. I am a complete newbie to the world of DSP. I am basically looking
> > for *basic* algorithms (or as basic as possible) for simple pitch shifting
> >
> > and time shifting. I'm not overly fussed with having the best possible
> > sound, I just generally need help with where to begin coding for a time
> > and pitch shifter. The signal processing will be applied to a single voice
> > only, so no orchestra/drums and other such things which can cause issues
> > with pitch and time shifting.

Is it a singing voice?  Do you know the key and base pitch?  Is the
singer singing on key?  If so, try using several ring buffers as per
below, one of proper length for each note in the key, and continuously
select the one with the least phase discontinuity at the wrapping
point.

> Use ring buffer. Write at constant "speed" but read faster or slower than
> you write. If you read faster pitch goes up and if you read slower pitch
> goes down. Sound quality is pretty horrible due to the phase
> discontinuities (i.e. phases don't match when read and write passes each
> other) but it works. The length of the ring buffer is crucial parameter for
> satisfactory results.


IMHO. YMMV.
-- 
rhn A.T nicholson d.0.t C-o-M

Jani Huhtanen wrote:
>
> Use ring buffer. Write at constant "speed" but read faster or slower than
> you write. If you read faster pitch goes up and if you read slower pitch
> goes down. Sound quality is pretty horrible due to the phase
> discontinuities (i.e. phases don't match when read and write passes each
> other) but it works. The length of the ring buffer is crucial parameter for
> satisfactory results.

toss in a little bit of "pitch detection" (look up AMDF for "Average
Magnitude Difference Function" on Google) and the splice in or out
exactly one or two whole periods of the waveform.  when you splice,
crossfade from the old to the new.  that will improve  the sound a lot.

r b-j

I once implemented a pitch-shifter with the ring buffer as described by
Jani. If I remember correctly (this was a looonnngggg time ago) I used
a cross-fade to gloss over the points where the read and write pointers
crossed each other, which was an improvement. I've always wondered
since then whether a better windowing scheme such as a hamming window
would have improved things.

Any comments?

Cheers,

Ross-c

Ross Clement (Email address invalid - do not use) wrote:
> I once implemented a pitch-shifter with the ring buffer as described by
> Jani. If I remember correctly (this was a looonnngggg time ago) I used
> a cross-fade to gloss over the points where the read and write pointers
> crossed each other, which was an improvement. I've always wondered
> since then whether a better windowing scheme such as a hamming window
> would have improved things.
>
> Any comments?

it's not a bad idea to think of the window functions as the
concatination of a fade-up and fade-down functions.  the hann window is
not bad for crossfading, but the Hamming is not so good
(discontinuity).

r b-j

robert bristow-johnson wrote:
> Ross Clement (Email address invalid - do not use) wrote:
> 
>>I once implemented a pitch-shifter with the ring buffer as described by
>>Jani. If I remember correctly (this was a looonnngggg time ago) I used
>>a cross-fade to gloss over the points where the read and write pointers
>>crossed each other, which was an improvement. I've always wondered
>>since then whether a better windowing scheme such as a hamming window
>>would have improved things.
>>
>>Any comments?
> 
> 
> it's not a bad idea to think of the window functions as the
> concatination of a fade-up and fade-down functions.  the hann window is
> not bad for crossfading, but the Hamming is not so good
> (discontinuity).

The Hann window is a raised cosine. It's performance is good, but not 
outstanding; other, better windows use more terms. Hats off to Nuttall, 
Blackman, Harris, Kaiser, and others. But before (he knew) their work, 
Hamming had a problem with a Hann window's first sidelobe. He determined 
empirically that 92% Hann and 8% rectangular knocked the first sidelobe 
down as far as it would go without raising any of the others above it.

Hamming was smart. He knew not only how to get the job done, but also 
when to quit. His window is probably not optimum for much (if anything) 
but it's good enough for the particular class of problems he dealt with. 
That said, it's an empirical kludge, more like what I would do than what 
we expect from people who get remembered. Hamming is remembered for many 
things besides his window.

Despite it's relatively poor sidelobe performance, a Hann window has a 
property it shares only with Bartlett (triangular) and rectangular 
windows: when overlapped 50%, the sum is uniform. That property 
recommends it for certain applications (NOT fast convolution).

Jerry
-- 
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������

Jerry Avins wrote:
> The Hann window is a raised cosine. It's performance is good, but not
> outstanding; other, better windows use more terms. Hats off to Nuttall,
> Blackman, Harris, Kaiser, and others. But before (he knew) their work,
> Hamming had a problem with a Hann window's first sidelobe. He determined
> empirically that 92% Hann and 8% rectangular knocked the first sidelobe
> down as far as it would go without raising any of the others above it.
>
> Hamming was smart. He knew not only how to get the job done, but also
> when to quit. His window is probably not optimum for much (if anything)
> but it's good enough for the particular class of problems he dealt with.
> That said, it's an empirical kludge, more like what I would do than what
> we expect from people who get remembered. Hamming is remembered for many
> things besides his window.
>
> Despite it's relatively poor sidelobe performance, a Hann window has
> a property it shares only with Bartlett (triangular) and rectangular
> windows: when overlapped 50%, the sum is uniform. That property
> recommends it for certain applications (NOT fast convolution).

Because the Hamming window is the sum of a Hann window and a
rectangular window, it also share's this property of a uniform sum
when overlapped 50%


IMHO. YMMV.
-- 
rhn A.T nicholson d.0.t C-o-M