Some years back Wayne Stahnke and I discussed the optical scanning
problem of distinguishing notes from non-notes.  My plan (never got to it
-- maybe now that I'm retired I will!)  was to use a line-scan camera much
like D. L. Bullock describes, with programmable thresholds for go and
no-go.

One would need to calibrate carefully for "difficult" rolls, and there
will always be the need to proof the copy against the original.  And
there can be multiple thresholds for different functions, such as
printed stuff vs. note punches.

I prefer the line-scan approach over other methods because it provides
the most flexible way of handling any kind of roll.  Then, as Bernt Damm
notes, everything following can be done in the computer.

On the matter of how many notes to capture:  It seems a waste of storage
media to use 176 (or whatever the number may be) slots when all one needs
is 12(?) for a Rolmonica.  Why not have a configuration parameter for
the file that defines the scale?  Then only what is needed is used, in
probably binary sequence.

A comment regarding images.  I think we must use images, not ASCII,
for stuff printed on the rolls.  Imagine, for instance, a child's
picture roll, or that wonderful old QRS roll, "Der Schnitzel-bank", with
delightful pictures throughout.

John Phillips' comments about the tempo lines leads me to speculate on
just what may be important to collectors and researchers of the future.
It would seem better to err on the side of too much rather than too
little.

One last comment:  No one's going to make much money at this preservation
business, so let's put aside worries about pirating, etc. and consider it
a hobby freely shared.

Bob Billings


 [ Editor's note:
 [
 [ Richard Tonnesen and Wayne Stahnke both concluded, many years ago,
 [ that file formats which are efficiently encoded for minimal size
 [ require much more programming, and thus the processing time is
 [ much slower.  Both the Stahnke and the Tonnesen perf-file formats
 [ use two bytes for each note event: one byte for delta-distance, the
 [ other byte is the channel (key) number (up to 240 channels if needed).
 [
 [ By way of comparison, MIDI files -- which support multiple channels
 [ and controller events -- average about 4.5 bytes per event, for the
 [ same music roll data.
 [
 [ Thus the perforator control file of a typical reproducing roll might
 [ require 20 kbytes storage, while the MIDI file would take 45 kbytes
 [ per song.  In either format you can store *thousands* of files on
 [ a modern disc drive!  If you wish to send files on a floppy disk,
 [ MIDI files often compress to less than 10% size using pkzip.
 [
 [ I had the same thought as you about the cute illustrations printed
 [ on "Schnitzel-Bank" (QRS WF6720).  Richard Tonnesen performed a 
 [ special high-resolution transcription for me, and I scanned the
 [ images into a set of TIFF files.  Everything is ready for the day
 [ when Richard gets a continuous-feed laser printer to print the
 [ words and illustrations on the piano roll !
 [
 [ -- Robbie