Good and bad news.
The scope showed, that the short ticks of the NMI-clock (expected length nx64 us) were much longer (> 180 us) than expected. My NMI based 24 bit timer counts correctly, but its setup was wrong: I thougt, that if one NMI cycle lasts 64 us, then 10 cycles would last 640 us. I did not consider, that the NMI generator is stopped when A' is 0 and that the time necessary to run the NMI code in ROM and my additional NMI code in ram must be also part of the setup value calculation.
This calculation must take care of at least 4 different program flow paths inside the NMI routine, having at least 4 different runtimes. This calculation could be done, but needs additon, subtraction, multiplication, division of 32 bit values. This could be done (even in assembler) before start of the music to set the default timing. But it would last too long to setup new timer values during running the song, caused by a TEMPO meta-event within the MIDI file.
So I decided to make a less complex approximation, which gives not exact timing values, but having a typical deviation of less than 10% and which can also be calculated in realtime during the song.
Now Rhapsody takes 15 min 55 sec (now a little bit too short), Scorpien's Wind of Change runs at same speed, Pink Floyd's Diamond still too slow (has a high BPM of 384, thus runs with shorter NMI ticks).
I added (for debugging) a new counter into the delay routine. It counts up, when the runtime between delay-calls exceeds the length of the desired delay. That means, that the program runs too slow to handle the delays correctly. Fortunately the counter values I have seen (are shown at end of program) are quite low....
Bad news are, that the Z88DK version I use, is a bit buggy when doing 32 bit calulations. So I downloaded the latest version and this errors are gone
But this Z88DK has new bugs: the program crashes at end, when it should jump back to BASIC. Hopefully this bugs will be resolved soon. Then I will upload a new player version.