論文一覧に戻る

査読者 1

総合点

8

確信度

2

コメント

人間に通知するための電子音を機械的に認識することで、自動処理の枠組みを構築することができるという提案は興味深い。また、電子音の認識が比較的容易であることを実装により示したことも意義があると言える。

本論文では電子音の発生源が1つの場合を取り上げているが、駅の自動改札のように、近い場所で同一の電子音が複数発生するような状況での応用にも是非取り組んで欲しい。

音響特徴量の抽出について、第3.1章ではパワースペクトラムやMFCC等の要素が混合した特徴量ベクトルが得られるように読めるが、表1や第4.2章では、パワースペクトラムやMFCCのいずれかを選択する必要があるように読める。前者の記述を改められたい。

第3.2.1章でセキュリティを考慮した対策が述べられているが、具体的にはsurlパラメータを許容しない点が対策になっているということなのか、十分理解できなかった。

第4.3章でDTWと直接比較を計算量の観点から比較しているが、平均的な計算量についてのみで、レイテンシに関する記述がない。アプリケーションによっては重要な要素と考えられるので、考察を追記して欲しい。

また、図6のキャプションが記述の途中で切れていることや、4.3章の「実験3」は「実験2」の誤りとみられるなど、論文として不適切な部分があり、修正が必要である。

加えて、以下のような点は読者にとって分かりにくいので、修正されることが望ましい。

- Dynamic Time Warping法について、具体的な説明や参照すべき文献が示されていない。
- 「コスト」と「特徴量ベクトル間の距離」の関係が明らかでない。
- 図3のグラフは、各軸の意味を明示すべき。
- 「パワースペクトラム」と「パワースペクトル」が混在している。

採録判定時のコメント

ゲームの効果音や電子音を認識してイベントのトリガーにするというアイデアは興味深い。比較的簡易な手法(JavaScriptを用いたローカルブラウザ上での動作)で十分な認識精度が出ることを示すと共に、Webサービスと連携しやすい実装方式であることも発展が見込める。一方で、使用されている認識手法は一般的なものであること、ブラウザ上で軽量に動作するという利点の説明が不十分であることなどから、ショート採録と判断された。

レビューサマリ

人間向けに設計された電子音を機械的に認識して、自動処理のトリガーとして利用するというアイデアや、比較的シンプルな手法で十分な認識精度が得られること、Webブラウザで動作することで既存のサービスとの連携が容易とみられることは、好意的に解釈されました。
一方で、ブラウザで軽量に動作するという利点が論文の記述からは十分に読み取れないこと、Dynamic Time Warpingの参考文献が示されていないこと、キャプションの記述が途中で切れていること等、論文としての完成度が低かった点がネガティブな印象を与えました。
これらの指摘を踏まえて、よりよい研究・論文に発展させることを期待しています。

その他コメント

査読者 2

総合点

5

確信度

2

コメント

既存のゲームを拡張する手法の一つとして,電子音をトリガにイベントを発生させることができるJavaScriptライブラリを提案している.

JavaScriptのみで実装されている点は興味深い。軽量かつWebブラウザ上で簡単に電子音の検出ができることは,多くの既存WEBサービスとの連携や実装のしやすさから発展性が高く,実証実験を通じて実用に耐えうる可能性があることが示唆されている点も評価できる.しかし,既存手法との差別点について論文から十分に読み取ることが難しく,本提案手法の優位性や新規性について疑問が残こるため「5: ショート採録が妥当」と判断する.


論文改善のためのコメント、疑問:
・古典的なテンプレートマッチングとしてDynamic Time Warpingを取り上げているが,参考文献として参照することで読者の理解が深まるので,追記して頂きたい.

査読者 3

総合点

7

確信度

2

コメント

本論文は、Web上で、ゲームの効果音などを検出し、各種イベントのトリガーとすることができるシステムの提案です。
・JavaScriptのみで記述されており、Webブラウザで実行可能なこと、
・シンプルさを保持しつつ、テンプレートマッチングの簡易な音声検出で十分な性能が出せることが示されている点
・フレームワークだけではなく実際のアプリケーション例も豊富に実装されている点、
などが評価できます。

今回の実装はプロトタイプのため、本質ではないとは思いますが、
3.2.1で示されている「URLにMeshbluのtokenとUUIDを直接指定する」手段は、
今後不特定のユーザがこのシステムを利用することを想定する場合には、妥当ではありません。
(他のサービス経由でIoTサービスとの連携を行う場合は、OAuthなどで認可を取得するべきです)
一般的なサービスとして検討していく場合には、考慮が必要と思います。