In article
<Pine.LNX.4.44.0805082122050.18719-100000@[EMAIL PROTECTED]
>,
Beta Zero <beta_zero@[EMAIL PROTECTED]
> wrote:
> >> For example, let's say I have a large number of .WAV files in the
> >> harddrive I'm looking at, is there any easy way for me to extract the
> >> major frequencies from them, assuming I also specify an estimated
> >> sample rate, a particular playback rate, and the depths into the file
> >> I am examining? (This would be the first step toward creating
> >> sound envelopes for them. I think.)
> >>
> >> Or has somebody already done that, and it's already available as a
'C'
> >> program?
>
> Tom Harrington <tph@[EMAIL PROTECTED]
> wrote:
> >Err, sure it's possible.
>
> It's not that hard for the Atari ST, just time consuming, and I have
> other things to do with my life. But now that I have a Mac 'mini,'
> there has GOT to be SOME way of ****ting it over to the Mac. And it is
> bound to work a whole lot faster. Maybe there is a 68k emulator out
> there somewhere, and the i/o is mapped into the addressing space in a
> rational, well-do***ented way?
>
> >I would expect this task to be a decidedly non-trivial one, but that
> >doesn't mean it's impossible or that it hasn't been done. If you're
> >just starting to learn to write software, you'll need to learn to
> >crawl and walk before you can run with a complex project.
>
> Hey, I'm a 68000 assembly language programmer, not a 'C' programmer;
> there are fewer instructions and addressing modes for the 68k.
>
> To elucidate the matter a little more, let's suppose I have 100 megs of
> null bytes in a .RAW or .WAV file. (I am assuming that .RAW and .WAV
> files similarly contain series of 32 bit long words.) If that's the
> case, it really doesn't matter what the sample rate is, or what the
> playback rate is, you are still going to get a series of zero
> frequencies, whether the file was examined in a forward direction, or a
> backward direction. Of course, that's a trivial situation. On the
> other hand, if your 100 meg file is full of a whole bunch of $ffffffff
> long words, you are (I would expect) going to be returning a series
> of the highest frequencies that are possible. You might even want to
> flag an overflow situation. But if you are dealing with some raw data
> sampled from a musical performance - say, a cello and an oboe, the
> bytes are going to be anything but well-ordered; the frequencies
> returned will depend a lot on what you might specify for a sample rate,
> and a playback rate.
>
> I was just hoping someone had already concocted a command along those
> lines for the Darwin 'terminal' for the Mac...
a file of continuous anything is DC, not a waveform.
Apple does provide a library to convert a buffer of audio samples into
an array of frequency magnitudes. You'll need to wrap that as a Terminal
command, though. (You see it in the animated frequency display in the
lower right hand corner of Quicktime Player, when you play an audio file.)
Here are some links:
http://developer.apple.com/do***entation/Performance/Reference/vDSP_1D_FFTransforms_Reference/Reference/reference.html
http://developer.apple.com/samplecode/VelEng_FFT/
http://www.google.com/search?q=fast+fourier+transform+site:developer.apple.com
I'm under the impression that Apple's libraries are optimized for
the particular Mac that you are running on, so you get Altvec on
PowerPC, and Intel SIMD processing on Intel Macs.
"Fourier Transform" is a specific instance of the general class
of converting from waveform samples to frequency magnitudes.
"Fast Fourier Transform" is a specific algorithm for implementing
the "Fourier Transform" transform. One of the jewels of computer
science, it is an unobvious transformation of the Fourier Transform
that is orders of magnitude faster.
/System/Library/Frameworks/Accelerate.framework/ contains an
implementation of the Fast Fourier Transform algorithm that has been
carefully optimized for the specific hardware for that Mac.
|
