JTDX_contest v3.0.0-rc08登場 ― SuperFoxデコーダーが大幅進化、僕もこのプロジェクトを応援したい ― 2026年09月22日 16時59分21秒
JTDX_contest v3.0.0-rc08 がリリースされました。
今回の最大の注目点は、何といっても Experimental SuperFox decoding support です。
Tihomirから送られてきた説明を読むと、単純に 「WSJT-X 3.0.2のSuperFox receiverを移植しました」 というレベルではありません。
WSJT-X 3.0.2のreceiverを出発点としながら、 JTDX_contest独自のデコード処理をかなり積極的に追加 しています。
🦊 SuperFox decoder の何が変わったのか
SuperFoxの帯域内に通常のFT8信号などが存在しても、 interferenceを受けているtoneだけが突出しないよう補正してから decodeを行います。
候補を絞りながらlist decodingを行い、 messageのCRCを使って候補を確認します。
特に面白いのは、odd periodで実際に受信できたHoundを使って、 Foxが誰に応答している可能性が高いかを絞り込むところです。
一度decodeしたFoxや、DX Call boxに指定されたFox、 受信したHoundなどの既知情報を利用して、 decoderの探索を助けます。
これも非常に興味深いところです。
↓
FT8 signals subtraction
↓
cleaner audio
↓
SuperFox decode
つまり、同じband内の通常FT8を先に見つけて取り除き、 その後にSuperFoxをdecodeするという考え方です。
Fox探索をthread化し、 難しいFoxの探索が他の処理を必要以上に遅らせない構成になっています。
最終段では3つのsync windowを使用し、 Foxにfrequency offsetやtime offsetがある場合にも対応します。 これはデフォルトで有効とのことです。
⚙ Experimental だからこそ面白い
現在、このSuperFox decoderは experimental とされています。
またTihomirによると、 SuperFox関連のconstantは 再buildすることなく変更可能 になっています。
今後、実際のSuperFoxのrecordingを集めながら、 各parameterを調整していくことを想定しているとのことです。
Tihomirは、実際のSuperFox DXpeditionを受信した WAV file を募集しています。
理想は約1時間分とのこと。 実際の信号を使ってdecoderを改善するための資料になります。
📡 SuperFox以外のrc08の変更
✅ 周波数の Mark as default / Unmark default
✅ band buttonはdefault frequencyとIARU regionに合うものを表示
✅ Check for updates 機能を追加
✅ stock JTDXが「ALL」にしてしまったFT2 frequencyを自動修復
✅ main windowを狭くした場合のlayout改善
✅ menu translation、tooltip、keyboard shortcutの修正
📖 SuperFox receiverの解説ページ
新しいSuperFox receiverがどのように動作するのかについて、 Tihomir自身が詳しい解説ページを公開しています。
8言語で用意されています。
🤝 僕はこのプロジェクトを積極的に応援したい
僕自身、JTDXには以前から深く関わってきましたが、 今回のJTDX_contestを見ていて特に面白いと思うのは、 既存のものを単に維持するだけではなく、新しいアイデアを実際に実装して試している ところです。
Decoderは、「理屈では良さそう」だけでは完成しません。
実際のsignal、QRM、frequency offset、time offset、 様々な受信環境で試し、 そこで得られたevidenceを元に改良していく必要があります。
僕は、こういう開発を積極的に応援したいと思っています。
日本のJTDXユーザーにも、 このプロジェクトをぜひ知ってもらいたいと思います。
また、SuperFoxの実録WAVを提供できる機会があれば、 decoder developmentへの非常に良い協力になると思います。
WSJT-X Improved は「WS Digital Mode Suite」へ ― v3.2.0公開に向け準備進行中 ― 2026年09月22日 09時41分32秒
「WS Digital Mode Suite」へ 🚀
長く親しまれてきた「Improved」という名前が、まもなく大きく変わりそうです。
WSJT-X Improved を使っている方なら、最近の動きを見て 「何か始まっているな」と感じているかもしれません。
2026年9月22日現在、SourceForge の Activity には、 新しい WS v3.2.0 のファイルが次々と登録されています。
- Windows 64-bit
- AL版
- Widescreen版
- Windows 32-bit
- Linux
- macOS
- Raspberry Pi
- Source code
これらが ws-3.2.0_260924... という名称で準備されています。
ただし、今日9月22日の時点では、 Activity上に登録状況は見えていても、 通常のダウンロードページからまだ取得できないものがあります。
SourceForge側で最終準備中
という状態と見るのが自然でしょう。
最初は単純に
↓
WS
という名称変更なのかと思っていました。
しかし、JTAlert側の対応を見ると、 もう少し正確な姿が見えてきます。
Support for the new WS Digital Mode Suite (previously known as WSJT-X Improved).
Dedicated JTAlert operating mode for WS with a green colored icon for the "JTAlertV2 for WS Suite" shortcut.
If you want to create your own shortcut use the /wsdms command-line parameter to start JTAlert in WS operation mode.
ここまで明記されているので、 今後の呼び方としては
と考えるのが一番分かりやすそうです。
興味深いのは、 JTAlertが単に実行ファイル名を読み替えただけではない点です。
専用ショートカットとして
が用意され、さらに起動オプションとして
まで用意されています。
つまり周辺ソフト側でも、 WS Digital Mode Suite を独立したアプリケーション環境として扱う準備が進んでいる ということです。
僕も WSJT-X をベースにした派生版を開発しています。
そして先日、K1JT Joe から直接、
“WSJT-X” を含めないでほしい
という要請を受けました。
そのため僕自身の版についても、 現在はいったん一般公開を停止し、 re-name / re-brand を進めています。🔧
僕自身は Joe から直接、名称についての要請を受けた。
Uweさんの WSJT-X Improved は WS Digital Mode Suite への移行を進めている。
Uweさんが Joe から同じ要請を受けた結果として 今回の名称変更を行ったのかどうか。
タイミングだけを見ると、 「同じ話なのでは？」と思いたくなります。
ただ、Uweさん本人からその経緯を聞いたわけではありません。
なので、そこは勝手に結び付けず、 分けて考えておきたいと思います。
WS Digital Mode Suite v3.2.0 の正式公開へ
Windows / Linux / macOS / Raspberry Pi など
JTAlertなどが「WS Suite」を独立した対象として扱う
徐々に WS Digital Mode Suite / WS Suite という呼び方へ移行
僕自身、長い間 WSJT-X Improved を追いかけてきました。
JTDXやWSJT-X Improvedの開発の流れをずっと見てきただけに、 「WSJT-X Improved」という名前そのものが消えていく のは、少し不思議な感じがします。
でも、これは単なる名前変更というより、
「WSJT-X ○○」ではなく、
自分自身の名前を持つソフトウェアへ
という大きな転換点なのかもしれません。
- 従来版からの設定引き継ぎ
- 旧 WSJT-X Improved との共存
- フォルダ名や設定保存先の変更
- JTAlert の WS Suite モード
- PSK Reporter へ送られる program identity
- 旧版ユーザーがそのまま移行できるのか
9月24日に正式公開されたら、 実際にインストールしてこのあたりも確認してみたいと思います。
【アマチュア無線家の皆さんへ】周波数再編アクションプラン案のパブコメ開始 ― 430～440MHz帯と『周波数割当ての見直し』に注目 ― 2026年09月20日 11時45分40秒
総務省が「周波数再編アクションプラン（令和8年度版）（案）」を公表し、パブリックコメントの募集が始まりました。 今回の案には、アマチュア無線に関して見過ごせない記述があります。
総務省「周波数再編アクションプラン（令和8年度版）（案）に対する意見募集」
https://www.soumu.go.jp/menu_news/s-news/01kiban09_02000601.html
意見募集は2026年9月19日から10月23日23時59分まで。 案件番号は145210777です。
今回の文書は42ページありますが、一通り読んでみると、アマチュア無線家として特に注意しておきたい部分がありました。
総務省案の「第4章 Ⅸ その他周波数の再編・電波の利用等に関する取組」の 「（12）アマチュア無線周波数帯における周波数の割当てや共用等の検討」には、次の趣旨の記述があります。
「アマチュア無線全体の周波数割当ての見直しや更なる共用の推進等に向けた検討」
さらに、当面の課題として、
「430-440MHz帯等において、第4章Ⅱ4（2）①自営系無線システムに併せた検討を進める」
とされています。加えて、いわゆるバンドプラン全体の将来的な見直しや、更なる共用の推進についても記載されています。
もちろん、この文書に「430MHz帯をアマチュア無線から取り上げる」と書いてあるわけではありません。 そこは冷静に読む必要があります。
しかし一方で、「アマチュア無線全体の周波数割当ての見直し」「430-440MHz帯等」「更なる共用」「バンドプラン全体の将来的な見直し」という言葉が、 政府の周波数再編方針案に明記されていることも事実です。
430～440MHz帯については、単独で書かれているのではなく、 「第4章Ⅱ4（2）① 自営系無線システム［400MHz帯］」の検討と併せる形になっています。
その自営系無線システムの項では、タクシー無線や地域振興用MCAなどについて、 アナログ方式だけでなくデジタル方式でも局数の減少傾向がみられ、 携帯電話（IP無線等）やデジタル簡易無線などへの移行が進むことが想定される、としています。
そして中長期的には、周波数の整理・再編について調査・検討し、 これまで周波数を分けていた用途を統合・共用させることなども例示されています。
現時点で具体的な削減幅や新たな共用相手が決まった、と読むべきではありません。 ただし、430～440MHz帯を自営系400MHz帯の再編と関連付けて検討する方針が明記されている以上、 アマチュア無線家側からも利用実態や技術的事情を具体的に示していく意味はあると思います。
今回の案では、アマチュア無線について、 ピーク時の1,364,316局（平成6年度）から、 329,653局（令和8年3月末、24.1%）まで減少したことが示されています。
しかし、アマチュア局全体の局数が減ったことと、 個々のアマチュアバンドで必要とされる帯域幅や周波数利用の価値は、必ずしも同じ話ではありません。
430MHz帯だけを見ても、FM、レピータ、デジタル通信、衛星通信、コンテスト、弱信号通信、各種実験など利用形態はさまざまです。 HF、50MHz、1.2GHz以上の各バンドについても、伝搬特性や利用目的は大きく異なります。
だからこそ、単に「アマチュア局数が減った」という総数だけではなく、 各周波数帯の実際の利用状況、国際的な周波数分配、技術的利用、共用した場合の影響などを丁寧に評価してほしい、 という意見は十分に成り立つと思います。
ここは大事です。
e-Govは、パブリックコメントについて、 提出された意見の「量」ではなく「内容」を考慮する制度であり、 同一内容の意見が多数提出されても、その数そのものが考慮対象になる制度ではないと説明しています。
ですから、同じ文章を大勢でコピーして送ることよりも、 それぞれのアマチュア無線家が、自分の経験や専門分野から具体的な意見を出す方が意味があります。
- どのページ、どの項目についての意見なのかを明示する
- 「反対」「困る」だけでなく、なぜ問題なのかを書く
- 自分がその周波数を実際にどう利用しているかを具体的に示す
- 共用を検討するなら、相手システムや技術条件、干渉条件を明確にしてほしいと求める
- 局数だけでなく、バンドごとの利用実態を評価してほしいと求める
- 可能なら、どのような文言や検討条件にすべきかまで提案する
DXをやっている人、コンテストをやっている人、レピータを管理している人、 衛星通信、EME、マイクロ波、デジタルモード、非常通信、技術実験をしている人――。
アマチュア無線の使われ方は一様ではありません。 だからこそ、それぞれの分野を実際に運用している人から出てくる具体的な意見には価値があります。
今回の意見募集は始まったばかりです。 まだ知らないアマチュア無線家も多いと思います。
私自身も、これで結論を出したわけではありません。 今後、今回の案だけでなく、根拠となっている電波の利用状況調査や電波監理審議会の評価、 過去の検討経緯なども確認したうえで、自分の意見をまとめるつもりです。
感情だけで書けば「ご意見として承ります」で終わってしまうかもしれません。 だからこそ、精査できる方にはぜひ原文を読み、技術的・制度的な根拠を持って意見してほしいと思います。
そして、まずは声を出すこと。 この件を知らない友人・知人のアマチュア無線家、クラブの仲間、SNSでつながっているハム仲間にも、 「こういうパブリックコメントが始まっている」ということを伝えていただければと思います。
📻 まず原文を読む。
🔍 自分の分野から考える。
✍️ 自分の言葉で意見を出す。
🌐 そして周囲のアマチュア無線家にも知らせる。
🔹 総務省
「周波数再編アクションプラン（令和8年度版）（案）に対する意見募集」
🔹 e-Gov パブリック・コメント
意見募集案件一覧
案件番号：145210777
🔹 パブリック・コメント制度について（e-Gov）
パブリック・コメント制度について
※この記事は2026年9月20日時点で公表されている「周波数再編アクションプラン（令和8年度版）（案）」およびe-Gov掲載情報を基にしています。 今後の検討や意見募集結果によって内容が変わる可能性があります。
WSJT-X派生版の公開配布をいったん休止します ― 名前を変えて、開発はそのまま続けます ― 2026年09月18日 11時52分34秒
今回の理由は、ソフトの不具合や安全上の問題ではありません。
WSJT-X upstream側から、派生版については WSJT-Xとは独立したプロジェクト名を使ってほしい との要請を受けたためです。
その要請を尊重して、これまで使ってきた 「WSJT-X Improved JP1LRT Edition」 という名称は、今後の正式名称としては使わないことにしました。
🔹 開発：継続
🔹 新しい名称：検討中
🔹 最後の公開版：20260901A-REB522-P6 / P6-AL
🔹 GitHub：公開のまま
なので、「公開停止」と書くと少し大げさに見えるかもしれませんが、 実際には いったん看板を外して、作業場に戻った くらいの感覚です（笑）。
これまで実装してきた内容は、AutoSeq 2 / 3、Wanted / Hunting、Terminal Hold、 No-reply fallback、手動操作との競合防止、Best S&P、各種表示改善やdiagnostic機能など、 FT8 / FT4を実際に運用していて「ここをこうしたい」と思ったものが中心です。
✅ Wanted局を待つHunting動作
✅ RR73 / 73終端処理の保護
✅ QSO中の誤った切替や誤発火の抑制
✅ Terminal Hold
✅ Band Activity / Wide Graph表示改善
✅ ALL.TXT / diagnostic情報の強化
このあたりは、名称とはまったく別の話です。 名前が決まっていなくても、コードは書けます（笑）。
むしろ最近は、JTDX_contest 3.0を実際に動かしてみて、 デコーダーや処理構造の考え方そのものにかなり興味が戻ってきています。
「これは面白いな」と思う考え方があれば、 そのまま持ってくるのではなく、 自分の環境ではどういう形で実現できるのか を考えてみたいと思っています。
今回、名前を考えているうちに、少し根本的なことを考えました。
そもそも私は、このソフトを大規模に普及させたいのか？
……たぶん、そこが一番の目的ではありません。
商用ソフトではありませんし、 ユーザー数を競いたいわけでもありません。
もともとは、
それを実際に使って、動きを確認して、 面白ければさらに改良する。
それが出発点でした。
ところが一般公開を続けていくと、 名前、ロゴ、Release管理、User Guide、多言語化、配布ページ、サポートなど、 ソフト開発以外の作業もどんどん増えていきます。
それも必要な仕事ではあるのですが、 今の自分は、そこよりも 実際の動作やアルゴリズムをいじっている方が楽しい ということを改めて感じています。
将来、また普通に一般公開するかもしれません。
限定配布にするかもしれません。
自分と少数のテスター中心で続けるかもしれません。
今のところ、どれかに決めるつもりはありません。
需要が自然に増えたら、その時に考えればいいと思っています。
逆に、技術実験として続けるのが一番面白いなら、それでも十分です。
その方が自分には合っている気がしています。
「WSJT-X Improved JP1LRT Edition」 という名称は、 今後はhistorical nameとして扱います。
過去のRelease、source bundle、User Guide、screenshotなどには当然その名前が残っています。 それらまで無理に書き換えるつもりはありません。
GitHubのP6 / P6-AL Releaseページは現在、 Historical Release Record として残しています。 Win64の実行バイナリは削除し、 source bundle、checksum、documentationは技術記録として残しました。
また、このブログでこれまで掲載してきた 旧名称を前提とした配布案内やRelease紹介記事は、一旦非公開にします。
技術記事として今後も意味のあるものは、 必要に応じて内容を整理して再公開するつもりです。
https://github.com/jp1lrt/wsjtx-avelag
https://github.com/jp1lrt/wsjtx-avelag/releases/tag/20260901A-REB522-P6
そんなわけで、少し整理期間には入りますが、 開発そのものはむしろ今まで通り、いや、 余計なことを考えず技術に戻れる分、こちらの方が気楽かもしれません（笑）。
新しい名前と今後の公開方法が決まったら、また改めてお知らせします。
JTDX派生版「JTDX_contest 3.0.0-rc07」公開 ― FT2を新実装、デコーダー進化はさらに加速 ― 2026年09月17日 22時54分44秒
今回の目玉は、何と言っても FT2の正式実装 です。
しかも、単純に他の実装からFT2デコーダーを持ってきたものではありません。 JTDX_contestで大幅に改良されてきた 独自のFT4デコーダーチェーンをベースにFT2を実装 しており、 FT2にもJTDX_contest独自の仕組みが引き継がれています。
🔹 Ensemble decoding
🔹 TX background decoding
🔹 Decode budget
🔹 FT2専用の4段階プリセット
🔹 Expert menu / Preset lamp
FT2の送受信互換性についても、WSJT-X Improvedとの間で相互確認が行われ、 12種類のメッセージタイプで送受信をクロスチェック。 さらに20mでの実運用テストも行われたとのことです。
rc07はFT2追加だけではありません。GUIや操作性、従来から存在していた問題の修正まで、かなり広い範囲に手が入っています。
✅ 周波数表示上でマウスホイールを使い、100 / 10 / 1 kHz単位でQSY
✅ DX Callボタン／コールサイン欄のダブルクリックでQRZ.comを開く機能
✅ ウィンドウリサイズ時のsplitter比率保持
✅ Waterfallに以前から存在していたbuffer overrunの修正
✅ 新規インストール時の多数の初期設定値を実運用向けに見直し
このうち、ウィンドウを狭くした状態で終了すると、次回起動時にサイズが変わってしまう現象については、 私の環境で気づいてTihomirさんへ報告しました。 すぐに再現確認が行われ、その後すぐRepository側で修正されています。
本当に仕事が速いです（笑）。
rc06では、これまでJTDXの日本語ローカライズを担当してきた経験を活かして、 新しく追加されたUIやメッセージの日本語化について少しお手伝いをさせていただきました。
rc07ではFT2関連の新しい文字列が追加され、 FT8/FT4限定だった表記の一部も「FT*」へ一般化 されています。 現在、FT2関連の日本語訳についても、単に日本語として自然かどうかだけでなく、 decoder内部の意味や既存用語との整合を含めて確認しています。
JTDX_contestは、もはや単に「コンテスト向けに機能を足したJTDX」というだけではなく、 FT8 / FT4 / FT2のデコーダーそのものをかなり積極的に検証・改良するプロジェクト になってきています。
とくに、同じ受信音声を異なる条件で再評価するensemble decoding、 応答判断に必要な処理と、その後のTX background処理を分離する考え方、 hint memoryの拡張など、単なるGUI追加とはまったく違う方向の改良が進んでいます。
JTDXユーザーには、かなり面白い派生版だと思います。
https://ce3tsk.com/
https://github.com/ce3tsk/jtdx_contest
「JTDX_contest 3.0.0-rc06 公開 ― 日本語ローカライズと新機能を確認 ― 2026年09月15日 17時39分06秒
JTDX_contest 3.0.0-rc06 公開 ― 日本語ローカライズと新機能を確認
昨日から今日にかけて、日本語ローカライズの見直しを少しお手伝いした内容が、 早くもrc06へ反映されました。さらに、話題にしていたDXCC名の表示切替や、 cty.dat / LoTW user listのダウンロード機能まで実装されています。
CE3TSK Tihomirさんが開発を進めている JTDX_contest 3.0.0-rc06 が公開されました。
昨日から今日（9月14日～15日）にかけて、 これまでJTDXの日本語ローカライズを担当してきた経験を活かし、 JTDX_contest 3.0で新しく追加されたUIやメッセージの日本語化について、 少しお手伝いをさせていただきました。
日本語化は「単語を置き換えるだけ」ではない
今回の3.0では、新しいデコーダー設定をはじめ、多くの項目が追加されています。 こうした技術系ソフトウェアの翻訳は、単純に英単語を日本語へ置き換えればよいというものではありません。
たとえば budget や knee of the curve といった表現も、
機能や処理の意味を理解せずに直訳すると、日本語UIとしてかなり不自然になります。
「許容処理量」 / 「処理時間枠」 / 「性能向上の折れ点」 / 「ワイドグラフ幅」
実際の機能やソース上の意味を確認しながら、
日本語として自然であることと
技術的な意味を変えないことの両方を意識して整理しました。
今回提出した日本語 .ts ファイルは、早速 rc06 に反映されています。
DXCC名は「英語か日本語か」ではなく、選べる形に
今回、Tihomirさんと話をしていて興味深かったのが、 DXCC country/entity名の表示方法です。
JTDXではCountryDatに含まれるDXCC entity名も各言語へ翻訳できますが、 私はDXCC名については、LoTWやログソフト、CTYデータなどとの比較を考えると、 標準的な英語名称を基本にした方が扱いやすいと考えています。
「DXCC名は英語をデフォルトにして、必要な人だけ各言語表示を選択できる方式が良いのでは」 という考え方でした。
すると rc06 では早くも、 Translate DXCC names（DXCC名を日本語で表示） という設定が追加されました。
必要なら日本語表示を選ぶこともできる。
どちらか一方を強制するのではなく、ユーザーが選べる形です。
cty.dat と LoTW user list も設定画面から更新
さらに、データ更新について意見交換していた cty.dat の最新版ダウンロード と LoTW user list の最新版ダウンロード も、 Settings > General > Data files に実装されています。
このダウンロード機能自体はTihomirさんも以前から考えていたそうですが、 ちょうど話をしていた内容がすぐ rc06 に入ってきたので……
こちらのWindows環境でも、
日本語 .ts の反映、DXCC名の表示切替、cty.dat のダウンロード、
LoTW user list のダウンロード、ダウンロード済みデータの日付表示
まで実際に確認しました。
ダウンロードしたファイルを無条件に使うのではなく、 内蔵データとダウンロード済みデータを比較して、 新しい方を使用する仕組みになっています。
rc06 のそのほかの変更
- Band buttons の追加
- Dark style の改善
- QSO日付形式を
yyyy-MM-ddに統一 - Windows HTTPS download 関連の改善
- AppImage の DST 関連修正
まだ開発途中のJTDX_contest 3.0ですが、改良のスピードがかなり速く、 見ていて面白いです。
日本語についても、これまでのJTDXローカライズの経験を活かしながら、 できる範囲でお手伝いしていこうと思います。
73, Yoshi / JP1LRT
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
WSJT-X Improved 260908版が英語で起動する理由 ― 日本語で使用するには --language=ja を指定 ― 2026年09月11日 10時18分27秒
WSJT-X Improved 3.2 の 260908版を日本語Windows環境で起動すると、 これまでと違ってデフォルトでは英語GUIで起動することが分かりました。
最初は日本語translationの問題も疑いましたが、調査した結果、 これは翻訳ファイルの不具合ではなく、260908版で意図的に導入された 起動言語の仕様変更であることが分かりました。
DG2YCB Uweにも確認し、変更の経緯について回答をいただきましたので、 これから260908版を使用する日本のユーザー向けにまとめておきます。
■ 実際の動作
同じ日本語Windows PCで260818版と260908版を比較したところ、 次のようになりました。
| Version | 起動オプション | 起動言語 |
|---|---|---|
| 260818 | 指定なし | 日本語 |
| 260908 | 指定なし | 英語 |
| 260908 | --language=ja | 日本語 |
つまり、260818まではWindowsのシステムロケールに従って 日本語環境では自動的に日本語GUIが選択されていましたが、 260908では言語を明示しない場合に英語が選択されるようになっています。
■ ソースコードを比較すると原因は明確
260818と260908の完全なソースツリーを比較したところ、
原因は wsjtx/main.cpp の変更でした。
260818では次のようになっています。
L10nLoader l10n {&a, locale, parser.value (lang_option)};
この場合、--language が指定されていなければ、
通常のsystem localeを使った言語選択処理へ進みます。
そのため日本語Windowsでは日本語translationが自動的に読み込まれます。
一方、260908では次のコードに変更されています。
QString language_override = parser.value(lang_option);
// Default to English unless a language was explicitly requested.
if (language_override.isEmpty()) {
language_override = "en";
}
L10nLoader l10n {&a, locale, language_override};
コメントにも、
Default to English unless a language was explicitly requested.
と明記されています。
つまり260908では、言語オプションが空の場合、
system localeを参照する前に明示的に "en" が設定されます。
その結果、動作は次のようになります。
260818 言語指定なし ↓ system locale ↓ Japanese Windows ↓ Japanese GUI 260908 言語指定なし ↓ "en" を明示的に指定 ↓ English GUI 260908 --language=ja ↓ "ja" を明示的に指定 ↓ Japanese GUI
■ なぜこの変更が入ったのか
この点についてUweに問い合わせたところ、変更の経緯も分かりました。
Uweによると、複数の言語環境をインストールしたmacOSを使用している あるOMからの提案を受けて、
English should be the default everywhere.
という考え方に基づき、 言語を明示指定しなかった場合は英語をデフォルトにする 変更を行ったとのことです。
したがって260908版が日本語Windows上でも英語で起動するのは、 偶発的なregressionではなく、現在のWSJT-X Improvedで意図された動作です。
■ 日本語で使用するには
260908版を日本語GUIで使用したい場合は、起動時に
--language=ja
を指定してください。
Windowsのショートカットから起動している場合は、
ショートカットのプロパティを開き、
「リンク先」の wsjtx.exe の後ろに半角スペースを入れて、
次のようにします。
"C:\...\wsjtx.exe" --language=ja
実際のパスはインストール先によって異なりますので、 現在ショートカットに設定されているパスは変更せず、 その末尾に
--language=ja
を追加すればOKです。
例えば英語を明示的に使用する場合は、
--language=en
となります。
■ 日本語translationが削除されたわけではありません
ここは誤解しやすいところですが、 260908版から日本語translationが無くなったわけではありません。
実際に
--language=ja
を指定すれば、正常に日本語GUIで起動します。
つまり問題はtranslation resourceではなく、 起動時にどの言語を選択するかというselection logicです。
■ Best S&Pの言語依存問題修正とは別件
今回の件については、私が以前Uweへ送った Best S&Pのlanguage-dependent flaw修正との関係も念のため確認しました。
結論として、両者は無関係です。
Best S&Pの修正は、 翻訳された文字列そのものを比較してCQ priorityを判定していた部分を、 typed CQ priority valueによる比較へ変更したものです。
変更対象は主として
displaytext.cpp と mainwindow.cpp であり、
- QLocale
- QTranslator
- L10nLoader
- language command-line option
- translation loading
には触れていません。
Uweからも、
It was not due to your patch, Yoshi.
と明確に回答をいただいています。
■ 将来的にはGUIから言語切替も？
Uweはさらに、各言語のtranslation fileが継続的にきちんとメンテナンスされるのであれば、 将来的には「User Dark Style」のように、 メインプログラムのメニューから言語を切り替えられるようにしたい、 という考えも示しています。
これは実現すればかなり便利だと思います。
■ まとめ
WSJT-X Improved 260908版について、 日本語Windowsで英語GUIが表示されても異常ではありません。
260908版では仕様変更により、 起動時に言語を指定しなかった場合は英語がデフォルト になりました。
日本語で使用する場合は、
--language=ja
を起動オプションとして指定してください。
日本語translation自体は正常に収録されており、 このオプションを指定すれば従来通り日本語で使用できます。
WSJT-X Improved 3.2 / 260908で日本語メニューが英語で起動する場合の対処と原因 ― 2026年09月10日 07時48分31秒
WSJT-X Improved 3.2 / 260908で日本語メニューが英語で起動する場合の対処と原因
WSJT-X Improved 3.2.0 260908 AL PLUSを使用した日本人ユーザーから、 「これまで日本語だったメニューが英語表示になった」という問い合わせがありました。
同様の事象は別の日本人ユーザーでも確認されており、 日本語表示そのものが失われたわけではなく、起動時の言語選択の挙動が変わっていることが分かりました。
先に結論：日本語で起動する方法
260908で日本語GUIを使用したい場合は、起動時に次のオプションを付けます。
--language=ja
たとえばWindowsのショートカットを使用している場合は、「リンク先」の実行ファイル名の後ろに半角スペースを入れて、
"C:\WSJT\wsjtx\bin\wsjtx.exe" --language=ja
のようにします。 実際のインストール先は各自の環境に合わせてください。
この方法で260908でも正常に日本語表示になることを、複数の日本人ユーザーで確認しています。
260818と260908を同じPCで比較
原因を切り分けるため、私自身の日本語Windows環境で260818と260908を同じPC上でA/Bテストしました。
- 260818：言語オプションなし → 日本語で起動
- 260908：言語オプションなし → 英語で起動
- 260908：
--language=ja→ 日本語で起動
少なくとも私の環境では、260818と260908の間で、 「言語を明示指定しなかった場合のデフォルト動作」 が変わっていることが確認できました。
ソースを比較すると原因が見つかりました
そこで260818と260908の完全ソースを比較しました。
直接の違いは wsjtx/main.cpp にありました。
260818では次のようになっています。
L10nLoader l10n {&a, locale, parser.value (lang_option)};
この場合、--language が指定されていなければ空の値がそのまま L10nLoader に渡されます。
そのため通常のsystem localeによる言語選択が働き、日本語Windowsでは日本語GUIが自動的に読み込まれます。
一方、260908では次の処理が追加されています。
QString language_override = parser.value(lang_option);
// Default to English unless a language was explicitly requested.
if (language_override.isEmpty()) {
language_override = "en";
}
L10nLoader l10n {&a, locale, language_override};
つまり260908では、言語指定がない場合に "en" を明示的に設定するよう変更されています。
L10nLoader 側では "en" を明示的な英語指定として扱い、
system localeに基づくtranslationの読み込みをスキップします。
その結果、オプションなしでは英語GUIになります。
逆に --language=ja を付ければ "ja" が明示指定されるため、
日本語translationが正常に読み込まれます。
実際の挙動とソースの処理が一致
整理すると次の通りです。
- 260818：言語指定なし → system localeを使用 → 日本語Windowsでは日本語
- 260908：言語指定なし →
"en"を設定 → 英語 - 260908：
--language=ja→ 日本語
実機で確認した挙動と、ソース上の処理が完全に一致しました。
また、L10nLoader.cpp と L10nLoader.hpp 自体は260818と260908で変更されておらず、
言語・locale・translation周辺を確認した範囲では、今回のデフォルト動作を変える直接の差分はこの main.cpp の変更でした。
Best S&Pの日本語対応patchとは無関係です
260908には、私（JP1LRT）が提供したBest S&Pの言語依存修正patchも取り込まれています。 そのため当初、この変更との関係も念のため確認しました。
しかしこのpatchは、Best S&P内部で翻訳済み文字列を比較していた処理を、 言語に依存しない内部のtyped valueによる比較へ変更したものです。
QLocale、QTranslator、L10nLoader、
translation loading、--language の処理には触れていません。
ソースdiffでも今回の日本語GUI起動問題との直接的な関係がないことを確認しました。
これは「バグ」なのか？
260908のコードには、
// Default to English unless a language was explicitly requested.
というコメントがあるため、コード変更そのものは意図的に書かれたものと考えられます。
ただし、 「すべての非英語環境で、言語指定がなければ英語をデフォルトにする」 ことまで意図したユーザー向け仕様変更だったのか、 またその理由が何だったのかまでは、今回比較したソースだけからは判断できません。
したがって現時点では、これを「バグ」や「regression」と断定するのではなく、 260818と260908の間でデフォルトの言語選択処理が変更された という事実として整理しておくのが適切だと思います。
従来の自動言語選択へ戻す場合
もし260818までのように、言語指定がない場合はsystem localeに従う動作へ戻すのであれば、
main.cpp の処理を260818の形に戻すのが最小の修正です。
L10nLoader l10n {&a, locale, parser.value (lang_option)};
この形に戻しても、英語を明示したい場合の
--language=en
は従来通り機能します。
今回の解析結果についてはDG2YCB / Uweにも共有しています。
とりあえず困っている方へ
260908をインストールして「メニューが英語になってしまった」と困っている方は、 まずはショートカット等に
--language=ja
を追加して起動してみてください。 日本語translationそのものは正常に利用できます。
最初は単純な「日本語メニューが出ない」という問い合わせでしたが、 同一PCでのA/Bテスト、260818と260908のソース比較、 そしてtranslation loaderの処理を追うことで、今回の挙動の直接原因まで確認することができました。
73,
Yoshi / JP1LRT
ハムフェア2026、今年も2日間楽しんできました！ ― 2026年08月31日 09時22分49秒
財布を忘れて《詰んだ》ところから始まり、0次会、6m DXer懇親会、ARDC講演、関東UHFコンテスト表彰式まで。たくさんの皆さんにお会いできた、楽しい2日間でした 📡
昨日・一昨日は ハムフェア2026 に参加してきました。
今年も出展者証を持っていなかったので、10時の開場を待つ一般入場組。とはいえ、朝から長蛇の列に並ぶのは苦痛なので（笑）、初日は 10時30分ごろ到着 をターゲットに自宅を出発しました。
会場までいろいろな行き方がありますが、この日は外も比較的涼しかったので、りんかい線の国際展示場駅から歩いて向かうことにしました。
国際展示場駅に着いたところで《詰んだ》🤣
なんと……
財布を家に忘れてきました。
普段からあまり現金を持ち歩かない私ですが、さすがにハムフェアでは多少必要だろうと思っていたのに、その財布そのものがない（笑）
スマホケースの中には、非常用に入れてある エマージェンシー・キャッシュ5,000円。
そして夜には6m DXerの皆さんとの懇親会。その予算もだいたい5,000円。
……はい、使えません🤣
そんなことを考えているうちに、11時に予定されていた仲間との記念撮影の時間が迫ってきます。
もう歩いている場合ではないのでタクシーへ。運転手さんに「Suica使えますか？」と確認するとOK。普段から モバイルSuica を使っているので、ここは無事突破（笑）
なんとか記念撮影にも間に合いました 📸
記念撮影のあとは、そのままの流れで有明ガーデンへ。
しゃぶしゃぶの飲み食べ放題で、ビールをジョッキ 7杯 流し込み、牛肉と野菜もしっかりいただいて満腹。
さて問題の支払いですが……仲間に PayPayで送金。
財布がなくても、意外とどうにかなるものです（笑）
その後はハムフェア会場内をゆっくり散策。
普段SNSや無線でつながっている方、久しぶりにお会いする方、初めて直接ご挨拶できた方など、本当にたくさんの皆さんとお会いすることができました。
無線で声やコールサインを知っていても、実際に顔を合わせて話せるのは、やっぱりハムフェアならではですね 😊📡
18時からは秋葉原へ移動し、6m DXerの皆さんとの懇親会。
今年はブラジルから PY2XB Fredさん も参加されました 🇧🇷📡
宴会開始前にはFredさんとヨドバシカメラへ行き、Fredさんのスマートフォンケースと、奥様用のモバイルバッテリー選びにもお付き合い。
その後の懇親会では、6m DXの話はもちろん、いろいろと興味深い話を伺うことができ、とても有意義な時間になりました。
もちろん二次会にも参加 🍺🤣
そしてハムフェア2日目。
この日は昼ごろから会場入りしました。
メインステージで行われた
― イノベーション等を支える ARDC のビジョン ―」
のお話は、とても興味深く聞かせていただきました。
アマチュア無線を単に「今ある趣味」として見るのではなく、次の世代や技術、教育、イノベーションへどうつなげていくのか。
こういう話をハムフェアの場で聞けるのは、とても良いですね。
そして14時からは、第43回関東UHFコンテスト表彰式 を《見学》😅
なぜ《見学》かというと……
コンテスト当日の休みを申請するのを忘れてしまい、今年は参加できなかったから🤣
表彰される側には回れませんでしたが（笑）、多くのお知り合いの皆さんが表彰される姿を、拍手でお祝いしてきました 👏
2日目はそのまま帰宅。17時にはもう自宅でのんびりしていました。
今年のハムフェアも、2日間を通して、日頃から無線やSNSでつながっている本当に多くの皆さんとお会いすることができました。
直接お話しできた皆さん、ありがとうございました 😊
一方で、
という方も本当にたくさんいらっしゃいました。
あれだけ多くの人が集まるイベントなので、こればかりは仕方ありませんね。
今回お会いできなかった皆さんとは、ぜひ来年こそ！
人と人が直接会えることこそが一番の楽しみなのかもしれません。
今年も楽しい2日間でした。
皆さん、ありがとうございました！ 😊📡🍺
最近のコメント