John,
     I also updated my Amaseis to permit working with the files.  In looking
at a case involving a periodic signal I discovered that the spectral values
of Amaseis are not normalized.  The FFT-component magnitudes should not
depend on the time-length of the record, but they are evidently proportional
to that length.  My guess is that what is being used is a 'standard'
engineering algorithm (such as employed in Excel) that does not do the
normalization for reason of 'book keeping'.
    For those interested in (relative) comparison of spectral intensities in
a given (single) case, the normalization is not important; but to compare
different spectral records, this is required.  For the present version of
the code, one must either insure that every case considered is of the same
time duration; or that manual adjustments of a normalizing type be done to
the numbers following their generation.  If we are to generate power
spectral densities with the algorithm, I recommend that the code be changed
to give normalized output.
   Numerical approximations to the Fourier transform are subtle.  The
Cooley-Tukey algorithm which allows the unwieldy discrete version to be
'streamilined' to the fast version is not easily understood and many
examples of normalization confusion exist.  The real test of whether one
'got it right' in writing the code is to consider (1) the FFT of a test
case, followed by (2) the inverse FFT to see if the starting 'signal' is
exactly reproduced after doing first the transform and then the inverse
transform.  What makes the matter more confusing when it comes to the
development of this type software is that there are six different acceptable
(equivalent) forms of the continuous Fourier transform and its associated
inverse (the math on which the FFT is based).  These are all equivalent but
different in appearance according to whether two-pi is put in one place or
the other acceptable place (or split according to the square root) and
according to whether the choice of negative sign in the exponential term is
placed in the direct transform or in the inverse transform.  For those who
are interested in the Fourier transform, I have written two papers on the
subject:
(1) Fourier transform construction by vector graphics, AJP 60, 439-441
(1992).
(2) Graphical explanation for the speed of the Fast Fourier Transform,
online at http://arxiv.org/html/math.HO/0302212
    Part of our difficulties relate to the following:  in physics the
continuous form of the Fourier transform is very common because of its many
theoretical application; the Laplace transform is rarely used.  In
electrical engineering, the Laplace transform is very common, but the
continuous Fourier transform is rarely used.  Because the FFT derives from
the continuous FT, engineering code has probably therefore been more subject
to the pitfalls that result from non-normalization.
     Incidently, the FFT algorithm used by WinQuake is normalized.

  Randall

psn-l-digest-request@.............. wrote:

> .------ ------ ------ ------ ------ ------ ------ ------ ------ ------.
> | Message 1                                                           |
> '------ ------ ------ ------ ------ ------ ------ ------ ------ ------'
> Subject: Re: ASCII file of wave forms and transforms from AmaSeis
> From:    Roger Sparks 
> Date:    Tue, 13 Feb 2007 11:06:13 -0800
>
> Hi John and Alan,
>
> I picked up the new version of Amaseis.   It seems to work fine.   I can
> read the new data files with Quatro Pro.   Congratulations on a very
> quick development of new feature.
>
> Roger
>
> __________________________________________________________
>
> Public Seismic Network Mailing List (PSN-L)
>
> To leave this list email PSN-L-DIGEST-REQUEST@.............. with
> the body of the message (first line only): unsubscribe
> See http://www.seismicnet.com/maillist.html for more information.