基本周波数抽出器 REAPERによる抽出実験

はじめに

とあるメーリングリストHTS-users に投稿があった：
[hts-users:04236] REAPER: the pitch tracker

音声のピッチ抽出器とのこと。せっかくだから試してみよう、というわけである。なお基本周波数の簡単な知識については先の記事を参考に。
<a href="http://tam5917.hatenablog.com/entry/2015/03/05/214305">基本周波数についてのまとめ - 備忘録</a>

REAPERについて

「Robust Epoch And Pitch EstimatoR」だから「REAPER」。

ソースコードとドキュメントが以下にある。
<a href="https://github.com/google/REAPER">google/REAPER</a>

説明

上記サイトより引用すると：

"The reaper program uses the EpochTracker class to simultaneously estimate the location of voiced-speech "epochs" or glottal closure instants (GCI), voicing state (voiced or unvoiced) and fundamental frequency (F0 or "pitch")."

（ざっくりとした訳）
”REAPERは有声音の基準点の位置つまり声門閉鎖点と、有声音/無声音の判定、そして基本周波数を同時に推定する「EpochTracker」である。”

なおGoogleのDavid Talkin氏がプログラムを書いたそうである。RAPTの論文の著者と同じ人物である。GCI（自分もまだ良くわかってない）については以下の論文が参考になるだろうか。
IEEE Xplore Abstract - Detection of Glottal Closure Instants From Speech Signals: A Quantitative Review
論文タイトルで検索するとPDFがヒットすると思われる。

ライセンス

うっかり見過ごされがちだが、フリーソフト利用にあたってライセンスの確認は「非常に重要」である。REAPERはApacheライセンス Vesion 2.0である。以下にApacheライセンス Version 2.0の要点を示す。

必須事項	ライセンスと著作権の表示、変更点を示すこと
許可されること	商用利用、修正、配布、特許の利用許可、派生物に別のライセンスを課すこと
禁止事項	商標の利用、作者に責任を求めること

(ライセンスの選択を恐れる必要はありません - Qiitaより引用)

ライセンス表示および著作権表示を忘れなければ、自由に自分のソースコードに組み込んで活用してもよいということであり、またそのソースコードを再配布してもOKということ。
(SPTKに組み込まれる日も遠くないのではと想像)

インストール

cd convenient_place_for_repository
git clone https://github.com/google/REAPER.git
cd REAPER
mkdir build   # In the REAPER top-level directory
cd build
cmake ..
make

指定可能オプション

オプションの種類	説明
-i	入力音声 (wav)を指定
-f	F0の出力ファイルを指定
-p	ピッチマークの出力ファイルを指定
-a	結果をアスキー形式で保存
-x	F0の探索範囲の最大値を指定
-m	F0の探索範囲の最小値を指定
-d	様々な分析結果を出力 (詳細省略)
-s	80Hzにおけるハイパスフィルタの適用を抑制
-e	F0の出力フレーム間隔を指定
-t	位相ひずみを抑制するためのヒルベルト変換を有効化

とりあえず、上記の-iから-mまでの６つのオプションを覚えておけばよいだろう。ピッチマークについては（めんどくさいので）ここでは説明しない。音声から推定できるパラメータの１種、という認識でスルーすればとりあえずおｋ。

基本周波数を抽出し、かつ結果をアスキーで保存したいときのコマンド例：

reaper -i /tmp/bla.wav -f /tmp/bla.f0 -a

出力ファイルの形式

-aオプションをつけたときのreaperの出力結果例を一部載せる。

先頭から７行にヘッダ部
データ部は（時刻有声/無声フラグ F0値）

有声/無声フラグは1が有声、0が無声である。また無声部のF0値は-1というマジックナンバーが割り当てられている。

EST_File Track
DataType ascii
NumFrames 236
NumChannels 1
FrameShift 0.00000
VoicingEnabled true
EST_Header_End
0.000000 0 -1.000000
0.005000 0 -1.000000
0.010000 0 -1.000000
(中略)
0.095000 0 -1.000000
0.100000 0 -1.000000
0.105000 0 -1.000000
0.110000 1 163.265305
0.115000 1 124.031006
0.120000 1 124.031006
0.125000 1 120.300751
0.130000 1 121.212120
(中略)

上記のように、REAPERはデフォルトで出力結果の先頭に７行ほどヘッダ(アスキー)をくっつけてくる。したがって出力結果をいじるときにはsedコマンドなどでヘッダを取り除く対処が必要となる。

実験

REAPERの挙動を確認するための基本周波数抽出実験を行った。ピッチマークについては今回実験しない（プロットがめんどくさい）。今後モチベーションが続けばやるかも。

実験条件

データ	SPTK example に同梱のdata.short
サンプリング周波数	16kHz
量子化ビット数	16bit
SPTKのバージョン	3.7
比較手法	RAPT, SWIPE', DIO, REAPER

なお、data.shortの内容は、男性話者により「青い植木鉢」を発声したときの音声波形データである。（はてなブログに音声を埋め込む方法がよく分からない(´・ω・`)　誰か教えてくれ）

STRAIGHTは入手方法がめんどくさそうだったので止めた。~~またWORLDはMac上でMakefileを動かしたとき、test.cppのコンパイルに失敗するするので止めた(´・ω・`) (LinuxとWindowsでしかコンパイルできないっぽい？)~~ 最新版のWORLDではMacでコンパイル可能。

使用スクリプト

SPTK使用。Python分かりません。

スクリプトと同じディレクトリにdata.shortとREAPERの実行バイナリ(reaper)、DIOの実行バイナリ(dio)が置いてある前提である。なおdioはWORLDに付属のサンプルソースのtest.cppを少し改造し、F0抽出機能のみを実行するようになっている。オリジナルのtest.cppをtest.orig.cppとし、改造後をtest.cppとしたときのパッチファイルはこちら。

実験結果

RAPT
- 実行時間
  - real 0.009 sec
  - user 0.006 sec
  - sys 0.001 sec
- 抽出結果

f:id:tam5917:20150306192811p:plain

SWIPE'
- 実行時間
  - real 0.013 sec
  - user 0.006 sec
  - sys 0.001 sec
- 抽出結果

f:id:tam5917:20150306192813p:plain

DIO
- 実行時間
  - real 0.019 sec
  - user 0.016 sec
  - sys 0.001 sec
- 抽出結果

f:id:tam5917:20150307192422p:plain

REAPER
- 実行時間
  - real 0.178 sec
  - user 0.175 sec
  - sys 0.002 sec
- 抽出結果

f:id:tam5917:20150306192812p:plain

考察

実行時間は早い順にRAPT < SWIPE' < DIO << REAPERである。また実際の抽出結果については、まずRAPTには発話開始後すぐに有声/無声の判定誤りが見られる。また、SWIPE'とREAPERについては発話の最後の部分「うえきばち」の「ち」付近で判定誤りが起きている。DIOについてはこれらの判定誤りは観察されない。SWIPE'とREAPERのF0軌跡はほぼ類似しているが、SWIPE'のほうがより滑らかな軌跡が得られている。SWIPE'により過剰に平滑化されているのか（＝抽出が甘いのか）、REAPERやDIOが精度よく抽出できているのかの判断は現時点ではできない（評価基準はこれから勉強予定）。DIOはRAPT、SWIPE'、REAPERともF0の軌跡の傾向が異なっているのは興味深い。

おわりに

本稿ではREAPERによる基本周波数抽出実験についてまとめた。実験の結果、REAPERは他のコマンドと比較するとあまり高速ではないことが判明した。基本周波数の抽出という目的で数多くの音声ファイルをスクリプトで一括処理する状況ではやや不利である。とはいえ、ピッチマークの抽出など他にはない分析も可能であるから、アプリケーション次第では便利な場面も出てくるだろう。というかピッチマーク抽出器として割り切って使うほうがよいかもしれない。

今後の課題はピッチマーク抽出実験およびその評価である。