sorry, dropped a phrase by accident: shouldn't be too hard -- to use --.
On Sat, 6 Oct 2018 at 22:14, Scott Cotton wrote:
> The best open source one I know of is
> https://breakfastquay.com/rubberband/
>
> It is however very dense. I wouldn't bet on coming to an understanding of
> how it does
The best open source one I know of is https://breakfastquay.com/rubberband/
It is however very dense. I wouldn't bet on coming to an understanding of
how it does sample/window framing without significant investment. The
author himself said it was very hard to get sample accurate input samples
Could you know where I can find phase vocoder implementaion in cpp thus I
can run it on real time ?
בתאריך שבת, 6 באוק׳ 2018 ב-21:21 מאת Daniel Varela <
danielvarela...@gmail.com>:
> For real time you will need to do windowing and overlap add. But yeah, 5ms
> should be enough.
>
> This
You can "freeze" audio with the phase vocoder "for ever" if that ist
what you want to do.
You just keep the magnitude of the spectrum from one point in time and
keep it
and update the phases with the phase differences of that moment.
Am 06.10.2018 um 20:02 schrieb Alex Dashevski:
Hi,
Hi,
phase vocoder doesn't have restriction of duration ?
Thanks,
Alex
בתאריך שבת, 6 באוק׳ 2018 ב-20:55 מאת Daniel Varela <
danielvarela...@gmail.com>:
> You could try a phase vocoder instead of WSOLA for time stretching.
> Latency would be the size of the fft block.
>
> El sáb., 6 oct.
You could try a phase vocoder instead of WSOLA for time stretching. Latency
would be the size of the fft block.
El sáb., 6 oct. 2018 19:49, gm escribió:
>
> right
>
> the latency required is that you need to store the complete wavecycle, or
> two of them, to compare them
>
> (My method works a
right
the latency required is that you need to store the complete wavecycle,
or two of them, to compare them
(My method works a little bit different, so I only need one wavecycle.)
So you always have this latency, regardless what sample rate you use.
But maybe you dont need 20 Hz, for
Alex, it sounds like you are confusing algorithmic latency with framing
latency. At each frame, you take in 10ms (or whatever) of input, and then
provide 10ms of output. This (plus processing time to generate the output) is
the IO latency of the process. But the algorithm itself can add
If I understand correctly, resampling will not help. Right ?
No other technique that will help. Right ?
What do you mean "but not the duration/latency required" ?
בתאריך שבת, 6 באוק׳ 2018 ב-20:29 מאת gm <g...@voxangelica.net>:
>
>
> Am 06.10.2018 um 19:07 schrieb Alex Dashevski:
> > What
Am 06.10.2018 um 19:07 schrieb Alex Dashevski:
What do you mean "replay" ? duplicate buffer ?
I mean to just read the buffer for the output.
So in my example you play back 10 ms audio (windowed of course), then
you move your read pointer and play
that audio back again, and so on, untill
What do you mean "replay" ? duplicate buffer ?
I have the opposite problem. My original buffer size doesn't contain full
cycle of the pitch.
How can I succeed to shift pitch ?
Thanks,
Alex
בתאריך שבת, 6 באוק׳ 2018 ב-19:55 מאת gm <g...@voxangelica.net>:
>
> no, you don't change the
no, you don't change the buffer size, you just change the playback rate
(and speed, if you want) of your grains.
For instance, lets say the pitch is 20 Hz, or 50 ms time for one cycle.
You want to change that to 100 Hz.
Then you take 50 ms of audio, and replay this 5 times every 10 ms (with
I still don't understand. You change buffer size. Right ?
But I don't want to change.
בתאריך שבת, 6 באוק׳ 2018 ב-19:11 מאת gm <g...@voxangelica.net>:
>
> In my example, the buffer is 2 times as long as the lowest possible pitch,
> for example if your lowest pitch is 20 Hz, you need 50 ms
In my example, the buffer is 2 times as long as the lowest possible pitch,
for example if your lowest pitch is 20 Hz, you need 50 ms for one wave cycle
Think of it as magnetic tape, without sample rate, the minimum requierd
latency and the buffer length in milliesconds
are independent of
Hi,
I can't understand your answer. The duration of buffer should be bigger
than duration of pitch because I use WSOLA.
The latency also depends on sample rate and buffer length.
Thanks,
Alex
בתאריך שבת, 6 באוק׳ 2018 ב-18:26 מאת gm <g...@voxangelica.net>:
> Your numbers don't make
Your numbers don't make sense to me but probably I just dont understand it.
The latency should be independent of the sample rate, right?
You search for similarity in the wave, chop it up, and replay the grains
at different speeds and/or rates.
What you need for this is a certain amount of
I have project with pitch shifting (resampling with wsola), It implements
on android NDK.
Since duration of pitch is ~20ms, I can't use system recommended
parameters for the fast path. for example, for my device: SampleRate:48Khz
and buffer size 240 samples. That means, duration time is 5ms (<
You've got it backwards -- downsample means fewer samples. If you have a
240-sample buffer at 48kHz, then resample to 8kHz, you'll have 240/6=40
samples.
-Ethan
On Sat, Oct 6, 2018 at 4:10 AM, Alex Dashevski wrote:
> Hi,
> Let's assume that my system has sample rate = 48Khz and audio buffer
Hi,
Let's assume that my system has sample rate = 48Khz and audio buffer size =
240 samples. It should be on RealTime.
Can I do that:
1. Dowsampe to 8Khz and buffer size should be 240*6
2. To do proccessing on buffer 240*6 with 8Khz sample rate.
3. Upsample to 48khz with original buffer size.
19 matches
Mail list logo
