トロッコに乗って落ちるだけ
とりあえず、ほとんど教本の内容をなぞっただけのゲームを試しに作ってみました。 素材は一から。あとで差し替えたい。
https://kbbr.github.io/TramGame/
1週間に1度は更新していこうと思っていたのですが、立て込んでしまいました。 というか公開方法を調べるのに手間取りました。 もうレンタルサーバーとか借りてしまったほうが良い気がします。
そして試しに作ってみたはいいものの、色々と課題が多いっぽい。
とりあえず教本読む
書店に行って、教本あさってきました。
事前にネットサーフィンして、Unityというのが最近の流行りのようなので、Unityの教本を探してきました。
すっごい分かりやすそうなので、しばらくはこれを読みます。
今更ですが、プログラムを書くだけじゃなくて、絵とか音楽も重要なんだなーと。
絵はまあ頑張るとして、音楽はセンスをまったく授かっていないので、フリー素材かなーと思ってます。
Speaker Verification with Deep Features を読んだメモ
Speaker Verification with Deep Features
Yuan Liuら，IJCNN，Jul 6-11， 2014．
適当な要約
GMM-UBMモデルの入力にPLP + Δ + Δ (計39次元) 以外にも，DNNとかRBMで獲得した特徴量も連結して
GMM-UBMを最尤推定 -> MAP推定 -> 対数尤度比で照合
ってやったら連結する方が結果良くなったよ．
関連研究
- Deep Networkからのfeature extraction
- softmax層の出力である事後確率を使うtandemアプローチ
- 最終層での出力の重み和
- もしくはbottleneck層を使って，bottleneck層前への出力の重み和
- softmax層の出力である事後確率を使うtandemアプローチ
DNNへの入力
- scalable approach
1. 全学習データをDNNへの入力として学習
2. 最終層へ入力される(sigmoidに掛けられる前の)重み行列を掛けられた合計の値(weighted sum)
-> 主成分分析(次元削減)
-> 元々のDNNへ入力していた特徴量とつなげる
3. DNNで抽出された特徴量をGMM-HMMでモデル化する
DNNを話者照合で使う方法について
1. model-based
2. feature-based
1. model-based
-
- 分類器か他の分類器の補強として使う
- 基本的に，話者毎に別のNNを構築する必要があり，そのせいでrobustではないし，話者が増えるごとにパラメータ数が増加する
2. feature-based
-
- 問題点: DNNの学習時のラベルに何を選ぶかが不明
- GMM-UBMモデルを学習させるための特徴量となるbottleneck featureを抽出(input: context-frame feature vector, output: speaker id)
- しかし，bottleneck featureだけだと，base systemよりも性能が悪い
- back-end側でbottleneck featureとoriginal featureを組み合わせたスコアリングをすると性能がよくなる
- phone-labelを使ってニューロでfeature extractionをしているものがない(Jul 2014)
- 話者照合でもニューロでfeature extractionしているものもない
Deep Tandem Features fro Speaker Verification
- DNN Tandem Feature(supervised)
- 音素依存のネットワークだと，出力層に近い層は話者依存性が少ない．
- それは話者情報が音素依存になるように出力されるため．
- そのため，最後の隠れ層のfeatureの方がパフォーマンス上悪く，真ん中くらいの隠れ層のfeatureの方がよい．
- RBM Tandem feature(unsupervised)
- 入力特徴量をより正規的に，識別しやすいような特徴にモデル化し，(DNNに比べ)音素にあまり依存しないようにする．
- このTandem featureはfront-endレベルかback-endでのスコアリングのレベルで，元々の音響特徴量と組み合わせて使う．
- front-endなら，元々の音響特徴量につなげるだけで，back-endなら，Tandem featureと音響特徴量を別々のシステムとして構築して，2つのシステムからのスコアを重み平均をとって，クラスタリングする．
実験
- Dataset(for UBM):
- 学習: NIST SRE 2005 1-conversation(male only)
- 274話者のデータが9時間分
- 1 audio file: about 2 minutes(after voice activity detection)
- 評価: NIST SRE 2006 core condition(male only)
- 352話者のtarget話者(1話者2分間の音声)
- 645個のテスト音声
- 学習: NIST SRE 2005 1-conversation(male only)
- Dataset(for DNN or RBM):
- 学習: switchboard English data set
- 特徴量(39次元):
- 13次元のPLP係数(10msecごとの) + Δ + Δ
- 同一話者のPLPセグメントは全部つなげて，1ファイルにして，平均と分散の正規化を行う
- UBM(512-components)
- NIST SRE 2005でUBM学習 -> NIST SRE 2006のtarget話者の(テスト音声とは別の)登録用音声でUBMをMAP適応
- test
i) targetモデルとUBMモデルを使ってフレーム単位での平均対数尤度スコアの2つを導出
ii) その2つのスコアの差が最終的なスコアとなる．
-
- c.f. GMM-UBM のEER は11.18%
- DNN(RBM)
- 隠れ層: 7層(2048ノード)
- 入力層: 429ノード(11 PLP feature フレーム)(= 39 * 11)
- 対象フレームに対し，前後5フレーム
- 出力層(DNN): 9296ノード(tri-phoneの状態)
- cross-entropy，L-2ノルム(weight-decay term: 10^-6)
- この論文でのDNNとRBMの違い
- DNN: RBMを積み上げて，一番上の層のRBMだけ出力層を各音素のtri-phoneの状態の確率にしてback-propagationで学習．
- RBM: RBMを積み上げて，教師なし学習(layer-wiseに入力を復元するpre-trainingをするだけ．多分)
- ざっくり言うと
- DNN: 音素依存の教師ありdeep feature
- RBM: 教師なしのdeep feature
- deep feature
i) Projection Dimension of Deep feature
-
- 39 PLP feature(11 frames) -> 2048 deep feature -> PCA(20 or 39 or 78 dimension)
- RBMでの教師なしdeep featureの方が良い性能: 10.33%(best: 39-dimension)
- DNN: 14.82%(best: 78-dimension)
ii) PLPとdeep featureの組み合わせ
-
- feature level:
- PLPとdeep tandem featureをつなげる
- RBMの方が性能が出る
- score level:
- deep featureでのGMM-UBMモデルとPLPでのGMM-UBMモデルのスコアを重み和を取る
- 重みは良いスコアに0.7，悪い方のスコアに0.3を掛けあわせ足し合わす．
- DNNの方が性能が出る
- feature level:
- 特徴の深さ
- DNNは深くなるほど，性能が悪くなる(EER: 10.31%)
- 理由はおそらくDNNは音素の状態の事後分布でチューニングされるせい
- RBMは層数が4がもっとも性能が良い(EER: 9.75%)
- 真ん中の隠れ層を特徴量として達成しているのが面白い
- DNNは深くなるほど，性能が悪くなる(EER: 10.31%)
テキスト独立の話者照合
- GMM-UBM(512 components)
- 学習: 携帯電話音声12.5時間
- 登録
- 51話者で登録
- 同じテキストの音声(3sec)を3発話で登録
- テスト
- 全部で7140ファイル
- 7発話(1発話が本人，6発話が詐称者)
- 詐称者の6発話の内，2つは本人が登録とは別のテキストの音声を，別の2つは詐称者が登録と同じテキストの音声を，
- 最後の2つは詐称者が別のテキストの音声を発話したもの
- 結果
- RBMの方が性能がよい(EER; RBM: 0.88%, DBN: 0.98%)
- PLPとDNNで組み合わせても，PLPだけの方が性能がよい
- 理由はPLPだけでも十分にEERが低すぎたため
所感
- 結果について
- 教師なし学習させたRBMを多層に組んで，その中間の隠れ層の値を特徴量にした方が結果が良い．
- RBMでの特徴量だけでは性能がそこまで良くない，そのためハイブリッド的に元々の特徴量とつなげて拡張した特徴量を用いた方が良い．
- その他
- RBMとかDNNをどう組んだのかさっぱり不明
- RBMへの入力にPLPを使っているが，PLPは実数値のはずで，論文だと平均と分散の正規化をしたとしか触れてない．
- どんな正規化をしたのか知りたい．
- そもそもRBMは入力も2値を仮定したモデルだった気がする
- RBMをlayer-wiseに教師なし学習(入力を復元するように学習)するだけで，話者を識別するような特徴を取ってこれるのか疑問だったが，結果が出ているなら何らかの特徴は取れている模様
molokaiのカラースキーマを背景が端末の色に沿うように少し弄るメモ
vim を使うことになったので，ついでにカラースキーマもネットで評判のmolokaiを使うことにしました．
それで端末エミュレータを半透明にして普段作業しているのですが，普段使っている端末だとmolokaiの背景色で塗りつぶされて，
vim を開いているときだけ，(色が強過ぎて)半透明になりません．
そのため，molokaiのカラースキーマを少しいじって，半透明になるようにしました．
これは，そのときのメモ．
目標は，vimの通常の背景色をなくして，行番号の背景色もなくすこと．
ちなみにvim のカラースキーマの設定には全然詳しくないです．
大体143行目くらいのNormal のctermbg をnone にして，230行目のLineNr のctermbg をnone にしただけでした．
if &t_Co > 255
if s:molokai_original == 1
"... 3行くらい色々書いてある"
else
hi Normal ctermfg=252 ctermbg=none
"...その他色々"
endif
"...色々"
hi LineNr ctermfg=250 ctermbg=none
python2で文字列と数値が混在したリストをsortする
Linuxで言うところのコレ．バージョンのソートっぽいもの．
$ echo -e "foo1\nfoo2\nfoo11\nfoo20" | sort -V foo1 foo2 foo11 foo20
もちろん普通のsortでは上手くいかない．
$ echo -e "foo1\nfoo2\nfoo11\nfoo20" | sort -n foo1 foo11 foo2 foo20
このバージョンのソートには文字列と数値が入り混じるので，
python2の組み込みのsort，sortedで無理やりソートしたときのメモ．
def numeric_cmp(x, y):
return cmp(int(x[3:]), int(y[3:]))
hoge = ['foo1', 'foo11', 'foo2', 'foo20']
hoge.sort(cmp=numeric_cmp) # もしくは sorted(hoge, cmp=numeric_cmp)python2系だと，ユーザ側で比較関数を定義出来るので，それを利用．
単に比較する数値のところだけをスライシングして，intで数値にした後に比較する関数を定義してソートするだけ．
無視する文字列の長さが決まっていて固定的ならこれでいい気はしますが，長さが変わるような可変的な場合はどうすればいいか分からないですね…．
ffmpegでwavデータをG722音声符号化でエンコード
ffmpegのオプション，いつも覚えにくいなって思っています．
manを見れば大体良いのですが，時間掛かるので，メモ．
ffmpegで変換できるG.722の形式は多分こんな感じ．
- G.722
- 16KHz, 16bit, 64kbps
$ ffmpeg -i [入力ファイル] -acodec g722 -ar 16000 -f g722 [出力ファイル]
-
- -i は入力ファイルを指定するやつ．
- -ar でサンプリング周波数与えないと，多分ダメ(もともとのwavのサンプリング周波数のまま？)
- -f オプションでg722 の指定は要らないかも．manには自動検出するって書いてある．
音声処理するときはwavを扱うので，
$ ffmpeg -i [g722ファイル] [wavファイル]
こんな感じでwavにして扱っている．
他にも，よく使いそうな感じだと
$ ffmpeg -i [入力wavファイル] -ar 16000 -ac 1 [出力wavファイル]
見たいな感じで入力wavファイルを，サンプリングレート16k，チャンネル数1のものに変換している．
