I would like to code an FFT algorithm in C++ to output frequency vs. amplitude in a given (preferably short) time interval. I have managed to extract the data chunks from the WAV file, but I have no clue as to what I should do next.
Since the time between individual samples is the inverse of the sampling rate, should I just use this value as my time interval, or would I get significantly better results if I used an even smaller time interval (while approximating the instantaneous amplitude between two sample points by linear approximation?) Btw, the goal is to achieve a relatively efficient, but most importantly accurate algorithm.
How many samples at a time do I have to analyze to get better results? I would like the time interval of each FFT output to be as small as possible.
Please provide any other suggestions on how to increase accuracy, without causing SIGNIFICANT slowdown. I would also be very greatful if someone could suggest some sites or any other info relevent to this topic.
Full Version: FFT analysis of WAV file data chunks
hi!
1st of all i think you have to decide wether FFT is what you want.
FFT analyses data in a rectangular window.
it "interprets" the data as if the window was repeated in a loop over and over again.
so it's not really made for normal audio data.
this limitation can be overcome, but it takes a bit more than just choosing a good window-size.
next thing is, it makes a difference if you only want to analyze data and display something useful,
or if you want to add some processing steps, maybe change the data in the frequency-domain and do the inverse transform.
if you only want to display something without much processing of the data it should be enough to just cut it into peaces and process.
the size depends on how much resolution in the frequenzy domain you need.
if you make chunks of 1 second each, you'll get 1Hz resolution.
if you make your chunks 1/100 second each, you'll get 100Hz resolution.
if you want to analyze the full audio-spektrum (including bass) you probably need big chunks like 1/10 of a second or larger.
if you want to proccess the data in some way, and need accurate results meaning you don't want to miss anything that might fall onto window bounds, you have to make sure every sample in the processed audio-stream appears in at least 2 chunks. better 3.
one way to do this is to
1) cut the data into chunks of N length.
2) take the first 3 chunks
3) multiply the first chunk with a linear ramp from 0 to 1 (ascending)
4) multiply the third with a linear ramp from 1 to 0 (decending)
5) form a big chunk of 3*N length.
6) FFT' the big chunk
7) do whatever you want with it
8) advance by N samples (not 3*N!) and goto 2)
this is called "windowing" - in this example you would be using a very simple window but that usually don't hurt.
( of course you can always use 5, 7, 9... chunks to form one big chunk (if you require more resolution on the time-axis), but using more than 3 you should use another windowing technique, and things start to get complicated from there :) )
also if you change the data in the frequenzc domain and inverse transform it back, you'll get no audible "clicks" which you usually do get when you use the plain rectangular window.
when you inverse transform the data back to audio-samples, you get 3*N samples again.
to "reconstruct" the original stream, you just have to add the overlapping chunks, that is, the one you "ramped" before the FFT.
you don't have to modify them in any way, because the linear ramps make overlapping chunks that reconstruct the original signal when added together again.
(to get a perfect reconstruction you should use a 0-1 (ascending) ramp for step 4) too, and take x=x-(x*ramp(t)) instead of just x=x*other_ramp(t) - otherwise you'll get slight rounding-errors).
on other thing:
i'd not recommend re-implementing any FFT algorithm, since there are plenty plenty plenty good open-source packages available.
one other thing (if you want maximum accuracy in the frequenzy domain) you could consider is a wavelet analysis.
but this considerably slows things down, since you have to make far much more computations if you need frequency-resolution.
otherwise if you only need the power in every octave (means one ocatve resolution), wavelet analysis can be very fast, many times faster than any FFT approach.
one big plus of wavelets is you can choose your resolution for the frequency AND for the time-axis easily.
so. back to fft.
for 2^n sized windows i always use ooura's FFT package available here:
http://momonga.t.u-tokyo.ac.jp/~ooura/fft.html
if you need other sizes than powers of 2 i can't recommend a FFT package, but there are plenty that work with arbitrary sizes.
i hope this helped at least a little bit,
bye,
--hustbaer
p.S.: you should NOT interpolate the audio-data in any way, since you would lower the precision of the result.
just take 22khz as 22khz and process it.
unless you know exactly what you are doing it makes absolutely no sense to interpolate.
if you must for some reason, you should at least use some simple digital filter but thats a completely different topic.
1st of all i think you have to decide wether FFT is what you want.
FFT analyses data in a rectangular window.
it "interprets" the data as if the window was repeated in a loop over and over again.
so it's not really made for normal audio data.
this limitation can be overcome, but it takes a bit more than just choosing a good window-size.
next thing is, it makes a difference if you only want to analyze data and display something useful,
or if you want to add some processing steps, maybe change the data in the frequency-domain and do the inverse transform.
if you only want to display something without much processing of the data it should be enough to just cut it into peaces and process.
the size depends on how much resolution in the frequenzy domain you need.
if you make chunks of 1 second each, you'll get 1Hz resolution.
if you make your chunks 1/100 second each, you'll get 100Hz resolution.
if you want to analyze the full audio-spektrum (including bass) you probably need big chunks like 1/10 of a second or larger.
if you want to proccess the data in some way, and need accurate results meaning you don't want to miss anything that might fall onto window bounds, you have to make sure every sample in the processed audio-stream appears in at least 2 chunks. better 3.
one way to do this is to
1) cut the data into chunks of N length.
2) take the first 3 chunks
3) multiply the first chunk with a linear ramp from 0 to 1 (ascending)
4) multiply the third with a linear ramp from 1 to 0 (decending)
5) form a big chunk of 3*N length.
6) FFT' the big chunk
7) do whatever you want with it
8) advance by N samples (not 3*N!) and goto 2)
this is called "windowing" - in this example you would be using a very simple window but that usually don't hurt.
( of course you can always use 5, 7, 9... chunks to form one big chunk (if you require more resolution on the time-axis), but using more than 3 you should use another windowing technique, and things start to get complicated from there :) )
also if you change the data in the frequenzc domain and inverse transform it back, you'll get no audible "clicks" which you usually do get when you use the plain rectangular window.
when you inverse transform the data back to audio-samples, you get 3*N samples again.
to "reconstruct" the original stream, you just have to add the overlapping chunks, that is, the one you "ramped" before the FFT.
you don't have to modify them in any way, because the linear ramps make overlapping chunks that reconstruct the original signal when added together again.
(to get a perfect reconstruction you should use a 0-1 (ascending) ramp for step 4) too, and take x=x-(x*ramp(t)) instead of just x=x*other_ramp(t) - otherwise you'll get slight rounding-errors).
on other thing:
i'd not recommend re-implementing any FFT algorithm, since there are plenty plenty plenty good open-source packages available.
one other thing (if you want maximum accuracy in the frequenzy domain) you could consider is a wavelet analysis.
but this considerably slows things down, since you have to make far much more computations if you need frequency-resolution.
otherwise if you only need the power in every octave (means one ocatve resolution), wavelet analysis can be very fast, many times faster than any FFT approach.
one big plus of wavelets is you can choose your resolution for the frequency AND for the time-axis easily.
so. back to fft.
for 2^n sized windows i always use ooura's FFT package available here:
http://momonga.t.u-tokyo.ac.jp/~ooura/fft.html
if you need other sizes than powers of 2 i can't recommend a FFT package, but there are plenty that work with arbitrary sizes.
i hope this helped at least a little bit,
bye,
--hustbaer
p.S.: you should NOT interpolate the audio-data in any way, since you would lower the precision of the result.
just take 22khz as 22khz and process it.
unless you know exactly what you are doing it makes absolutely no sense to interpolate.
if you must for some reason, you should at least use some simple digital filter but thats a completely different topic.
Thank you so much for all of the useful information you posted. Let me be a little bit more specific about what I want to use FFT for (maybe it isn't the best method for this sort of thing.) I wrote a program that calculates how much the pitch of an audio file should be shifted (in cents) to convert it from an initial BPM to a final BPM. What I would like to do is to have the second part of my program shift the pitch of an input audio file by the number of cents that corresponds to the given change in BPM. I initially thought about doing this with FFT like this: convert a small portion of the audio signal into the frequency domain, convert the frequencies to pitch (in cents) and add the constant number (in cents) which was calculated in the first part of the program, then convert pitch back into frequency. This I think should take care of the non-linear relationship between pitch and frequency. Do you think this would work? Is there a better method? The only thing I really want out of the program is so that it shifts the pitch very accurately.
hi again!
i'm pretty sure there exist good working solutions, but if you want to implement it on your own thats fine with me :)
i have absolutely no experience in shifting pitch without changing BPM - or vice versa - changing speed (BPM) without shifting pitch...
if i were to implement such a program and processing time didn't matter much, i'd go for a high-res wavelet analysis.
the wavelet function would be a single sine-wave, masked with some window - one would have to experiment which one works best...
the frequency to start would maybe be about 10 or 15Hz.
for the transform, you just compute the correlation between the signal and the wavelet.
this gives you the "power" of the "frequency in the wavelet" (the frequency of the masked sine-wave) at any point in the input signal.
(*) then you resample the wavelet to a higher frequency, maybe by 1/48 of an octave or so.
compute the next correlation, and repeat (->*).
when you have reached a frequency of ~20khz you can stop.
the result you will have will be many many correlation-signals.
to "reproduce" the original you'd have to start with a zero-output signal.
then you take the first correlation-signal, and start with the first sample X(0).
you add the wavelet multiplied by X(0) to the beginning of the output-signal.
advance by one sample in the correlation signal (->X(1)), add the wavelet multiplied by X(1) to beginning of the output-signal plus one sample.
repeat for all samples, repeat for all correlation-signals (using the properly resamples wavelets).
to reconstruct the signal pitch-shifted, you'd just use a different wavelet.
the length of the wavelet would be the same, but you'd change the frequency by the desired amount.
i don't even know if this would work and if i remembered everything the right way, but if it works is should give a pretty nice result.
however, i expect it to take ages to compute, since the processing power required would be hundrets or thousands or ten-thousends the time of an fft approach.
there should be a nice way to do it by FFT as well, would be much faster, but i still have to "order" it in my mind and "let it think" a while...
it's also hard to explain a topic....
would be something like
* cut into chunks
* remember the difference between the last sample of the current chunk and the first of the next chunk
* output the chunk, repeat samples from the beginning or cut some at the end to reach the desired length
* use FFT/iFFT to phase-shift the next block by an appropriate amount - if you made the first chunk longer by 1/10 then you'd have to shift phase by 36°
* repeat for all blocks
but this would NOT work perfect and only work for very small changes in length.
the limitations apply to your idea of just changing the pitch in the frequency domain.
i think the results might be nearly identical.
i suggest you go for some reading about FFT, windowing techniques and wavelet analysis.
bye,
--hustbaer
i'm pretty sure there exist good working solutions, but if you want to implement it on your own thats fine with me :)
i have absolutely no experience in shifting pitch without changing BPM - or vice versa - changing speed (BPM) without shifting pitch...
if i were to implement such a program and processing time didn't matter much, i'd go for a high-res wavelet analysis.
the wavelet function would be a single sine-wave, masked with some window - one would have to experiment which one works best...
the frequency to start would maybe be about 10 or 15Hz.
for the transform, you just compute the correlation between the signal and the wavelet.
this gives you the "power" of the "frequency in the wavelet" (the frequency of the masked sine-wave) at any point in the input signal.
(*) then you resample the wavelet to a higher frequency, maybe by 1/48 of an octave or so.
compute the next correlation, and repeat (->*).
when you have reached a frequency of ~20khz you can stop.
the result you will have will be many many correlation-signals.
to "reproduce" the original you'd have to start with a zero-output signal.
then you take the first correlation-signal, and start with the first sample X(0).
you add the wavelet multiplied by X(0) to the beginning of the output-signal.
advance by one sample in the correlation signal (->X(1)), add the wavelet multiplied by X(1) to beginning of the output-signal plus one sample.
repeat for all samples, repeat for all correlation-signals (using the properly resamples wavelets).
to reconstruct the signal pitch-shifted, you'd just use a different wavelet.
the length of the wavelet would be the same, but you'd change the frequency by the desired amount.
i don't even know if this would work and if i remembered everything the right way, but if it works is should give a pretty nice result.
however, i expect it to take ages to compute, since the processing power required would be hundrets or thousands or ten-thousends the time of an fft approach.
there should be a nice way to do it by FFT as well, would be much faster, but i still have to "order" it in my mind and "let it think" a while...
it's also hard to explain a topic....
would be something like
* cut into chunks
* remember the difference between the last sample of the current chunk and the first of the next chunk
* output the chunk, repeat samples from the beginning or cut some at the end to reach the desired length
* use FFT/iFFT to phase-shift the next block by an appropriate amount - if you made the first chunk longer by 1/10 then you'd have to shift phase by 36°
* repeat for all blocks
but this would NOT work perfect and only work for very small changes in length.
the limitations apply to your idea of just changing the pitch in the frequency domain.
i think the results might be nearly identical.
i suggest you go for some reading about FFT, windowing techniques and wavelet analysis.
bye,
--hustbaer
QUOTE(RiskyP @ Mar 28 2003 - 03:28 AM)
I would like to code an FFT algorithm in C++ to output frequency vs. amplitude in a given (preferably short) time interval. I have managed to extract the data chunks from the WAV file, but I have no clue as to what I should do next.
Since the time between individual samples is the inverse of the sampling rate, should I just use this value as my time interval, or would I get significantly better results if I used an even smaller time interval (while approximating the instantaneous amplitude between two sample points by linear approximation?) Btw, the goal is to achieve a relatively efficient, but most importantly accurate algorithm.
How many samples at a time do I have to analyze to get better results? I would like the time interval of each FFT output to be as small as possible.
Please provide any other suggestions on how to increase accuracy, without causing SIGNIFICANT slowdown. I would also be very greatful if someone could suggest some sites or any other info relevent to this topic.
Since the time between individual samples is the inverse of the sampling rate, should I just use this value as my time interval, or would I get significantly better results if I used an even smaller time interval (while approximating the instantaneous amplitude between two sample points by linear approximation?) Btw, the goal is to achieve a relatively efficient, but most importantly accurate algorithm.
How many samples at a time do I have to analyze to get better results? I would like the time interval of each FFT output to be as small as possible.
Please provide any other suggestions on how to increase accuracy, without causing SIGNIFICANT slowdown. I would also be very greatful if someone could suggest some sites or any other info relevent to this topic.
1. Figure out how much frequency resolution you need
2. Find the window size which gives you the frequency resolution you need
3. Round up to the nearest power of 2.
Studying the code of Sox will help, since stretching and pitch changing are both included in that program.
SoundTouch Library
Maybe this will help. I have no clue to how it's done here, but the sources are included so it should be possible to figure out.
Maybe this will help. I have no clue to how it's done here, but the sources are included so it should be possible to figure out.
There is also the Pacemaker DSP Winamp plugin, that features its own source code.
But I'm not sure if RiskyP needs time stretching, I understood that he just wanted to apply a pitch shift based on BPM calcuations... in otherword, just a speed change. In this case, a resampling algorithm is needed, no need to perform any conversion into the frequency domain.
But I'm not sure if RiskyP needs time stretching, I understood that he just wanted to apply a pitch shift based on BPM calcuations... in otherword, just a speed change. In this case, a resampling algorithm is needed, no need to perform any conversion into the frequency domain.
Thanks to all who posted. Unfortunately I don't understand very much of the methods that people listed, but that's my fault because I am still only learning FFT by myself and I have no clue really about the DSP applications of it. I'll try to be more specific about what I am really trying to get at.
I want to pitch shift files so that the BPM DOES change. The point of the program would be to convert a file at say, 141.345 BPM to 130.001 BPM or so. There is a formula for calculating how much you have to change the pitch of the entire file (in the unit of cents) to achieve this change in BPM and this is what the first part of my program calculates.
I used this info to pitch-shift a WAV file in Soundforge, but even though it was accurate (about 0.5% deviation from the target BPM) this is not accurate enough for me. The reason is that Soundforge only allows pitch shifting to one decimal place, such as 100.2 cents, but NOT 100.23657 cents. I tried to look for programs that allow me to enter as many decimal places as I want, or at least 3 or 4 decimal places, but I haven't found any. That is really the reason why I would like to make a pitch-shifting part to my program. Is there any program out there that shifts pitch this accurately? Another reason for me writing it is because I would like to learn how to do it. Unfortunately, this has been very hard so far.
Basically, if anyone could point me to a program that lets me adjust (to at least 3 or 4 decimal places) how much I can shift the pitch by IN CENTS, I would be one very happy RiskyP. Otherwise, I guess I will have to try to learn all this DSP stuff you guys are throwing at me (which would actually be the best case scenario if I could) because I don't really understand most of it.
Thanks for the input!
I want to pitch shift files so that the BPM DOES change. The point of the program would be to convert a file at say, 141.345 BPM to 130.001 BPM or so. There is a formula for calculating how much you have to change the pitch of the entire file (in the unit of cents) to achieve this change in BPM and this is what the first part of my program calculates.
I used this info to pitch-shift a WAV file in Soundforge, but even though it was accurate (about 0.5% deviation from the target BPM) this is not accurate enough for me. The reason is that Soundforge only allows pitch shifting to one decimal place, such as 100.2 cents, but NOT 100.23657 cents. I tried to look for programs that allow me to enter as many decimal places as I want, or at least 3 or 4 decimal places, but I haven't found any. That is really the reason why I would like to make a pitch-shifting part to my program. Is there any program out there that shifts pitch this accurately? Another reason for me writing it is because I would like to learn how to do it. Unfortunately, this has been very hard so far.
Basically, if anyone could point me to a program that lets me adjust (to at least 3 or 4 decimal places) how much I can shift the pitch by IN CENTS, I would be one very happy RiskyP. Otherwise, I guess I will have to try to learn all this DSP stuff you guys are throwing at me (which would actually be the best case scenario if I could) because I don't really understand most of it.
Thanks for the input!
After reading a few of the links you guys posted. I found a good analogy to what I want. If my audio file was an LP, I would want to play it slower and record it to a new soundfile. Therefore, the pitch and the BPM have changed. Does this explain it better? The reason for the program in the first place is to convert all of my WAV files to a standard BPM so that I can DJ with them. Hope this helps.
ps.: Soundstretch looks very promissing!!! Thanks!!!
ps.: Soundstretch looks very promissing!!! Thanks!!!
Unfortunately, I don't know how to calculate how much to change the play rate by (in percents) to achieve a given pitch shift. Anyone know?
% change in BPM is same as % change in play rate.
For pitch change, scale factor = 2^(n/12) where n is the change in semi-tones. E.g. for 1 full octave of 12 semitones, 2^(12/12) = 2 so you double the play rate.
For pitch change, scale factor = 2^(n/12) where n is the change in semi-tones. E.g. for 1 full octave of 12 semitones, 2^(12/12) = 2 so you double the play rate.
A more precise way in SoundForge (4.5) is to use the resample tool. The quality of the process is also much better than the pitch shift one.
Divide the sample rate by the factor you need for your BPM change. Example BMP from 100 to 120 -> factor = 1.2. then if the sample rate is 44100 Hz,
44100/1.2=36750 Hz
Click resample, choose quality 4 (highest), antialias (yes if you downsample, no if you upsample), 36750 Hz.
After the process is done, resample again, but this time, check the box "change sample rate only, do not resample" (something like that), and set 44100 Hz. The process is instantly done. You new file now plays at 120 BPM.
If you want to program such a process yourself, have a look at http://groups.yahoo.com/group/eac/message/6445 where I explained what is resampling (the ascii diagrams are messed up; and forget about the dither part)
The http://www.cadenzarecording.com/papers/Filters.pdf paper is about digital filters, and also talks about resampling IIRC. It's more technical, but should be closer to what is done in reality.
The program Samplitude producer 2496 also allows you to synch different track in real time editing. You must first calculate the needed factor, or pitch shift (both can be used). Then you set it for the track (instant process), then you can graphically set the different tracks in synch, dragging the beats of one of them just above or below the beats of another. I use samplitude 6, in which the "track stretching" function unfortunately doesn't allow to stretch a track (with the mouse) while keeping a given beat in synch with another track. Maybe it was enabled in version 7.
If not, we should request it from Magix software, no calculus would be needed anymore : load your 100 BPM below your 120 BPM track, drag the first beat of the second track just below the first beat of the first track, lock it, then stretch, say, then tenth beats together, then the next shifted beats, further in the wavs, etc, until all beats are together.
Samplitude 6 allows to graphically stretch a track with the mouse in real time, which is the most complicated feature we need. Allowing to lock a beat in a given position should be easy for them.
Divide the sample rate by the factor you need for your BPM change. Example BMP from 100 to 120 -> factor = 1.2. then if the sample rate is 44100 Hz,
44100/1.2=36750 Hz
Click resample, choose quality 4 (highest), antialias (yes if you downsample, no if you upsample), 36750 Hz.
After the process is done, resample again, but this time, check the box "change sample rate only, do not resample" (something like that), and set 44100 Hz. The process is instantly done. You new file now plays at 120 BPM.
If you want to program such a process yourself, have a look at http://groups.yahoo.com/group/eac/message/6445 where I explained what is resampling (the ascii diagrams are messed up; and forget about the dither part)
The http://www.cadenzarecording.com/papers/Filters.pdf paper is about digital filters, and also talks about resampling IIRC. It's more technical, but should be closer to what is done in reality.
The program Samplitude producer 2496 also allows you to synch different track in real time editing. You must first calculate the needed factor, or pitch shift (both can be used). Then you set it for the track (instant process), then you can graphically set the different tracks in synch, dragging the beats of one of them just above or below the beats of another. I use samplitude 6, in which the "track stretching" function unfortunately doesn't allow to stretch a track (with the mouse) while keeping a given beat in synch with another track. Maybe it was enabled in version 7.
If not, we should request it from Magix software, no calculus would be needed anymore : load your 100 BPM below your 120 BPM track, drag the first beat of the second track just below the first beat of the first track, lock it, then stretch, say, then tenth beats together, then the next shifted beats, further in the wavs, etc, until all beats are together.
Samplitude 6 allows to graphically stretch a track with the mouse in real time, which is the most complicated feature we need. Allowing to lock a beat in a given position should be easy for them.
Thanks. I will try both methods (resampling and playrate change) and see which gets me better results. Hope it works!
QUOTE(RiskyP @ Mar 31 2003 - 02:41 AM)
If my audio file was an LP, I would want to play it slower and record it to a new soundfile. Therefore, the pitch and the BPM have changed. Does this explain it better?
Yes, perfectly, and as Pio has said you need resampling, and not anything else.
Basically, the speed and the pitch are linked in a digital recording, just as they are on an LP! Play it faster, it speeds up, the pitch increases, and it takes a shorter length of time to play from beginning to end.
The other methods you mention are clever algorithms for breaking the link between speed and pitch - so you can play it faster but maintain the same pitch, or increase the pitch without changing the speed (e.g. make someone talk with a sqeeky voice, but keep them talking at the same speed). These clever processes aren't perfect (though some are very good) - if you can avoid them, do!
Resampling is what you want. This is what I would do in Cool Edit...
Let's say you have a song at 120BPM, and you want to increase it to 130BPM. I'll assume it's ripped from CD, so it has a sampling rate of 44100Hz to start with. That's 44100 digital samples every second.
To make it run at 130BPM, you have to increase the sample rate by whatever fraction 130 is greater than 120. So, the new sample rate is
(130/120)*44100 = 47775
You need to take the exact signal that you already have, and, instead of playing it at 44100 samples per second, play it at 47775 samples per second. Magic - 130BPM.
To do this, DON'T resample to this rate - that will CHANGE the actual samples, whereas you want to keep them the same, but play them faster. To do this, go to Edit > Adjust Sample Rate, and type in the new value - 47775.
That's great - if your soundcard could play 47.775kHz sampled files, we'd be done. But it can't, and you can't burn them to CD either. So, resample it back to 44.1kHz. To do this, go to Edit > Convert Sample Type, and enter 44.1kHz 16-bit stereo, pre/post-filter on, quality 256. This will change the samples themselves, generating new digital samples, which are designed to play back at 44100 samples per second, whilst sounding exactly the same as the 47775 samples per second which you had a moment ago. This sounds clever, but it's actually very basic DSP - and Cool Edit does it very well.
You've now got a CD compatible version at 130BPM, without (much) quality loss.
Hope this helps,
Cheers,
David.
P.S. There's also a dedicated Time Stretcher in Cool Edit Pro which gives you the option of resampling, pitch shifting, or time stretching. It has the advantage of being able to do a gliding resample, which means you can slide the track upwards or downwards in speed between any two BPMs you want - great for mixing.
@RiskyP:
sorry, got you wrong.
i just thought pitch-shifting without changing the playback-rate/sample-rate was the goal.
resampling seemed a little to easy to be true
bye,
--hustbaer
sorry, got you wrong.
i just thought pitch-shifting without changing the playback-rate/sample-rate was the goal.
resampling seemed a little to easy to be true
bye,
--hustbaer
2BDecided's method is exactly the same as mine, but with the two processes performed in a different order. It turns his explanation clearer than mine, because the idea of increasing the sample rate to play faster is more obvious in his explanation.
Thanks guys. The only reason I wanted to use FFT, is because I read somewhere that changing the sampling rate is not very accurate....and also because I am a newbie to DSP. So would you guys would recommend the 'sampling rate method' over the 'play-rate change method?' As far as I can tell, both should be pretty accurate.
On another note, what are the most common applications of FFT is DSP?! I was just wondering.
@hustbaer: no problem man. I really appreciate your input!
On another note, what are the most common applications of FFT is DSP?! I was just wondering.
@hustbaer: no problem man. I really appreciate your input!
I figured I'll post some results:
Using the playrate switch in soundstretch:
Result: 129.999BPM
Desired: 130BPM
Using sampling method:
Result: 129.999BPM
Desired: 130BPM
As you can tell, both got the same result and both are very accurate!!! I am very happy about this so thanks to all! I noticed though that using soundstretch is much faster than the resampling method. Any reason why NOT to use soundstrech instead?!
Using the playrate switch in soundstretch:
Result: 129.999BPM
Desired: 130BPM
Using sampling method:
Result: 129.999BPM
Desired: 130BPM
As you can tell, both got the same result and both are very accurate!!! I am very happy about this so thanks to all! I noticed though that using soundstretch is much faster than the resampling method. Any reason why NOT to use soundstrech instead?!
The time taken to perform the process is related to the sound quality of the result. For example, in SoundForge 4.5, the resample process can be done at quality 1 to 4. Quality 1 is much faster. It sounds like the original, but listening carefully, you can hear that the sound quality has decreased. Quality 4 is quite undistiguishable from the original, even for audiophiles (until you reset the sample rate, that changes the playback speed, of course). There are some very fast and basic resample algorithms that litterally add a noise over the music.
Mathematically, the most obvious use of DFT (Discrete Fourier Transform, of which FFT, Fast Fourier Transform is a software implementation) is equalizing (bass/treble settings). In practice, bass and treble settings are done with IIR, or FIR filters. But one can show that a FIR or an IIR filter is a mathematical equivalent of a DFT process (and back), with some given parameters.
Mathematically, the most obvious use of DFT (Discrete Fourier Transform, of which FFT, Fast Fourier Transform is a software implementation) is equalizing (bass/treble settings). In practice, bass and treble settings are done with IIR, or FIR filters. But one can show that a FIR or an IIR filter is a mathematical equivalent of a DFT process (and back), with some given parameters.
@RiskyP
You've already found a solution for your problem, but if you are still interested in DSP programming or FFT's applications in DSP, I would recommend you to browse through http://www.dspguide.com.
It contains the whole book "The Scientist And Engineer's Guide To Digital Signal Processing" in PDF format and it's freely readable. Excellent nighttime reading
You've already found a solution for your problem, but if you are still interested in DSP programming or FFT's applications in DSP, I would recommend you to browse through http://www.dspguide.com.
It contains the whole book "The Scientist And Engineer's Guide To Digital Signal Processing" in PDF format and it's freely readable. Excellent nighttime reading
large linear convolutions are often calculated via FFT.
takes much less time than computing the convolution "straight-forward".
ideally O(n*log(n)) as compared to O(n^2)
bye,
--hustbaer
takes much less time than computing the convolution "straight-forward".
ideally O(n*log(n)) as compared to O(n^2)
bye,
--hustbaer
Here's one about the WAV file format: the data chunk contains 2 byte samples which are represented as 2's complement integers ranging from -32K to 32K approx. What are the units?! If I FFT a chunk of a signal, the resulting spectrum displays energy vs. frequency... what are the units of energy in this case?
QUOTE(hustbaer @ Mar 28 2003 - 12:32 PM)
hi!
one other thing (if you want maximum accuracy in the frequenzy domain) you could consider is a wavelet analysis.
but this considerably slows things down, since you have to make far much more computations if you need frequency-resolution.
otherwise if you only need the power in every octave (means one ocatve resolution), wavelet analysis can be very fast, many times faster than any FFT approach.
one big plus of wavelets is you can choose your resolution for the frequency AND for the time-axis easily.
one other thing (if you want maximum accuracy in the frequenzy domain) you could consider is a wavelet analysis.
but this considerably slows things down, since you have to make far much more computations if you need frequency-resolution.
otherwise if you only need the power in every octave (means one ocatve resolution), wavelet analysis can be very fast, many times faster than any FFT approach.
one big plus of wavelets is you can choose your resolution for the frequency AND for the time-axis easily.
(I know that this is going off-topic, but the post was interesting.
)After having read various wavelet tutorials, I'm not sure your method would be the best/most accurate. I've put a little thought into this, but I could possibly be wrong here/speaking out of my ass, so...
My idea was to couple the inverse discrete wavelet transform to the continuous wavelet transform of the input source. It seems to me that this method would allow either pitch or time scaling or both, depending on how you sampled from the CWT. I just don't know how practical this method is. Either way, here you'd go from the time-domain to the wavelet-domain with the CWT and back to the time-domain more-or-less directly with the IDWT. Or is this not practical?
QUOTE(RiskyP @ Apr 2 2003 - 12:50 AM)
Here's one about the WAV file format: the data chunk contains 2 byte samples which are represented as 2's complement integers ranging from -32K to 32K approx. What are the units?! If I FFT a chunk of a signal, the resulting spectrum displays energy vs. frequency... what are the units of energy in this case?
There are no units. Though you can calculate the frequency represented by each FFT bin. But...
Read a good book about DSP before you go any further. You've been discussing some advanced stuff, but you haven't looked at the basics yet - that's a sure way of geting confused and frustrated!
Cheers,
David.
David,
I will start reading a good book on DSP as soon as I can, but regarding your answer... I have a hard time believing that there are NO units. Where do the dB conversions come from then? When the audio file I am listening to was recorded, the movement of a microphone diaphragm 'traced' the analog waveform by means of positive and negative voltage fluctuations...right? So then the unamplified waveform should be in volts shouldn't it? I might be very wrong, but wouldn't it make sense that as a CD player reads the instantaneous sample height, it reconstructs - more or less - the initial analog wave with similar voltage fluctuations as were recorded by the microphone? I mean, the only differnce between the digital data and the analog waveform is that one is discrete and the other continuous. Why would digital loose the units?!
I will start reading a good book on DSP as soon as I can, but regarding your answer... I have a hard time believing that there are NO units. Where do the dB conversions come from then? When the audio file I am listening to was recorded, the movement of a microphone diaphragm 'traced' the analog waveform by means of positive and negative voltage fluctuations...right? So then the unamplified waveform should be in volts shouldn't it? I might be very wrong, but wouldn't it make sense that as a CD player reads the instantaneous sample height, it reconstructs - more or less - the initial analog wave with similar voltage fluctuations as were recorded by the microphone? I mean, the only differnce between the digital data and the analog waveform is that one is discrete and the other continuous. Why would digital loose the units?!
@RiskyP:
the "digitized waveform" has no unit.
it's just a sequence of numbers.
when you use the waveform to produce an analog output, like when you play it through a sound-card,
you interpret the sequence of numbers, in this case, as Volts.
however, you could also interpret the sequence of numbers as relative pressure, unit would be Pascal.
or as acceleration, then the unit would be m/sē.
all these interpretations are afaik valid and equal when you look at a classic system with a soundcard (optionally an amplifier), a classic "voicecoil & menbrane" loudspeaker and some air to play into.
but this does not mean the "sequence of numbers" (that we call waveform) has a unit.
one could reproduce the sound without ever producing any analog signal that is related to the numbers.
this would be a little tricky, but there should be several ways.
bye,
--hustbaer
the "digitized waveform" has no unit.
it's just a sequence of numbers.
when you use the waveform to produce an analog output, like when you play it through a sound-card,
you interpret the sequence of numbers, in this case, as Volts.
however, you could also interpret the sequence of numbers as relative pressure, unit would be Pascal.
or as acceleration, then the unit would be m/sē.
all these interpretations are afaik valid and equal when you look at a classic system with a soundcard (optionally an amplifier), a classic "voicecoil & menbrane" loudspeaker and some air to play into.
but this does not mean the "sequence of numbers" (that we call waveform) has a unit.
one could reproduce the sound without ever producing any analog signal that is related to the numbers.
this would be a little tricky, but there should be several ways.
bye,
--hustbaer
Ok, thank you... this makes sense. I'm glad you guys are so helpful.
As for reproducing the sound without any analog signal... this sounds very interesting, any links?!
As for reproducing the sound without any analog signal... this sounds very interesting, any links?!
The ADC is calibrated so that the highest level equals a given voltage, say Vmax.
The recorded numbers are the voltage V divided by the voltage reference Vmax, times 2^15.
The unit is then volt/volt = pure number.
The recorded numbers are the voltage V divided by the voltage reference Vmax, times 2^15.
The unit is then volt/volt = pure number.
...so there is no way of knowing Vmax?! I mean, is it a standard? Or does it vary from recording to recording?
oh boy!
Vmax...
i'm not absolutely sure that i understand the question, but i'll try...
well, lets start from scratch.
you have some digital audio.
the digital audio is stored as a sequence of numbers, ranging from -(2^(n-1)) to (2^(n-1)-1) - where n is the number of bits/sample.
so.
the DAC will output it's highest voltage, when the highest number is put in, right?
to keep it simple let's call the highest number (the (2^(n-1)-1) thing) "1" - means lets "normalize" the numbers.
if the digital signal uses the full dynamic range available, means if the highest number in the sequence is "1" or the lowest number is "-1", then the output voltage will the value the DAC is set to.
usually the final output of a soundcard or cd-player will be between 1Veff and 2Veff.
the so called "line level" is 1Veff (if i'm not mistaken).
means 1,414Vpeak or 2,828Vpeak-to-peak.
so IF your soundcard/cd-player/whatever is designed to output 1Veff, and IF the digital signal is not attenuated, then the output will be 1Veff.
simple as that.
if you want to know which voltage you'll get for a specific number "X" as input to the DAC, it's just as simple.
if:
n is the number of bits/sample and
X is a number in the range from -(2^(n-1)) to (2^(n-1)-1) and
Vmax is the highest voltage the DAC+analog-output-stage (including filters, buffers, line-driver etc.) will produce and
there is no volume control (like the volume control of every soundcard), then...
...
the output voltage Vout will be:
Vout=Vmax*X/(2^(n-1))
but since Vmax is not constant for every DAC+output-stage - you really can't tell unless you have further specs.
and finally, all this is only true for DC-coupled circuits.
most soundcards and even some cd-players have a highpass-filter in the output-stage, so they will cut the DC-component...
so far, so good.
when recording there are several standards, but it's really absolutels no use knowing was the original Vmax was.
the way things are usually interpreted is:
you have some digital recording.
the largest possible sample-value being N.
for 16 bit recordings this would be (-32768) but since we want a positive number we'll take +32768, even though +32767 is the highest possible number.
so N=32768.
then we define "0 decibel" as the volume of the loudest possible sine-wave that does not clip - or in other words, a sine-wave that has an amplitude of N.
then we have a useable standard definition of "volume".
then we look at the average volume of the recording, let's just define this as the "loudest" volume (or amplitude) that is not exceeded for at least 70% of the recording.
to interpret this volume easily you put it in the "0 decibel" system again, so if this amplitude is 1/2 N you'd call it "-6 decibel".
usual values range from -14 decibel to -6 decibel.
the older the recording the lower the number.
the more "mainstream-radio-pop" the higher the number.
the higher the number the less dynamic range is available, and vice versa.
but these are no "standards", just guide values.
and usually that's all one needs to know.
bye,
--hustbaer
Vmax...
i'm not absolutely sure that i understand the question, but i'll try...
well, lets start from scratch.
you have some digital audio.
the digital audio is stored as a sequence of numbers, ranging from -(2^(n-1)) to (2^(n-1)-1) - where n is the number of bits/sample.
so.
the DAC will output it's highest voltage, when the highest number is put in, right?
to keep it simple let's call the highest number (the (2^(n-1)-1) thing) "1" - means lets "normalize" the numbers.
if the digital signal uses the full dynamic range available, means if the highest number in the sequence is "1" or the lowest number is "-1", then the output voltage will the value the DAC is set to.
usually the final output of a soundcard or cd-player will be between 1Veff and 2Veff.
the so called "line level" is 1Veff (if i'm not mistaken).
means 1,414Vpeak or 2,828Vpeak-to-peak.
so IF your soundcard/cd-player/whatever is designed to output 1Veff, and IF the digital signal is not attenuated, then the output will be 1Veff.
simple as that.
if you want to know which voltage you'll get for a specific number "X" as input to the DAC, it's just as simple.
if:
n is the number of bits/sample and
X is a number in the range from -(2^(n-1)) to (2^(n-1)-1) and
Vmax is the highest voltage the DAC+analog-output-stage (including filters, buffers, line-driver etc.) will produce and
there is no volume control (like the volume control of every soundcard), then...
...
the output voltage Vout will be:
Vout=Vmax*X/(2^(n-1))
but since Vmax is not constant for every DAC+output-stage - you really can't tell unless you have further specs.
and finally, all this is only true for DC-coupled circuits.
most soundcards and even some cd-players have a highpass-filter in the output-stage, so they will cut the DC-component...
so far, so good.
when recording there are several standards, but it's really absolutels no use knowing was the original Vmax was.
the way things are usually interpreted is:
you have some digital recording.
the largest possible sample-value being N.
for 16 bit recordings this would be (-32768) but since we want a positive number we'll take +32768, even though +32767 is the highest possible number.
so N=32768.
then we define "0 decibel" as the volume of the loudest possible sine-wave that does not clip - or in other words, a sine-wave that has an amplitude of N.
then we have a useable standard definition of "volume".
then we look at the average volume of the recording, let's just define this as the "loudest" volume (or amplitude) that is not exceeded for at least 70% of the recording.
to interpret this volume easily you put it in the "0 decibel" system again, so if this amplitude is 1/2 N you'd call it "-6 decibel".
usual values range from -14 decibel to -6 decibel.
the older the recording the lower the number.
the more "mainstream-radio-pop" the higher the number.
the higher the number the less dynamic range is available, and vice versa.
but these are no "standards", just guide values.
and usually that's all one needs to know.
bye,
--hustbaer
The reason there's no fixed relationship between the sound pressure in the recording room, the voltage output by the microphone, the numbers generated by the ADC, the voltage generated by the DAC, the voltage generated by the amp and sent to the speakers, and the sound presure in the listening room is because...
different microphones have different sensitivity - same sound pressure gives a different voltage.
The mixing desk allows you to change the loudness, and hence voltage (that's what all the faders are for!)
ADCs have different Vmax
DACs have different Vmas
Amplifiers have (wait for it...) volume controls! So you can change the loudness, and hence the voltage!
different speakers have different sensitivity - same voltage gives different sound pressure
You can calibrate all this - and if this is done, you can talk about "dB SPL" (that's the sound pressure level, expressed in decibels) of the digital data, because you know how it will come out as sound. Twiddle the volume control, and the calibration is lost - so this is meaningless for all home environments.
See
http://replaygain.hydrogenaudio.org//calibration.html
for more.
Cheers,
DAvid.
P.S. dBs tell you have much larger or smaller one number is from another (usually unstated, but understood) number.
different microphones have different sensitivity - same sound pressure gives a different voltage.
The mixing desk allows you to change the loudness, and hence voltage (that's what all the faders are for!)
ADCs have different Vmax
DACs have different Vmas
Amplifiers have (wait for it...) volume controls! So you can change the loudness, and hence the voltage!
different speakers have different sensitivity - same voltage gives different sound pressure
You can calibrate all this - and if this is done, you can talk about "dB SPL" (that's the sound pressure level, expressed in decibels) of the digital data, because you know how it will come out as sound. Twiddle the volume control, and the calibration is lost - so this is meaningless for all home environments.
See
http://replaygain.hydrogenaudio.org//calibration.html
for more.
Cheers,
DAvid.
P.S. dBs tell you have much larger or smaller one number is from another (usually unstated, but understood) number.
Thanks everyone... this was very informative. I am glad I decided to post on HA.
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.