Marty Michener wrote:
>
> At 08:31 PM 3/17/02 -0500, you wrote:
>
> >What FFT size are you using?
> >
> >Walt
> >
>
> The software does not tell me per se, for the creation, only for the FFT
> size choice during the FFT file filtering sunctions. But I believe it can
> be calculated from the "bands" number. I have always taken that to mean:
> You take the total band width, from 0 to the Nyquist frequency (1/2 samping
> rate) and divide it by the number of separate bands created for the linear
> vertical display. So for 22050HZ, into 256 bands would be 86 Hz per band.
>
> But no that you ask, I am more and more sure I am wrong, because the FFT
> size tells how many samples are being used to form the local value for each
> frequency band, true? When you open the Analyze -> Frequency window, which
> draws a graph, y axis dB from 0 at the top to -120 (whatever you have to
> Range set to) at the bottom, x axis left 0, right Fnyq. It allows you to
> choose the FFT size - here now set to 4096, and filter Blackmann-Harris.
>
> But back to the spectral display - color is a function of loudness, and as
> you previously described it, as you reset the "bands" control from 128 to
> 4096, you of course see the vertical resolution going from coarse to very
> fine. But you also seem to see the accuracy in the left-right (time
> domain) resolution changing, so there is better time resolution for th 128
> bands, and more horizontally spread out, poorer time resolution for the
> more bands. This suggests to me Cool Edit is broadening the FFT size as
> one demands more frequency accuracy, as there is a natural kind of
> Uncertainty principle, here, you cannot know the exact frequency for a very
> short time period.
My previous sono software I set it as you do, before generating the
sono. With SparkXL, it's a series of buttons and can be set on the fly
while analyzing. SparkXL only goes down to 512, and it was the 4096 end
that I was noting as giving the processor a workout. Even then, you have
to set the timebase to fast (the display will scroll by fairly quickly
spreading the time), and you have to set it to max quality. I don't know
for sure what the quality setting does, it has four stops, and
definitely jumps up the processor demand to max it out. It's effect on
the display is fairly minimal, though it subdues the time blurring a bit.
As you noted frame size gives you various forms of resolution. At low
frame size you get more or less sharper on the timescale, but more
blurry on frequency. And high frame size is opposite. Which one to use
actually varies with the particular call you examine. For instance, just
rummaging around on my HD, the purple finch call works best at 4096 with
everything maxed, but a gray treefrog trill gives significant different
views with the low frame size giving what looks the most resolved.
I've only recently started seriously playing with SparkXL's sonograms.
Did not like it at first, but am beginning to figure out how to use it.
It's got both log and linear on frequency. You can adjust the frequency
range of the display to pick out just the frequency area of interest.
The same thing applies to it's loudness, you can't change the colors
used, but you can set the endpoints. And, all of this can be done on the
fly while it's running. The timebase and quality controls are the only
ones that can be reluctant to adjust when running.
> I might find out more from the original Cool Edit author, which I will try.
I have Tim Kientzle's Programmer's Guide to Sound. He has a whole
section devoted to FFT's, though he does not go as far as sonograms. I'm
not a heavy duty math person, but from what I can tell the frame size is
the number of samples used in each iteration of the FFT. Which would
explain why time blurs more as you go up in framsize, and why the
processor starts sweating. I'd not be surprised to find that SparkXL's
quality setting is how many samples between frame calculations. I doubt
it does a calculation with each sample increment, but if it did that
would be one heck of a lot of processing. What it probably does is
something that relates to how many samples each pixel step in the
display represents.
The display height is really something else. SparkXL has a fixed size
for that, and appears that each pixel of height is a different frequency
band that's calculated. That would be 256 bands I think. The value for
each band is variable as I noted above.
We just ordered a new G4 for my son to use in his programming, and to be
a testbed for OS X. It's got dual 1ghz G4's in it. It will run SparkXL
full out with no problem, I'm sure. OS X is BSD unix with a candy
coating. And some sound software is already gone native on it. The line
between Linux and mac is likely to blur a bit.
SparkXL's sonogram is part of their filter array setup. You can string a
whole set of filters together and run the sound through the set. And you
could have a in and out sonogram in there, or between any of the
intermediates. And adjust the filters on the fly while watching the
sonogram for what happens. That could give even the new G4 a workout if
you fully populated the filter array. I tend to use it's filters one at
a time, without accompanying sono, I've tried it with as many as 5
filters in place with my current G4, without the sono's that works,
depending on the filter, or you keep the sono's set on the low end. If
it runs out of guts to run realtime it automatically slows down to do
the filtering. I got SparkXL for it's filters, don't use it for routine stuff.
Walt
________________________________________________________________________
________________________________________________________________________
|