Well, I don't know Phil. Your idea sounded interesting at first, but
then towards the end you describe how hard it would be to use
"realisitic" models anyway, so you kind of defeat your own suggestion.
Plus, this would be even more comp sci and math I'd have to learn. I
do appreciate your ideas however, and I thank you.

I was thinking maybe when I can afford it I would just spring for the
Vienna Symphonic Library Orchestral Cube. It purports to provide
samples of everything I want, recorded by world class players in
anechoic chambers. It would be ideal if it wasn't for the three
thousand dollar price tag.

Anyway, I'm starting to think maybe I should just do the work with my
ear instead of my computer. Most of the posters here tend to think a
software solution would be next to impossible. Might as well brush up
on my ear training and spend the time using my right side of the brain
instead of the left. Hell, from the looks of it I could spend three
years figuring out this software, it would probably only take me three
days to do a rough guess transcription. Maybe I'm finally figuring
out how much harder it is to find a lazy way of doing things.


philicorda wrote in message .org...

Why not use mathametical models of the instruments? I would imagine the
amount of samples required to cover all the sounds a violin could make
would be impossible (think of playing a false harmonic on all the strings
of a violin at every position, and with every bowing style). With a model,
you have defined the 'prime aspects of these sounds' in a very flexible
way. The computer could adjust the way the model is 'played' to find the
best fit to the sound you wish to analyse.

This would perhaps get nearer to fulfilling the interesting idea in your
original post-

"Perhaps a car engine sound file
would yield three Double Basses, a flute or two in very quiet irregular
rhythms, and maybe a horn would be involved during gear changes."

The computer could go through every single possible sound a violin could
make by iterating though all possible bow positions/angle/velocity, finger
positions etc until it found the combination that would most closely
approximate the sound you want to analyse.

If I were to persue this, I would brutally simplify things to start with.
For example, make some simple rules for an experiment...

All music is played on a single instrument model that creates perfect sine
waves. Each note this instrument makes has a fixed decay to silence over a
period of one second.
The only variables this instrument has is how loud each note is, and its
pitch, fixed to a chromatic scale.
The limitations of the 'player' of this instrument has is to play twenty
notes per second, and as many as ten notes at once.

Then, take the sound file to be analysed and every 20th of a second, try
each of the limited range of sounds this instrument can create until you
find the one that correlates most closely. (Litrally by fft correlation?)

Once that is done, you should have a performance on a very simple
instrument that has some relation to the file you wish to analyse.

Then, the model could be made slightly more complex, ie - this instrument
is an ideal Karplus-Strong string with a simple frequency dependent loss
filter. It has the properties of the length of the string, where the
string is struck, and the amount of energy imparted. It is monophonic, and
can change pitch at a limited rate.

The disadvantages of this way of working would be - Iterating though each
sound a model could create would be *very* time consuming once the models
became more realistic. It's very hard to create good physical models of
real instruments.

The advantages would be -
It might actually work. Or at least provide a way to begin attacking
this interesting but extraordinarily difficult task. The model does not
just define a fixed set of sounds (samples) an instrument can create, but
also defines the limitations in how that instrument can be played.

I think that you would have to create a model of limitations of the player
as well as the instrument anyway if you were using samples. This would
be very difficult if the computer does not 'understand' the instrument
like a physical model, as you would have to create a large amount of
rules by hand for each sample.



2. Deduct from these analyzations the prime aspects of these sounds. If
we only have, say ten frequencies to represent this sound, which ones
would be the most usefull. Or would some other type of info about the
file be more imprtant than it's frequencies? So now we have a set of
data instead of just a pcm sound file. We can call these data sets,
"fingerprints." This is mainly to help speed up the math performed later
during step 4, though it will compromise the accuracy of the final
product. Ideally, the user should be able to select the amount of data
to be derived from the samples.

3. Analyze any given sound file. These would be the "real world"
sounds. Or anything at all. In fact, I was thinking last night that
the ultimate test for this software would be to feed it, say,
Beethoven's 9th, and see how close it could aproximate it.

4. Run differential, or co-efficent on the "real world" sound file
compared to all the "sound fingerprints" the program created in step 2.

5. Create midi file. After the program has deduced what would be the
best combination of instruments in which playing styles at what pitches
and what dynamics, playing at what kind of rhytmic figures, etc., the
program would simply create a multiple staff midi file with all said
info scored on it.

Viola!