Re: Extract data from AIFF file to compute FFT
Re: Extract data from AIFF file to compute FFT
- Subject: Re: Extract data from AIFF file to compute FFT
- From: "Francois Baronnet" <email@hidden>
- Date: Tue, 5 Aug 2008 08:02:04 +0200
Hi all (on all branch of this thread),
As Mikael said, there was 3 questions in my question. But thanks to
you all, I now have my answers.
I definitly wasn't aware of such difficulties when I first started my project.
But it's very very interesting and I hope keeping enough motivation to
implements all theses algorithms.
First goal: zero crossing and wave period :)
Thanks again for your time.
2008/8/4 tahome izwah <email@hidden>:
> 2008/8/4 Brian Willoughby <email@hidden>:
>> Your hunch about AIFF versus FFT is well-founded. AIFF has 16-bit or 24-bit
>> fixed point numbers packed (i.e. 2 or 3 bytes each sample) into the sound
>> data chunk, and that chunk does not always appear at a predictable location
>> in the file. The FFT requires floating point numbers, usually 32-bit (4
>> bytes).
>
> There are fixed point FFTs as well.
>
>> I'm not sure what you mean by (with main_frequency = FFT(some_datas[]); )...
>> An FFT does not produce a single result, such as a "main frequency." An FFT
>> produces, usually, 1024 complex results, meaning 2048 values.
>
> That depends on the transform frame size. 1024 is an arbitrary number,
> usually this number can be anything that is a 2^n number.
>
>> Each result
>> corresponds to a different frequency bin. Even if you do an FFT, you still
>> have to interpret the thousands of results and use some kind of non-trivial
>> algorithm to map the FFT results to tell the user they are 'In tune' or
>> 'sharp' or 'flat' - either for one string at a time, or possibly for all
>> strings at once if you're clever. Using an FFT does not necessarily make
>> this any easier.
>
> Yes.
>
>> Basically, a 1024-point FFT is equivalent to multiplying the input signal by
>> 1024 different sine waves, each at a different frequency division.
>
> No. It's a mutiply-accumulate, not just a multiply. You could also
> call it a correlation between the input signal and a sinusoid at a
> given frequency (multiple of sample rate/N, N being the transform
> size).
>
>> You would be better off calculating a precise 440 Hz sine wave into a
>> working buffer, and then using math similar to an FFT, but much faster, to
>> compare your input to that frequency. In other words, instead of
>> calculating 1024 results, you would calculate only one complex result.
>
> Look for the Goertzel algorithm, this is the name of the DSP process
> that does this.
>
>> Simpler tuning algorithms just look for zero transitions and measure the
>> period of the waveform. Such an algorithm is susceptible to overtones which
>> cause false triggering at the octave frequency, especially with strings
>> where the first harmonic can be stronger than the fundamental.
>
> Peak-picking the FFT output would be susceptible to the same effect. I
> recommend you look for autocorrelation based methods, they are usually
> the method of choice for this particular application (in the musically
> monophonic case, that is). Rabiner and Schafer "Digital Processing of
> Speech Signals" would be a good starting point.
>
> HTH,
> --th
>
--
François Baronnet
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden