MKIV CD noise analysis

[andrew.bennett@ns.sympatico.ca (Andrew Bennett)]

As promised eons ago, I have finally got power spectrum
routines working on data from the MKIV. First results:

PERIODICITIES
The patterns I thought I could see with repeat
distances of 16 and 4 pixels are not visible in
the spectra. The best face-saving excuse I can come
up with is that they were moire patterns involving
the dot pattern of my monitor. But I'll keep looking.

NOISE
60Hz noise is undetectable ... or I am looking in
the wrong part of the spectrum.

(about 50 seconds per image, 40 rows/sec -> 20/sec
folding frequency so 60 Hz should be aliased to
somewhere near the folding frequency that way.
The other way, resolution 40 Hz so 60 Hz ->
1.5 cycles per row. Right?)

I was so surprised at not finding 60 Hz that I
artificially added some. 2 digits p-p (0.5 digits^2
variance) was obvious and 4 digits p-p was prominent
so the actual amount must be minute. Unless I am
looking in the wrong place in the spectrum.

I conclude that either Tom is really running the
whole thing on batteries somewhere deep in the
woods away from power lines or he really knows
what he is doing!

Other noise: The dark file d150004 had some blips
in the spectra:
about 16KHz  TV?
      18KHz  ?
      32KHz  harmonic of TV?
      34KHz  Monitor? Stereo carrier? TV sound carrier?
All frequencies assuming 12microsec/pixel. Scale to taste.
Total power in these blips maybe 3 digit^2 if I have
got my scaling right. Big deal.
Quite invisible in the other files examined - these all
had higher signal levels.

CONCLUSION
I still haven't found a damn thing to complain
about. The MKIV is a fine piece of engineering.

***********************
TECHNICAL DETAILS.
The programs are single precision floating
point based on the Hartley transform. Written
in Borland Pacal 7.0, with a minute amount of
Assembler to cover BP7.0's abominably slow 32-bit
integer coding, they handle 1 & 2D transforms with
dimensions having up to 3 mutually prime factors
chosen from (2, 3, 4, 5, 7, 8, 9, 16, 25, 32)
   eg 2016 = 7*9*32.
There would be no technical problem other
than laziness in adding a factor of 127 to
the list if somebody really wanted to do
2032x2032 rather than 2016x2016. I have power
of two code too.

2Kx2Kx4B/pixel = 16M image or Hartley
2Kx1K  8M each = 16M Re + Im FT after splitting
                  8M 2-D power
                 16M Re + Im Cross spec

So in my 32M machine I can roll in a batch
of images and accumulate 2D power spectra
using 24M work space.
With the same work space, I can read in the data,
transform, and convert from Hartley to Fourier
(the real part of the output FT overlays the
Hartley transform which in turn overlayed
the input raw data) which I then write back
to disc.
Transform + cross spectrum + 2 power spectra
as needed for cross correlation spectrum
needs 48M, which I am too mean to buy. However, I
have computed the correlation spectrum in two
halves with disc buffering:

PROBLEMS WITH DISC TRANSFERS
Reading and writing the 24MB for the first half
of the correlation processing took only a matter
of seconds - far faster than I expected - but the
second half took several minutes. It turned out
that splitting the data into an integral number
of 2016 point rows put the transfers involved
in the second half out of step with the disc file
allocation. Borland Pascal went away and did
something incredibly time consuming to cope with
this. But only when writing - reading was about
as fast as when things were in step. The cure was
to split the computation at a multiple of some
large power of two (I didn't bother to find out
the precise value; 32768Bytes worked) rather than
at the end of a row.
The moral of the tale is that you may need to
worry about nasty low level details when trying
to write out a lot of data to disc. I managed
to make my disc look 50 times slower than it
really was, without even trying.

INTEGER FFT
On the way to the floating point Hartley transform
I played with integer FFT. This was a time consuming
disaster as far as power spectra were concerned as
I could not keep the data within the 16-bit range
without all the interesting low level noise stuff
falling off the end of the word. However, if anybody
wants a set of routines for 1 & 2D transforms with
full facilities for putting in scaling factors at
every turn and for counting the overflows ...

2Kx2Kx2B/pixel =  8M per image
                 16M per 2 images
  2x8M Re+Im     16M per transform, 2 at a time
                  4M each packed Re, Im, power
So one could do a great deal in a 32M computer.
Pity it isn't useful.

(Why Borland Pascal 7.0?
1) I own a copy.
2) I know how to circumvent most of the bugs.
3) C/Linux - which I also have - is to me essentially
a write-only language. Nearly as bad as LISP. How
you C-Gurus cope, I have no idea.)
**************************************

Andrew Bennett, Avondale Vineyard, Nova Scotia, Canada.