4K ミクさんを見る方法

4Kミク

暮れのミク界隈をこんなニュースが駆け抜けた:

4K番組『初音ミク「マジカルミライ 2014」LIVE&MAKING』は、Channel 4Kで1/9（金）から、毎週金曜午後2時よりご覧いただけます！ http://t.co/hoK8m8ruGz　#マジカルミライ　#初音ミク pic.twitter.com/FaKqe1b5B7

— 初音ミク マジカルミライ 公式 (@magicalmirai) 2014, 12月 22

自分はちょうど 58Z9X 買ったところ。
来年一年かけて4KのPCゲーム環境を揃えるつもりで、テレビ放送やコンテンツは全く対象外…だったのだけれども、勢いで視聴環境を整えてしまったｗ
せっかくなので、後続の方のために視聴方法をまとめておきます。
自分の知識と経験を誠実に記述しますが、この通りにやって見れなくても責任は持ちませんので悪しからず。

---

4K放送を見るために

4Kミクは Channel4K というチャンネルで放送される。
視聴には、「4K動画を見れる」だけでなくて「Channel4Kを見れる」ようにする必要がある。
このプラスアルファが結構ややこしい。

結論から言うと次のデバイスが必要:

• HDMI/HDCP2.2対応4Kディスプレイ(テレビ)
• Channel4Kチューナーとスカパー！のICカード
• 124/128度CSアンテナ(スカパー！プレミアム用アンテナ)

---

各機器の説明

各機器が何を行うのかを把握しておくと、自分なりに組み合わせられるはず。
とにかく見れればいいから製品教えろという方は飛ばしておｋ。

124/128度CSアンテナ

Channel4K は JCSAT3A/4B 衛星から放送されるので、まずこれを受信できないとならない。
JCSAT3A/4B はスカパー！プレミアムの放送衛星としても使われており、このアンテナで受信できる。

共聴アンテナは Channel4K のサイトに受信可能なタイプがあるのでそれを参照。
あといくつかの CATV では、Channel4K の再配信を行っているそうだ(PDF)。
これらの CATV を視聴できる場合はアンテナは不要であろう。

既存のアンテナで124/128度CSを受信できず、対応 CATV も通じていない場合は自前でアンテナを付けることになる。
マンションだと室外は共有部分なので、アンテナを取り付けるには管理組合の同意が必要ね。もちろん賃貸ならオーナーの。 今時ならアンテナ設置はルール化されてるだろうから聞けば分かると思う。

Channel4Kチューナーとスカパー！のICカード

放送を受信できたら次は、そこからメディアデータを取り出すことになる。
これをやってくれるのがチューナーで、復調からスクランブル解除、映像音声のデコードまで行う。

放送信号にはスカパーのスクランブルがかかっているため、復号のためにスカパーのICカードが必要になる。
さらに、ICカードの有効化のために Channel4K を放送している NexTV-F との契約が必要。スカパーとの契約は不要。

なお、チューナーは放送局毎に必要になる。
ソフトウェアレベルの差異であれば、将来のチューナーのファームウェアアップデートで対応可能。
見えているところでは、ひかりTV VOD やスカパー4K放送はおそらく対応されるであろう。
2K本放送がソフトウェア更新ですむかどうかは分からない。

HDMI/HDCP2.2対応4Kディスプレイ

Channel4K では、チューナーからデジタル映像音声出力する際は HDMI を用い、HDCP2.2 で保護する必要がある。アナログ映像出力は禁止。
よって、映像を見るためには HDMI/HDCP2.2 で接続する必要がある。

なお、リムーバブル記録媒体への出力方式はまだ既定されていないため、外部機器へのムーブやダビングはできない。

Channel4K の映像形式は 3840x2160@60 4:2:0/8 であり、これをフルで伝送するには HDMI2.0 (HiSpeed HDMI ケーブルも)が必要。
HDMI1.4 で繋いだ場合は 30Hz など品質が落とされるであろう。
実際には、HDCP2.2 対応のインターフェースは HDMI2.0 にも対応していると思う。

Channel4K は色は 4:2:0/8 ですけど、本放送は 10bit になる予定です。色形式も 4:4:4 になるかも？
本放送をフルスペックで見るところまで見据えると、4:4:4/10 対応までチェックしておかないといけません。現行製品であるんかな？

---

具体的な製品

124/128度CSアンテナ

スカパー！プレミアムが見れるアンテナなら何でもいけるであろう。

スカパー！プレミアムの新規加入を条件に、アンテナと工事代金を割り引いてくれるキャンペーンやってるので、それ使ってもいいかと。

ちなみに自分はこのキャンペーン使いました。
窓越え用の細いケーブル代が3000円ちょっとと割高だったけれど、アンテナ取り付けの手間省けたのでまぁよいかな。
スカパーも4K放送のために加入するつもりだったし。

Channel4Kチューナーとスカパー！のICカード

チューナーは選択肢が少ない。

Channel4Kのサイトにも書かれているけれど、次の3つ。

• SHARP TU-UD1000
• Sony FMP-X7
• TOSHIBA REGZA Z10X

テレビとして Z10X があるならその内蔵チューナーを使えばよろしい。
チューナー内蔵でない場合は TU-UD1000 か FMP-X7.
BS/CS のチューナーとレコーダも欲しいなら TU-UD1000 も選択肢に。
FMP-X7 はUSBメモリからの動画・ハイレゾ音声の再生や、4K放送の音声をHDCP2.2しないで出力できるのが人によっては魅力かと。

HDMI/HDCP2.2対応4Kディスプレイ

2014年になっていくつか 4K モノが出てきている。
Channel4K 見るなら HDMI2.0/HDCP2.2 対応かどうかを要チェック。

いわゆる 4K(対応)テレビは、2014年春以降ならたぶん大丈夫。
Z10X ならチューナー付き。

PCモニタだと DELL の P2415Q/P2715Q のみ？

4Kプロジェクタは知らん。

うちの例

アンテナはスカパープレミアムのキャンペーンで。
まだ入会してないけど安い番組ひとつ取るだけかなー。

チューナーは FMP-X7.
録画用に HDD 2TB 付けてます。
試験放送の 35Mbps なら 133時間分で万全とはいい難いが、しばらくは持つであろう。
あと4K動画ファイルをUSBメモリからHDDに移して視聴できるので、MMD 4K とか見るのにも手軽。

テレビは 58Z9X.
綺麗でとてもよいものです。

MIKUNOPOLIS

行ってきましたわー

いやー、素晴らしかった。

個人的には、出来が良い体験ほど文字にしたり記録を残すことを避けたい性格なんだけれど、今回は日本語の情報量は少なくなりそうなので記録にちょっと貢献しましょう。
時系列に思い出しながら書いていこうかな。

ホテルで少し休んで、8時過ぎにノキアシアター到着。
既に列が長い。みんな期待に満ちた顔で談笑しながら並んでいます。
いいねこの空気。

と見ていたら声をかけられる。
何でも本来はツアー組はもう少し前に集まってチケット配る予定だったそうで…
みんなで僕の名を叫んで探してくれたそうで…申し訳ない。
いやでもホント、集合なんて聞いてないぞ。

中に入るとDannyChooさんがMCしている。
「ミクさんマジ天使！」と客に教えている。
Dannyさん、コンサート前のボカロ歴史セッションでも見事な説明してたけどプレゼン上手いな。
そしてダンスロイドの二人が出てくる。
曲はルカルカだったかな？
正直踊ってみた程度だと思ってたけれど、なかなか上手い。
話によると品川やロス着いてからも練習してたそうで。
上手い下手は別にして、仕事に手を抜かない人は個人的に好き。今後応援しよう。

踊りを見ながら着席。
場所はステージに向かってやや右、前から10列目くらい。
コンサート後は Club NOKIA 行く予定でウェストポーチのみの格好だったので、
あぶれたパンフを隣の人に預かってもらう。ありがとう。

少し休んでいると流れてくる "Diva desu" の歌声。
そして WIM! 始まったー！ 隣人に合わせて立って手振り。
うう大閃光をホテルに忘れてしまったのだ一生の不覚。
前は立たず。後情報によるとトヨタ枠のセレブさんらしい？
すぐ後ろは空席で、数列は着座、その後ろからは立っているようだ。
AX のフォーラムで「お前ら立つ？」と相談してるスレッドを見ていたので、スタンディングさせられるか心配していたんだけれど、これを見て素晴らしいコンサートになることを確信する。

前を見て、次は音に集中をする。
気づかなかったけれど、かなりの音量が出ている。
なのに、音割れや妙な反響が全く無く、耳へのダメージも無い、実に自然な音。
え、何これ？こんな音もあるのかと感動。
低音はどんな感じだろう…と頭をよぎったが、コンサート終了まで忘れていたｗ
音に集中する余裕が無く、ずっとライブを楽しんでしまった。ああもったいない。

スクリーンは照明が暗いときは枠が見える程度だけれど、ステージ端のバンドにライトが当たると面が見えてしまう。
また、スクリーンの繋ぎ目でずれたりも。
映像の質については目が悪いのもあってよく分からない。

シアター内にはオーロラビジョンが掲げられていて、カメラの画を映している。
ちらっと見ただけだけれどこれが見事。
モデルのクォリティが半端ない。これはブルーレイに期待しちゃいますよ。
そしてカメラワーク。
ステージにライトが当たるとカメラはその演奏者のアップにし、ミクを重ね合わせて映す。
繋ぎ目を移動する時は客席を映す。
ニコ生の画が同じなら、ほとんど違和感なく見えていたんじゃないでしょうか。
これ多分事前にかなりの研究をしたと思う。
機能的な面、この場合はカメラで映すという点は手間をかけなくとも達成できる。でもその質は手間をかけるほどに上がる。
こういうタイプの仕事では、どこまでの質を追求するかに制作側の熱意が如実に反映されるもので…ミクパとは偉い違いですな…。
なんか聞くところによるとサクラ大戦のステージのカメラスタッフらしいですね。素晴らしい仕事。

さて、ミクさん。
個人的にはミクをアイドルとして捉えているわけでは無いので、実在感はどちらでもいいんだけれど、
せっかくなのでステージにいるのだと思うことにしました。
面は見えるけれど、少し頭を切り替えればそこにいるように思うのは容易。
騙し絵で見え方を変えるような感じかな。
この感覚だと、枠は何かの演出の棒のように見えますね。

手を上げるとスクリーンにちょうど入るサイズでしたが、あれは等身大なのかな？
今まで実体を考えたことも無く、自分が普段対面するような人(大人の男性)と同じくらいに認識していたのだと思う。
それが、小さい女の子が存在しているのが感じ取れてちょっと驚いた。考えてみればそりゃ小さいよな、と納得する。

頭を使ったのはこのくらいで、後はもう音楽に合わせて腕振り声出し体を揺らすのみ。
いや正直覚えてないｗ
ニコ生組の感想読むと、ストリングスが素晴らしかったとか、ああもう覚えてないよ。
じっくり聞くという楽しみ方もあったと思うけれど…まぁどちらか選ぶならライブでは頭を働かせない方を選ぶ。

目に付いたところだと、セレブ席の方。目の前の男性一人は中盤からずっとスタンディング。
前方にちらほら若い子が立っていました。これは親がチケット貰ったのかな？
そして僕らの前のセレブ席は最後のアンコール三曲はスタンディング。
たぶん、礼儀としてのスタンディングオベーションだと思う。
満足したのかどうかはちょっと分からないな。でも子供は結構楽しそうな感じだったかな。

ビデオの再生方法を調べる

さてジェスチャーの見通しが立ったかなと。
このままジェスチャーからやってもいいのだけれど、アルゴリズムが長くて少しだれてきた。

ビデオ再生

少し方向を変えて、ビデオを表示してみよう。
今の時代ともなると、ビデオは簡単に再生できるライブラリがあるんじゃないかなと期待。

---

microsoft.xna.framework.media

XNAでは、media 以下に VideoPlayer や Video というクラスがある。

• http://msdn.microsoft.com/en-us/library/microsoft.xna.framework.media.videoplayer.aspx

ビデオの現在の絵をエフェクトとして取り出すことができるので、これを貼り付ければいい。

protected override void Draw(GameTime gameTime) {
  _effect.Texture = _player.GetTexture();

このクラスでは、動画はコンテントの仕組みでプログラムに組み込まなければならないようだ。
さらに、コーデックが WMV に限定されている。
コンテントについてはローダ部分を書けばファイルから取れるかもしれないけれど、コーデックはどうしようもない。

---

DirectShow

COMベースのメディアフレームワーク。元々は DirectX の一部だった。
フィルタパターンで美しそうな設計だ。
コーデックは、対応したソースフィルタを開発し、フィルタグラフに載せることで対応できる。

ただし、C# から使えるラッパは LGPL のしか無いようで、LGPL にしないなら自前で書かないとならない。

---

Media Foundation

DirectShow の後継で、Vista 以降専用。
現状で DirectShow との差異は、HD動画、DRM対応、効率向上といったところなのかな。

---

うーん…

DirectShow か MediaFramework か。
MediaFramework は新しいこと以外にこれといってメリットもなさそうだ。
このために WinXP を捨てるのはペイしないなぁ。

DirectShow にするとして、開発環境をどうしよう。
ラッパ使ってもいいのだけれど何とも釈然としない。

技術的にできることが政治的にできないのはムカムカするんだよな。

MMD の kinect 対応

キタ！


ここまでは時間の問題であったわけですが、予想以上に早い。

2010-11-04 米国で kinect 発売

PCで動かせるようになるまで数週間かなぁ
→2010-11-10 オープンソースドライバ公開
→2010-11-19 MS, Kinect のオープン利用を容認

2010-11-20 JST 日本で kinect 発売

誰かが MMD 対応するだろうけど、モーションデータを PMD 形式にするだけでも一ヶ月はかかりそうだな
→ 2010-12-08 OpenNI 公開。スケルトントラッキング！
→ 2010-12-13 樋口MのMMD+Kinect動画。作者キター！ リアルタイム！
→ 2010-12-19 MMD+Kinect 公開。

※日付は現地時刻。




さっそく遊んでみましたｗ

モーションデータも配布してますので、MMD屋さん興味あったらどうぞ。

---

MMD+Kinect 動作までの流れ

忘れないうちにメモ。

1. Kinect USB インターフェースを用意。

以前も書いたけれど、XBOX360+Kinect バンドルパックだと USB 端子が無くて、サポセンに電話して4000円でケーブル買わないとならないので注意してください。

2. OpenNI, NITE のインストール

OpenNI と NITE をダウンロードしてインストール。

Kinect ドライバのインストール

https://github.com/avin2/SensorKinect の Bin/SensorKinect-Win32-5.0.0.exe をダウンロードして実行します。

※注: 上記のバイナリは、https://github.com/ros-pkg-git/Sensor でソースコード配布されている OpenNI PrimeSense モジュールを第三者がコンパイルしたものです。
OpenNI の方がこなれてくれば、簡単なインストーラが配布されるでしょうから、そちらを利用してください。

環境変数

マイコンピュータのシステムの環境変数で、

• XN_SENSOR_VENDOR_ID の値を 0x045E
  
• XN_SENSOR_PRODUCT_ID の値を 0x02AE
  

で新規登録。 Windows での環境変数の反映のタイミングを知らないので、ここで一旦再起動。

Kinect の接続とテスト

Kinect を PC に繋ぎます。USBハブなどは経由せずに、直接PCに挿してください。 OpenNI のインストールディレクトリ(C:\Program Files\OpenNI かな)以下の、Samples\Bin\Release\NiViewer.exe を起動。
しばらくすると、フルスクリーンになって、Kinect の見ている映像が表示されれば成功です。
ダメだったら頑張ってくださいｗ

MMDインストール

VPVPから、MMD 7.24 と DxOpenNI をダウンロード。 MMD は適当な場所に展開。 次に、MMD の Data フォルダに、DxOpenNI に同梱されている

• DxOpenNI.dll
  
• SamplesConfig.xml
  

をコピー。

MMD起動

1. Help メニューから Kinect をチェックして、
   
2. 両腕を上げるポーズをとる
   

キャプチャなどは 樋口さんの説明動画 を見てください。

さぁこれで君もミクミクだ。

Wiiリモコンのジェスチャー認識

3軸加速度は大体分かったところで、次はジェスチャ認識を試してみましょう。
おそらくゲームのキモの部分になるけれど、じっくり調整は後にして当面は出来合いの流用してすましたいところ。

wiiremote gesture recognition で検索するといくつも出てきますね。

フリーソフトウェアとして整っているものは wiigee しか無いようです。
しかしこれは Java で書かれていて、C# XNA とは相性がよろしくない。

C で書かれた WiimoteGR というのもありました。ライセンスは不明。

論文は豊富にありますが、ソフトウェアが公開されているものは少なそう。
基本的には研究室内で使われているコードなんでしょうね。
いずれ書き直すとして、WiimoteGR 使いましょう。

論文は A latest compilation of links to the wiimote のリンク集が良さそうです。
ざっとサーベイしたところ、ニューラルネットはダメで、隠れマルコフモデル(HMM)が主流で、Slow Feature Analysis(SFA) が有望という感じ？

---

WiimoteGR

パターン認識のアルゴリズムはまだいいけれど、全体の設計は理解しておきます。

main() から処理が始まり、トレーニングをしてテストという流れになっています。
トレーニング時は パターン名を指定して、3軸加速度を何セットか記録。SQLLite で保存。

テスト時は SQLLite から学習データを読み込み、
リモコンのデータを記憶しながら、過去いくつかの入力信号をまとめてパターン認識にかける。

認識器は HMM クラス、隠れマルコフモデルでしょう。

const HMM& HMMLib::Recognize(const vector<HMM>& HMMVec, TimeSlot& seq)
    {
        vector<HMM>::const_iterator recognizedHMM = HMMVec.begin();
        for(vector<HMM>::const_iterator curHMM = HMMVec.begin()+1; curHMM < HMMVec.end(); curHMM++){
            if( SeqLogProb(*curHMM,seq,false) > SeqLogProb(*recognizedHMM,seq,false) )
                recognizedHMM = curHMM;
        }
        return *recognizedHMM;
    }

HMMLib は個々のパターンを表す HMM オブジェクトを何組か持っていて、
Recognize() 関数は SeqLogProb() の値が一番大きい HMM を選んで返すようだ。

おそらくこれは、ユーザーがジェスチャで何らかのコマンドを入力するというシーンを想定しているのであろう。
未知の入力対して、一番近いジェスチャパターンを返す。
対して振りゲーの場合、正解となるジェスチャが分かっている。
そのジェスチャとのみ評価を行い、評価値が一定以上ならば正解とする使い方になる。

ところで、テスト部では

while(wiimote.Button.A()){
            wiimote.RefreshState();
            // Acceleration:
            tempAcc.x=wiimote.Acceleration.X;
            tempAcc.y=wiimote.Acceleration.Y;
            tempAcc.z=wiimote.Acceleration.Z;
            
            tempSeq.AddObservableSymbol(defaultQuantizer.Quantize(tempAcc));
            cout << trainer.Recognize(loadedHMMVec,tempSeq).gestureName << " ";
            
            gestureReceived = true;
            Sleep(10);//period (ms)
        }

       void AddObservableSymbol(size_t obsSymbol){
            o.push_back(obsSymbol);
        }

3軸加速度そのものではなく、量子化(Quantize)した size_t 型の値を使っているようだ。

Quantize() 関数は

size_t DefaultQuantizer::Quantize(const Acceleration& acc) const{
        double rho = sqrt(acc.x*acc.x+acc.y*acc.y+acc.z*acc.z);
        return (rho>rho_threshold? 1<<3 : 0) 
             + (acc.x>acc.y? 1<<2 : 0)
             + (acc.y>acc.z? 1<<1 : 0)
             + (acc.z>acc.x? 1 : 0);
    }

となっていて、4bitのビットベクトルである。ビットの意味は

• 加速度の大きさが、スレッショルドを超えているかどうか
  
• 加速度の X方向成分が Y方向成分よりも大きいかどうか
  
• 加速度の Y方向成分が Z方向成分よりも大きいかどうか
  
• 加速度の Z方向成分が X方向成分よりも大きいかどうか
  

後段の 3つは加速度の向きを単純化したもので、最初の1つは大きさを単純化したものである。
3軸加速度そのものは使わずに、パターン認識に必要十分な特徴量へと変換したというわけであろう。
この量子化関数はパターン認識の精度に関わる重要なファクターになりそうだ。

例えば、このコードでは三軸加速度のみを用いているが、M+ のジャイロセンサーを活用できるであろう。
単純に、加速度と同様の手法で角速度を8通りに量子化すればよいのであろうか。
各速度を積分して姿勢を判別し、加速度に向きの補正をかければ良いのであろうか。
しっかり考えないと分からないな。

ダンガンロンパ

久しぶりにゲームクリアしましたよと。

ダンガンロンパ、PSP のアドベンチャーゲームです。
シナリオは閉鎖空間固定メンバーで次々に殺人が起きていくサスペンス。
ゲーム的には逆転裁判みたいな議論の矛盾を突いていくものです。

まずはシステムから。
本質的には逆転裁判と同じで、アクションの味付けがされています。
逆裁は長く議論続くとだれちゃうところありますが、ダンガンロンパはちょくちょくアクションが変わるので飽きにくい感じですね。
ちょいとルールが多すぎるきらいはありますが、なかなか楽しいゲームシステムになっていると思います。

さて、シナリオ。
評価ポイントは、ミステリの基本である動機とトリック、そして脱出モノとして舞台設定という三本ですかね。
ひどいってほどではないけれど、正直及第点は付けられないなぁ。

トリックは簡単。死体発見のタイミングで謎の半分は予想付きます。
さらに調査パートで大部分が分かり、議論パートまで分からないのはひとつふたつ。
次々に暴いていくという快感には欠けますね。

さらに「モノクマ」というゲームマスター的なキャラがいまして、ちょくちょくコントロールしてくれちゃいます。
「この事件に共犯者はいない」とか「DVDのこの先は見ちゃダメ」とか。
正直白けます。

動機はとってつけたようなもの。
残る世界設定も、ラノベ的非現実さとご都合主義で置いてけぼり感が強い。
グループ脱出モノとでも言うのかな。
たとえば去年出た「9時間9人9の扉」と色々とかぶります。
999もご都合主義的なルールが多いんですが、シナリオやキャラクターでうまく説明していて白けないよう努力している。
ダンガンはちょっと手抜きがすぎる気がしますねぇ。

おそらく売りでもある演出面があります。
これまたエキセントリックなキャラクタ付け、残虐描写、有名声優などなど、エッジを効かせているんでしょうね。
すいません、悪趣味で権威主義にしか思えませんでした。
悪趣味の気分悪さを感じさせるのは意図的なのは分かります。
でもそんな偽悪的な手法はもうありきたりで、そこからは一歩も出ていないですね。

まとめ。
法廷パートだけでもまぁ楽しめます。
これだけなら可は付けられるかな。
しかし演出などがマイナスに働いて、総合すると満足度は低いです。

加速度から向きの算出

引き続き、XNAとWiimoteLibで3Dオブジェクトを操作の解析を行います。

過去50個の平均をとってならしている部分を省くと、

    void wm_WiimoteChanged(object sender, WiimoteChangedEventArgs args) {
      WiimoteState ws = args.WiimoteState;        //WiimoteStateの値を取得
      x = ws.AccelState.Values.X
    }
    protected override void Draw(GameTime gameTime) {
      x = (-x * 90.0f);
      x = x / 180 * 3.14f;
      effect.World = Matrix.CreateFromYawPitchRoll(0, y, x);
    }

という感じです。y も同じコード。
AccesState.Values に角度に比例した値、具体的には -1..1 の範囲に丸めた値が入っているのかな？

---

イベントハンドラ

一番上の ws とは何かというと、

      this.wm = new Wiimote();
      this.wm.SetReportType(InputReport.IRExtensionAccel, true);//レポートタイプの設定
      this.wm.WiimoteChanged += wm_WiimoteChanged;              //イベント関数の登録

という手順で登録されたイベントハンドラの引数。

イベントハンドラ登録前の

Wiimote.SetReportType Method (InputReport, Boolean)
  Set Wiimote reporting mode (if using an IR report type, IR sensitivity is set to WiiLevel3)

  public void SetReportType(InputReport type, bool continuous)
    continuous: Continuous data

InputReport はおいといて、continuous は data が連続的な値になるみたいですね。
1byte の値そのままじゃなくて、実数に丸め込むのかな？
しかし AccelState には Values だけでなくて RawValues ってフィールドもあるから両方取れるのだが…。
ちょっと具体的にはよく分からないけれど、こういうパラメータがあることだけ覚えておきましょう。

続いて InputReport は、

InputReport Enumeration
  The report format in which the Wiimote should return data 

Member name	Description
Status	Status report
ReadData	Read data from memory location
OutputReportAck	Register write complete
Buttons	Button data only
ButtonsAccel	Button and accelerometer data
IRAccel	IR sensor and accelerometer data
ButtonsExtension	Button and extension controller data
ExtensionAccel	Extension and accelerometer data
IRExtensionAccel	IR sensor, extension controller and accelerometer data

IRExtensionAccel は IR と Extension と Accel なイベントを有効にする、ということのようです。
内部的にはビットベクトルになってそうです。

---

イベント

Wiimote.WiimoteChanged Event
  Event raised when Wiimote state is changed 
Syntax
  public event EventHandler WiimoteChanged

とのことで、状態が変わったら呼ばれるようです。

このイベントオブジェクトには WiimoteState がメンバ変数にあって、WiimoteState は

WiimoteState Members

Name	Description
AccelCalibrationInfo	Current calibration information
AccelState	Current state of accelerometers
BalanceBoardState	Current state of the Wii Fit Balance Board
Battery	Calculated current battery level
BatteryRaw	Raw byte value of current battery level
ButtonState	Current state of buttons
ClassicControllerState	Current state of Classic Controller extension
DrumsState	Current state of Drums extension
Extension	Is an extension controller inserted?
ExtensionType	Extension controller currently inserted, if any
GuitarState	Current state of Guitar extension
IRState	Current state of IR sensors
LEDState	Current state of LEDs
MotionPlusState	Current state of the MotionPlus controller
NunchukState	Current state of Nunchuk extension
Rumble	Current state of rumble
TaikoDrumState	Current state of the Taiko TaTaCon drum controller

いろいろメンバがありますね。
おそらくはこのライブラリで取得できるリモコンの値はこれで全部なのでしょう。

---

AccelState

長々とイベントハンドラの仕組みを追いましたが、結局のところすぐ上の AccelState.Values を使っています。

AccelState.Values は、WiimoteLib のヘルプによると

Normalized accelerometer data. 
Values range between 0 - ?, but values > 3 and < -3 are inaccurate.

0からの範囲に正規化した値のようです。プラスマイナス3を超えた値は不正確であると。

正規化というのは具体的には何でしょう。
センサから取れる加速度は 1byte の値なので、これをプラスマイナス3の範囲になるように変換したと思われます。
ゼロはおそらく静止状態でしょう。

件のソースコードでは、この値が 1 のときに 90度であるとみなしていました。
力を加えていない時にリモコンを傾けた時に、重力のX方向成分はサインカーブを描きます。
ということは、正規化とは有効値を 3 に収めるのではなくて、リモコン回した時の重力加速度の変化が 1 になるようにしたものということかな。

しかし値はあくまで加速度の成分で、角度に変換されているとはちょっと考えにくい気がします。
おそらくは、サンプルプログラムだから簡単に、サインカーブと比例直線を同じとみなして扱っているのでしょうか。

と、大体予想がついたところで、次はライブラリのソースみたり実測して確認をしましょう。