As mentioned earlier I was intrigued by one sentence in the mail from David, G0MRF, (17 Januari):
"Interestingly Rik's SlowJT9 which was running in parallel, managed to decode a couple of more transmissions than WSJT-X."
As SlowJT9 uses the JT9 decoder from the WSJT-X suite the performance of SlowJT9 and WSJT-X should be identical. The only difference between both could be a small timing difference that made SlowJT9 to decode some extra transmissions (pure luck, it could have
been the other way around as well).
So maybe the performance of SlowJT9 can be improved by running the recorded audio several times through the decoder with each time a small (0.1 second ?) time shift induced in the audio and then taking a "best off" all decoded signals?
So I decided to add a "Multiple decoding" option (Settings → Mode → check "Allow multiple decoding").
If "Multiple decoding" is enabled the received audio will first de decoded as it is and then shifted +/- 1 second in time steps of 0.2 seconds and decoded again for each step.
Thus there will 11 decoding steps in total.
However decoding always will stopped at 1 second before the end of the cycle at latest, so the next cycle will not be corrupted.
Decoding can also be stopped by clicking on the Band activity or RX frequency windows. After each decoding step the new (non-duplicate) decoded messages are shown.
So even during the decoding process any already decoded message can be selected by triple-clicking on it (a single click for stopping the decoding followed by a double click for selecting the message).
Be aware that for now all decodings are performed one after another and each one can take several seconds on a slow computer. In that case only a limited number of decoding steps will be performed.
But if multiple decoding also shows a significant improvement in the field I will have a look at parallel processing of the decodings.
In order to be able to evaluate multiple decoding the DT parameter now does not show the time offset of the received signal but the time offset of the decoded audio file.
This means that any message with a DT value different from 0.0 is a decoded message that would have been missed before.
I will appreciate all feedback about the number of decoded messages with a DT diffeternt from 0.0.
Of course bug reports, remarks and suggestions are still welcome.
