JTDX_CONTEST を試す ― 6m激混みWAVで見えたデコーダーの実力 ― 2026年09月13日 16時02分25秒
JTDX_CONTESTを試す ― 6m激混みWAVで見えたデコーダーの実力
JTDXにコンテスト機能を加えただけのForkではありません。FT8 / FT4のデコーダーにかなり手が入り、Ensemble、Alternate pass、Hint memory、さらに送信中の空きCPU時間を利用するBackground decodingまで実装されています。
最近、なかなか興味深いJTDXのForkを見つけました。
JTDX_CONTEST by CE3TSK
名前だけを見ると「JTDXにコンテスト機能を追加した版かな？」と思うのですが、実際に調べ、動かしてみると、それだけではありませんでした。
長年JTDXを使っていて、「1局でもデコード漏れを減らしたい」という人には、一度試してみる価値がかなりあると思います。実際の送受信に使うも良し、既存のJTDXの横で受信専用decoderとして走らせるも良しです。
JTDXユーザーにはかなり気になるFork
私はJTDXのベータテスターとして、一般公開版の2.2.159だけでなく、2.2.160 RC版も使用しています。
今回は、次のソフトを同じWAVファイルで比較してみました。
- WSJT-X 3.0.2
- JP1LRT Edition（WSJT-X 3.1 Improvedベース）
- JTDX 2.2.159
- JTDX 2.2.160 RC版
- JTDX_CONTEST v3.0.0-rc05
JP1LRT Editionではデコーダー部分には一切手を加えていません。基本的にWSJT-X本流由来のデコーダーをそのまま使用しています。
ところが、そのBenchmark WAVに見覚えが……
JTDX_CONTESTのサイトには、作者CE3TSKが性能評価に使用しているBenchmark WAVが公開されています。
FT8 / FT4それぞれ1時間分、240 periodの実受信データに加え、信号数が既知のcrowded-band用WAVも公開されており、Pythonのbenchmark scriptまで用意されています。
そのcrowded-band用FT8 WAVのファイル名を見て、
となりました（笑）。
元のファイル名は、
210615_071015.wav
2021年6月15日 07:10:15 UTC。
これは、このBlogでも以前公開したWAVです。
録音したのは、6m仲間のJR1LZK 田崎さん。茨城県水戸市で50MHzを受信した際の、非常に混雑したFT8の1 periodです。
当時、田崎さんの了解をいただいて、このBlogでBenchmark用として公開しました。
2021年の記事「FT8 decoding benchmark」
今回、JTDX_CONTEST側の ft8_full_band_16.wav と、元の 210615_071015.wav を実際に比較したところ、バイト単位で完全一致していました。
もちろん、有効に使っていただいているのは大歓迎です。
CE3TSK側では、このWAVについて104信号のtruth setを作成しており、そのうち101局がJA局だったと説明しています。6mの大オープンらしい、かなり過酷なデコーダー試験素材です。
同じWAVで比較してみた
今回の手元での比較結果は次の通りでした。
| Software | Decode数 | WSJT-X 3.0.2比 |
|---|---|---|
| WSJT-X 3.0.2 | 73 | 基準 |
| JP1LRT Edition / WSJT-X 3.1 Improved | 73 | ±0 |
| JTDX 2.2.159 | 75 | +2 |
| JTDX 2.2.160 RC版 | 83 | +10 |
| JTDX_CONTEST v3.0.0-rc05 | 93 | +20 |
73 → 75 → 83 → 93。
このWAVのような、極端に多くの信号が重なった状況では、かなり大きな差です。
まず、WSJT-X 3.0.2とJP1LRT Editionはともに73 decodeでした。
JP1LRT Editionではデコーダー部分に手を加えていないため、この結果はある意味当然ですが、少なくとも今回の試験では、JP1LRT Edition独自改造によってデコード性能が低下しているわけではないことも確認できました。
JTDX 2.2.159では75、2.2.160 RC版では83、そしてJTDX_CONTESTでは93でした。
この1本のWAVだけでソフト全体のデコード性能を断定するつもりはありません。極端に混雑した6mの1 periodに対する一つの比較結果です。ただし、この条件での差としては無視できないと思います。
JTDX_CONTESTは何をしているのか
JTDX_CONTESTの面白いところは、単純にデコード閾値を下げただけではないところです。
Ensemble decoding
同じ音声にわずかなdelay、dither、frequency shiftなどを与え、複数の条件でdecodeし、その結果を統合します。
Alternate pass
通常のdecode後に残ったresidual audioに対して、別のdecode recipeでもう一度探索します。
Hint memory
一度decodeした局やメッセージの情報を複数periodにわたって保持し、次のdecodeに利用します。
Background decoding / Pipeline
そして個人的に最も面白いと思ったのが、Background decoding / Pipelineです。
「送信中にもdecodeする」
通常のFT8ソフトでは、受信periodが終わるとdecodeを実行し、その結果で次の送信内容を決めます。
JTDX_CONTESTは、ここを二段階に分けています。
まず短時間のRX phaseで、次の送信を決めるために必要なdecodeを済ませます。
その後、こちらが送信を開始してからも、直前に受信した音声を保持したままBackground decodingを続けます。Alternate pass、Ensemble、Residual decodeなどを、従来ならCPUが遊んでいた時間に実行します。
送信が始まってから見つかったメッセージを、その最中の送信内容へ反映することはできません。しかし、その結果は次のperiod以降に使えます。
例えば、Background decodingで次のようなものを見つけたとします。
- 自局宛てのメッセージ
- New DXCC
- New Call on Band
- 強力な局の下に埋もれていたDX
現在の送信には間に合わなくても、その情報をHint memoryなどへ引き継いでおけば、次の受信periodでは既知候補として扱える。
つまり送信中の追加decodeは「今の送信を変えるため」ではなく、次の送信判断に使う情報を先に掘っておくための処理と考えると分かりやすいと思います。
6m DXでは、これはかなり価値があると思います。
一瞬のオープンでNew DXCCが出てくる6mでは、これが一番悔しいパターンです（笑）。
送受信に使うも良し、受信専用でも良し
JTDX_CONTESTは、普通に送受信ソフトとして使うこともできます。
一方で、
という使い方も面白いと思います。
JTDXユーザーの中には、取りこぼしを嫌って複数のdecoderを同時に動かしている方も少なくないでしょう。
そういう人にとっては、かなり興味深い選択肢になるはずです。
Contest機能も搭載
名前の通り、JTDX_CONTESTにはコンテスト機能も組み込まれています。
現在は特にWW Digi DX Contestを意識した実装となっており、exchange、points、multipliers、contest logなどが統合されています。
単なる「JTDXのdecoder実験版」ではなく、実戦運用までかなり意識して作られている印象です。
Benchmark環境も公開されている
もう一つ評価したいのは、作者が性能を主張するだけでなく、検証用のWAVとscriptを公開していることです。
- FT8：実受信1時間、240 period
- FT4：実受信1時間、240 period
- crowded-band WAV
- truth set
- benchmark script
crowded-band用WAVにはtruth setがあるため、単に「何局decodeしたか」だけでなく、false decodeまで評価できます。
という形で再現素材まで公開している姿勢は、とても好感が持てます。
JTDXユーザーなら一度試してみる価値あり
JTDX_CONTESTは現在、v3.0.0-rc05です。
したがって、完成したGA版として評価する段階ではありません。
しかし、長年JTDXを使っていて、
という人には、一度試してみる価値がかなりあると思います。
特にFT8 / FT4でDXを追いかけている人、6mのような一瞬のオープンを狙っている人には面白いでしょう。
実際の送受信に使うも良し。受信専用のサブdecoderとして使うも良し。
Webサイトは日本語表示にも対応しています。
最後にちょっとだけ
今回、
WSJT-X 3.0.2 = 73
JP1LRT Edition = 73
JTDX 2.2.160 RC版 = 83
JTDX_CONTEST = 93
という結果を目の前で見てしまいました。
でも、JP1LRT Editionではデコーダーには手を付けていません。
これはむしろ、次に何を研究すべきかが見えてきた、と考えることにします。
73, Yoshi / JP1LRT
コメント
_ Tihomir CE3TSK ― 2026年09月13日 21時22分03秒
_ JP1LRT / 津久浦 ― 2026年09月13日 23時03分57秒
Thank you very much for your comment and for the additional technical information.
I am also very glad that the origin of the crowded-band WAV has now been confirmed. The recording was made by Tasaki-san, JR1LZK, in Mito on 6 meters, and I published it on my blog with his permission back in 2021. I am very happy to see that it has been useful for the development and testing of JTDX_CONTEST.
Your explanation about the a-priori hint mechanism is especially interesting.
It also explains why a repeated or continuous real-world reception cannot be compared directly with a completely cold single-WAV decode. In actual operation, previously decoded stations can become useful context for the following periods, while the background decoder can continue searching for additional signals.
That is an important distinction, and I think it deserves further testing.
I will also try the same crowded-band WAV with the decode bandwidth expanded from 50 to 3650 Hz as you suggested. For comparison purposes I will keep the original 100–3100 Hz result as the fixed baseline, and treat the wider-band result as a separate test.
Thank you again for JTDX_CONTEST and for openly explaining the design behind it.
73,
Yoshi / JP1LRT
コメントをどうぞ
※メールアドレスとURLの入力は必須ではありません。 入力されたメールアドレスは記事に反映されず、ブログの管理者のみが参照できます。
※なお、送られたコメントはブログの管理者が確認するまで公開されません。
※投稿には管理者が設定した質問に答える必要があります。
トラックバック
このエントリのトラックバックURL: http://jp1lrt.asablo.jp/blog/2026/09/13/9876332/tb
※なお、送られたトラックバックはブログの管理者が確認するまで公開されません。
Thank you very much for your excellent and first independent review of JTDX_contest.
And yes, I got the full crowded band WAV file from your post. Thank you very much to you and to Tasaki-san JR1LZK.
By the way, the a priori hint mechanism can get even more stations out of the crowded band, e.g. if you read the same file several times, then you can see that the stations previously decoded will appear in the RX phase, and the new background phase will be able to pull out some more. This is still relevant because e.g. a band opening does not consist just out of one sample, i.e. the stations continue calling where they are, so including the hint mechanism's effect makes sense in real life.
Additionally, some of the signals our lower than 100 Hz and some are on the higher side of 3100 Hz, so if you want to get the best results for the crowded band you can increase the used decode bandwidth to 50-3650 Hz in Decode -> FT8/FT4 decode bandwidth menu.
Domo arigato gozaimasu and 73 de
Tihomir CE3TSK