-----------------------------
review comment 1
-----------------------------
■ 総合点
3
■ 確信度
2
■ 査読コメント
歌詞をベースに類似曲を見つけたいというモチベーションに対し、ソフトウェア的に十分に行き届いた実装がされていると見られ、評価できる。

しかし、論文の主要部分が形態素解析とソフトウェア実装に関する言及に占められており、動機となる歌詞検索そのものに関する言及があまり見られないのがやや残念である。例えば曲に対しての歌詞の影響度合い、実際にどの程度需要が見られるか、など。

参照論文にあるTextAliveは、歌詞に対して視覚的な演出を加える事により、表現者が歌詞の解釈を可視化して配布できるなどの明白なメリットが見られる。また、ありがち度の推定の場合、国内ポップソングに対する歌詞の類似性の指摘が話題となっている昨今、使う動機があると考えやすい。

今後、LyricListPlayerをベースとして曲と歌詞のマッチングや、ユーザが歌詞検索に対してどの程度、どのような動機を持つのかといった研究の発展性に期待する。
■ レビューサマリー
論文内容および実装方法に関して疑問はなく、アプリケーションの完成度も高いという評価だった。
しかし、「歌詞を起点にザッピングがしたい」という動機について議論が不十分だというのが査読者共通の意見となった。発表においてはこの点について議論を深められるような内容を期待する。



-----------------------------
review comment 2
-----------------------------
■ 総合点
3
■ 確信度
3
■ 査読コメント
本研究は歌詞を手がかりにして能動的に選曲するインタフェースを提案しています。研究全体の構成は妥当なものであるように思いますが、新規性・有効性その他いずれの観点から見ても採録に推すにはやや弱いように感じます。私が本論文を採録に推すには弱いと感じた点を以下に箇条書きします。

・歌詞の内容に沿って例えば「夏の歌」「旅の歌」を集める、といったアルバムは昔からあることで、歌詞に沿って曲を集めるという考え方自体に強い新規性は感じません。トピックモデルを採用して歌詞の共通項となるトピックを自動検出するという仕組みにも、既存技術から容易に派生しうるものであると考えます。
・ユーザインタフェースにもWISSの採録に十分たる新規性は感じません。他の人が実装してもこれに似たインタフェースになることが容易に予想されます。
・3章に示されている自然言語処理手法は既存手法の組み合わせという色が強いように感じます。これが例えば、歌詞の言語的特徴に特化した手法が示されていれば興味深かったように思います。あるいは、リアルタイムで局所的な歌詞の結びつけを実現するための自然言語処理が本研究の主たる貢献ということでしょうか。もしそうだとしたら、それ自体はインタラクティブシステムの会議で登壇発表して聴衆の興味を惹きつけるものになりえるのでしょうか。この原稿からは私には伝わりませんでした。
・形態素の数や順序をGUIでユーザに選択させる、というのは手法として弱い気がします。自然言語処理に詳しい人ならともかく、それ以外のユーザにこの選択を委ねるのは無理があると思います。
・実際にどのような楽曲順がどのような実行環境で何秒以内に生成されたか、といった実験結果が示されていないので、有効性を前向きに高く評価して採録に推す、ということも難しいように思います。
・歌詞の局所類似性にもとづいて楽曲を再生する、というインタフェースは確かに私の知る限り普及していませんが、提案手法が普及すれば本当にリスナーはそのような音楽を聴きたくなるのか、といった点について議論が浅いように思います。未来ビジョンの最終段落にこの点が言及されていますが単に「これまでに研究がない」としか書かれておらず、未来ビジョンが本論文を補足する役割を果たしていない（＝このままだと未来ビジョン欄を削除しても痛くない）ように思います。

以上の点のうち何個かでも光る点があれば、より強力な論文になるのではないかと思います。あるいはもし私が誤解している点があるとしたら、論文の書き方に改善の余地があるのかもしれません。もし採録されましたら、その点を検討して最終原稿を作成して頂ければと思います。



-----------------------------
review comment 3
-----------------------------
■ 総合点
3
■ 確信度
3
■ 査読コメント
再生中の曲の歌詞に局所的に類似している楽曲について，一覧表示してザッピングするための方法について，整った形式で記載されている論文であるとおもいます。ただ，追加記述があるほうが望ましい項目があります。

このような状況が必要／便利な状況について，査読者は想像できるものの，それが著者の想定しているものと一致しているかについて不安があります。単に「新しい鑑賞体験」という記載ではなく，どのような目的／利益／楽しさがある鑑賞体験であるかの補強をしていただかないと，LDAのトピックの配分を，形態素のモデル（意味の表現）に使ったことの妥当性が十分にはわからないため，他の実装方法ではいけない理由が十分には分かりませんでした。たとえば，Suffix Arrayなどの効率のよい（が，文字としてしかマッチングできない）方法が，応用上問題があるかどうかについて，知りたいと思いました。
　LDAを用いて，表層的には違ったものをとれるのは，望ましいということが暗黙の主張にあると推定できますが，問題設定は「歌詞で」ということですので表層的なマッチングでも，設定した状況は満足できるようにもおもいます。表層的なマッチングで不都合がおきる理由が査読者には十分にはわからないのは，著者らがマッチングに対して必要と考えている条件が，論文に明示されていないという欠点があると推定しています。
　LDAの扱いについても，知りたい項目があります。通常は，LDAのトピック分類に対して，名詞，動詞，形容詞だけを選んでいたのは，他の品詞で計算することが難しいのではなくて，その結果を利用することによってトピック分類にノイズが加わることが理由と考えられるため，「すべての形態素に対して距離を定義したいから全部を使う」という説明は，その判断の妥当性について疑問を生じます。いくつかのサンプルがどのようなトッピックに分類されていて，それが妥当であるかどうかが気になります。とくに，「名詞，動詞，形容詞」＊以外＊も計算することを主張しているのですから，それが応用上に意味のある配分をあたえていると思えるかどうかは気になるところです。
　なお，LDAをつかったマッチングについては先行研究で引用されて，引用文献ではトピック数は５ということが明示されていますが，この論文では明示されていません。LDAのトピックの数をどのような理由で，いくつを選んだのかを記載しないと，LDAの振る舞いが読者に了解できない可能性があります。もし，LDAの部分は引用されたものと同じであるのならば，そのように記載することもできるとはおもいますが，その場合は，LDAの記述の部分は本稿より縮小すべきとおもいます。または，それとの差があるならば，それが明確になるように記述するべきとおもいます。
　最後に，引用されたLDAによるマッチングの報告との最大の差分は，実時間で処理が可能となるようなインタフェースと考えられますので，これのための前処理や，それに要する前処理上のコスト，また，実行時のインデックスの大きさと，曲の増加に対するスケーラビリティを含めて知りたいとおもいます。今回の主張点をサポートするには，これらもLDAの詳細以上に読者に提案のシステムを理解してもらうときに重要なような気がします。