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個のテスト音声

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の方が性能が出る

特徴の深さ
- DNNは深くなるほど，性能が悪くなる(EER: 10.31%)
  - 理由はおそらくDNNは音素の状態の事後分布でチューニングされるせい
- RBMは層数が4がもっとも性能が良い(EER: 9.75%)
  - 真ん中の隠れ層を特徴量として達成しているのが面白い

テキスト独立の話者照合

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に教師なし学習(入力を復元するように学習)するだけで，話者を識別するような特徴を取ってこれるのか疑問だったが，結果が出ているなら何らかの特徴は取れている模様

2014-09-16

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

2014-09-05

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で数値にした後に比較する関数を定義してソートするだけ．

無視する文字列の長さが決まっていて固定的ならこれでいい気はしますが，長さが変わるような可変的な場合はどうすればいいか分からないですね…．

2014-09-04

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のものに変換している．

2014-07-09

MacのLocal環境でTerminal作業するときに，東アジア文字幅問題の沼から抜け出す

メモ

Mac(Mavericks)を使い始めました．WindowsとLinux出身者なので，慣れません．
それでも，Macで快適にTerminalで作業したいと思って，iTermとか入れて，Localでの作業環境を整えようとしました．
すると，UTF-8の東アジア文字幅でambiguous widthなものの表示がズレておかしくなるので，それを修正する話です．

修正すると言っても，場当たり的な修正です．
ロケールのファイルも上書きしてしまうので，アプリとかとの連携が取れない場合もあるかもしれません．
自己責任でお願いします．

Macを使ってターミナルで作業していると ambiguous width の文字がたまにあって表示がおかしくなります．
ambiguous width の問題についてググっても，「iTermでオプション有効にしたら解決した」って記事ばかり出て来て，「そんな馬鹿な」「このMacは本物のMacか？」という状態になってました．
結局，研究室の先輩に助けてもらいました．

まず問題について，sshでつないだ先(ロケールいじってambiguous widthは2で統一してある環境)だと表示ズレが起きないのに，Localで作業すると，表示ズレが起きました．
これはiTermでのオプションのambiguous widthを2で扱うっていうオプションをオンにしても改善されませんでした．
そのため，Macで文字幅を指定してしていそうなファイルをいじることにしましたが，一体どれが該当ファイルなのか分かりませんでした．
研究室の先輩によると，MacはBSD系らしいので，Linuxの構成はあまり参考にならない模様．結果的に，FreeBSDでの文字幅の問題について調べてもらい，解決案を頂きました（本当にありがとうございます）．

### FreeBSD用で，ambiguous widthを2に変更したロケールのソースファイルを落とす
$ wget http://sourceforge.jp/projects/mutt-j/scm/svn/blobs/146/mutt-ja-doc/trunk/samples/UTF-9.src?export=raw -O UTF-9.src
#### localeのバイナリのファイルを作成
$ mklocale -o ~/LC_CTYPE UTF-9.src
$ cd /usr/share/locale/
$ su
### UTF-8のlocaleファイルに上書き
# cp /usr/share/locale/UTF-8/LC_CTYPE /usr/share/locale/UTF-8/LC_TYPE.bak
# cp ~{LC_CTYPEを置いたUser}/LC_CTYPE /usr/share/locale/UTF-8/

短いですが，これで完了です．
iTermとかも再起動すれば，多分反映される気がします．

最初は，UTF-9(コンパイルし直したLC_CTYPEを置く)やja_JP.UTF-9(LC_CTYPE以外はja_JP.UTF-8の構成をコピー)というディレクトリを作って，LANGやLC_ALLをja_JP.UTF-9に変更して，使おうとしましたが，他のアプリとの連携がとれないらしいので，結局UTF-8に上書き安定になりました．自分は忘れましたが，戻せるようにバックアップは取って置いた方がいいです＾＾；
(ちなみに，ja_JP.UTF-9にja_JP.UTF-8と同じ構成にしないと，LANGとLC_ALLの変更は出来ませんでした．)

あとは，私事ですが，screenをGitから落として，コンパイルしたのを使ってます．
その場合，UTF-8-MAC問題に出くわします．
この問題に対処した先駆者がいたので，URLを張って置きます．
https://sites.google.com/site/togino77/home/screen-410

なんというか，上の作業は意味ない感じになった気がします＾＾；
結構この記事もリファレンスされているっぽくて，有名な問題だったみたいですね…．

自分が修正したときは，こんな感じになりました(ansi.cの箇所が1行ズレただけでした)．

 --- ansi.c
 +++ ansi.c
@@ -726,6 +726,10 @@
                      LPutChar(&curr->w_layer, &omc, ox, oy);
                      LGotoPos(&curr->w_layer, curr->w_x, curr->w_y);
                    }
 +               if( curr->w_mbcs)
 +                         {
 +                                       curr->w_rend.mbcs = curr->_mbcs = 0;
 +                         }
                  break;
                }
              font = curr->w_rend.font;
 --- display.c
 +++ display.c
@@ -603,7 +603,7 @@
            D_x += D_AM ? 1 : -1;
          D_mbcs = 0;
        }
 -      else if (utf8_isdouble(c))
 +      else if (utf8_isdouble(c) || (0xdf00 <= c && c < 0xe000))
        {
          D_mbcs = c;
          D_x++;

ansi.c とdisplay.c を修正しないとダメっぽいです．
変更箇所の位置はそんなに変わってませんでしたが，git から clone してきた段階で自分でソースを見て，判断するしかない気がします．
上記のサイトにならって，patch を書こうかとも思いましたが，すぐに意味なくなるかもしれないので，やめました．

デタッチしたときの utmp のエラーを出さないようにすることも出来るようで，下の diff みたいに，acconfig.h を修正する必要があるみたいです．
https://gist.githubusercontent.com/yujinakayama/4608863/raw/75669072f227b82777df25f99ffd9657bd113847/gistfile1.diff

とりあえず，これで文字幅の深い沼から少し抜け出した気がします．

[References]
http://www.csie.ntu.edu.tw/~r92030/project/big5width/
https://github.com/jj1bdx/mutt-ja-freebsd-private-port/blob/master/mutt/mutt-1.5.21-ja.1/UTF-8.txt
http://en.sourceforge.jp/projects/mutt-j/wiki/FreeBSD%E3%81%AEwcwidth
https://sites.google.com/site/togino77/home/screen-410
https://gist.githubusercontent.com/yujinakayama/4608863/raw/75669072f227b82777df25f99ffd9657bd113847/gistfile1.diff

考え中

営業なのに営業力が皆無のためゲーム作って癒やされたい。

とりあえず教本読む

来週から頑張ります

Speaker Verification with Deep Features を読んだメモ

適当な要約

関連研究

DNNへの入力