前回、各標本点を通る解析関数が無数にあると言いましたが、もう少し立ち入って見ましょう。
簡単のため元の信号を振幅が１で角周波数がωの単振動とします。
つまり、sin(ω･t) です。
この信号を標本化周波数 fs で標本化します。
当然ながら、sin(ω･t) は、これら総ての標本点群を通りますが、
±sin{(n･ωs±ω)･t}　　…（複号同順）
も、同様に総ての標本点群を通ります。（証明は、ソフトウェアＤＡＣの付録１参照のこと）
ここで、n は任意の自然数、ωsは標本化の角周波数(2π･fs)です。
これらは、標本点が時間に関して不連続なために生じた結果で、元の信号に対して、エイリアス(Alias)と呼びます。

つまり、色々な繋ぎ方があるのは、目的の信号と無数に存在するエイリアスの混合の仕方に他なりません。
逆に、あるＤＡＣでアナログ波形を得るということは、この混合比を決定するということです。
勿論理想は、元の信号が１で、総てのエイリアスがゼロです。

前回の fs/12 で、各標本点を直線で繋いだ線と元の波形との差は、それほどでもないと思われた方もあるかもしれません。
しかしながら、差が見えるということは、１ドット以上（隙間があれば２ドット以上）の差があるわけで、
これは誤差が１％（２％）以上あることを示しており、オーディオと言う範疇では、問題です。
しかも、周波数が高くなればこの誤差は益々大きくなってしまいます。

上図は、fs/3 の場合です。

そこで、この周波数依存性を、簡単に考察してみましょう。
折れ線で繋ぐということは、ソフトウェアＤＡＣでも紹介したＰ０２アップサンプリングを、無限に繰り返すことに相当します。
（階段状のままならＰ０１の繰り返しですが、位相がずれていくので単純に振幅の積算にはなりません）

上図は、そこで発表したＰ０２のＳ－Ａ図です。
最初の一回分だけでも、目的の信号部分が削り取られてエイリアスになってしまう様子がお分かりいただけると思います。

このようなスペクトルから、信号部分だけをフラットに戻して取り出すアナログフィルタがあると思いますか？
例え、理想に近いフィルタを作ったとしても、位相はどうでしょうか？
これを解決するには、原点に戻って、誤差の少ないトレースをＤＡＣで実現するしかありません。
つまり、エイリアスの多いアナログ化をしてからでは、遅いのです。

追伸：報告するのを忘れていました！
以前ＬＥＯさんが報告しているように、３月２日以来、Windows8(CP版) で弊社開発アプリの動作テストを行っています。
ＳＡＬも二台の検証機にインストールして、ついでにＷＦＰの動作テスト＆息抜き時の鑑賞用としています。
１．AthlonX2 + 4GB/RAM + Win8(64bit) + Ph社DDC/USB(内蔵ドライバ) + Ki社DAC + 例のヘッドホンシステム
２．PentiumD + 3GB/RAM + Win8(32bit) + Ra社DAC/USB(専用ドライバ) + Ac社プリ + Ya社メイン + Ki社低能率ＳＰ
両機共、折角付いた 24bit/88.2KHz 共有モードなので、WFP4ExpはＰ４０アップサンプリングを主に使用しています。
本来が商用アプリのテスト用なので、ＯＳのチューニングは行っておりませんし、ＰＣのパフォーマンスも低レベルです。
（テスト目的なので、デフラグはスケジュールしておりません）
また、オーディオ装置も、「社内への持ち込み品」のレベルです。
で、肝心の音質ですが、（ＳＡＬの耳では）問題ないレベルだと判断しています。
但し、メンテナンス実行中は流石にＮＧなので、ウォーミングアップ時に済ませておくと良いでしょう。

前回迄で、困難ではありますが何とか標本点群を再現できたとします。
（16bit-44.1/48KHz であれば、可能性は高いと思います。）
そこで今回からは、それらをどの様に繋いで元の波形を再現するかを考えます。

衝撃波の様な特殊なものを除けば、音波は解析関数で表せるはずなのですが、
解析関数と言う前提だけでは、残念ながら総ての標本点を通る関数を一つに絞ることはできません。
そのためには、標本化定理で言うところの「標本化周波数の半分(fs/2)以上の成分を含まない」ことが必要です。
この条件を入れて初めて一つに絞ることが可能なのです。
この件に関しては、これまで「手を変え品を変え」て説明してきましたので、ここでは省略します。
結論だけを言えば、教科書(?)にあるような階段状のギザギザ波形で繋いだものは、論外なのです。

教科書(?)では、標本点間の落差を１～２程度に描くことで、誤差（分解能）の内としてごまかしています。
実際のＣＤに記録されているデータで、その落差が数千の場合など、珍しくもありません。
と言うより、最近のＣＤでは差分の最大値が１００００以上のＰＣＭデータもざらです。
即ち、ギザギザで繋いだのでは、「その間の誤差が 10bit(1024) 以上」という場合も充分ありえます。

しかしながら、実際には此処で言う程ひどい出力（音）にならないのは、何故でしょう。
それは、その後にある fs/2 以上をカットする為の、アナログのローパスフィルタのおかげです。
もとの波形に対して、ギザギザ波形を 1/(2fs) だけ進めて（左に移動して）重ねてみると解り易いのですが、

（上図は、fs/12の単振動の例で、元の波形は灰色です）
そうすると、ギザギザ波形の水平部分の真ん中が標本点になり、一定の勾配部分では、前半分と後半分が点対称の関係になります。
つまり、後付のローパスフィルタで、誤差が相殺されると言う訳です。

残念ながら、この考えは誤りです。（正しく言い訳に過ぎません）
そのような結論を得るには、「標本化周期に対して一定の勾配」と見なせなければなりません。
そういった周波数領域は、大甘に見積もっても fs/100 以下です。
中域から高域をまともに再生したいと思うのであれば、元の波形を標本点群から逆算して、ＤＡＣにその波形をトレースさせることです。
標本化定理の「最高周波数の周期の半分で標本化すれば良い」と言う意味は、
「再生時は標本点を再現すればそれで良い」のではなく「その標本点群から元の波形を逆算できる」ということなのです。
ＳＡＬは、この元の波形を逆算することを、トレースと呼んでいます。

次回では、高精度に標本点群を再現しても、きちんとトレースしなければ、
それこそ後の祭り（アナログフィルタでは戻せない）であることを述べたいと思います。

  直訳すれば「アップサンプリング」とは、サンプリング周波数を高い周波数に変換すること（サンプリング周波数を上げる変換）を意味します。 ところがオーディオにおける「アップサンプリング」に限定した場合においても、「高い周波数に変換」ではなく「元のサンプリング周波数の整数倍数に変換」と捉える人もいます。 また、日本語では「標本化周波数変換」とも言いますが、K’sは拘りがあって、「標本化周波数」という言葉は生音やアナログ音源を最初にデジタル化するときのみに使いたいと言う勝手な思いがあり、他の人から見れば狭義な解釈となってしまいます。 これが、アップサンプリングの類義用語である、オーバーサンプリング、ダウンサンプリング、リサンプリング、Ｄ/Ｄコンバート、サンプリングレート変換などに広がれば、紛らわしいだけでなく解釈が違って当然です。

  話を元に戻しますが、友人は、あるＣＤプレーヤーにおいて、ＤＡコンバータで行なっているアップサンプリングを「音源（信号帯域）も拡張されている」と思って話しており、K’sは、そのＣＤプレーヤーは「音源はそのままでサンプリング周波数のみを高い周波数に上げてローパスフィルターの次数を下げられるようにしている為」と思って話を進めていました。 すなわち、友人は44.1KHzの音源をＤＡコンバータのアップサンプリングをオンにして２倍に設定したとき、音源もＤＡコンバータ内部で88.2KHzに変換されていると思っていたそうです。したがって「Wave File Playerでアップサンプリングして音源を２倍（88.2KHz）に変換した場合、ＤＡコンバータでさらに２倍にアップサンプリングしたら、４倍（176.4KHz）の音源になってしまうので云々・・・」ということが、話の食い違いの始まりだった訳です。

  友人曰く、そのメーカーのパンフレットに「ＤＡコンバータのアップサンプリング機能により、音源を精度良く88.2KHzや176.4KHzに変換する」と記されていたと言っていましたが、確かにオーディオ業界の中でも「アップサンプリング」という言葉の解釈がまちまちで全く統一されていません。 また、パンフレットに平気で嘘としか思えないことを平気で唱えているメーカーも見受けられます。

  オーディオ業界も「良い物を作る」のではなく「売れる物を作る」、言い方を変えれば「売ってしまった方が勝ち」なので、「売る為には嘘も構わない」という考えのメーカーがあるのでしょうか？ きっとメーカーの技術者は、その製品に相応しい宣伝ではないこと承知していると信じますが、宣伝文書を考える方（または業者）の知識不足のせいか、それとも営業側の意見なのでしょうか？

  百歩譲ってパンフレットの技術解説や売り文句は良しとしても、せめて「製品仕様」には用語や表記方法を統一して（場合により測定方法等も記述して）誤解を招かない表記を心がけて欲しいと願うK’sです。

「２．高架道路を乗せる」ことについて述べる前に、ここまでのおさらいをしておきましょう。
① 正確な位置に橋脚を立てるためには、ＤＡＣに充分に低揺らぎ(Jitter)なクロックが必要です。
② ＤＡＣは等時処理(Isochronous)なので、そのクロックに同期したテンポで（高さ）データを供給する必要があります。
③ 一方、ＰＣ内部は多時間系なので、該当プロセスは仮想時間で不均一に進められます。
敢えてデータの流れと逆行して書いたのは、目的を優先したかった為です。

では、実際はどの様な流れで解決するのか見てみましょう。
②→①に関しては、データエラーをしない程度に同期していれば良いので、②に同じクロックを供給すればＯＫです。
逆に、②の出力にＰＬＬ等で同期して①を動作させることも可能ですが、この場合は②の持つ揺らぎだけでなく、データの伝送路で生じる揺らぎも加味されてしまいます。
（等間隔に時を刻むことの難しさは、実時間が確定*の為の時間と同じ軸-次元-であるためです。）
次に、③→② に関しては当然ながらハードウェアの助けが必要ですが、③の仮想時間の間欠部分を吸収するだけの遅延(Latency)がどうしても必要です。
どの程度の遅延が必要かは、実時間に対する仮想時間のギクシャクの度合いによります。
つまり、ＰＣの再生アプリ＆ドライバ及びその動作環境次第です。

ついでに、ここで言う遅延(Latency)に関して、大いなる誤解が生じているようなので、説明します。
最悪の誤解は、「遅延が大きいと波形が鈍る」と言うものです。
恐らくは、アナログ回路での経験からの誤解と思われます。
仮想時間で扱っているＰＣＭデータには、時間情報は含まれていません。ただ、順序だけが重要です。
（所謂ファーストインファーストアウトです）
時間が付け加わるのは、ＤＡＣに於いてクロックに合わせてアナログ値を生成する時です。
もう少し正確に言うと、②の供給側も等時処理の部分は、この実時間に縛られます。
但し、データを正確に渡せる（確定*）範囲であれば、多少は揺らいでも構いません。
つまり、仮想時間での遅延は、一時保存しているだけで、出力波形に何ら影響するものではりません。
影響するのは、ＤＡＣクロックの揺らぎ(Jitter)と、等時処理(Isochronous)に於けるデータエラーと、遅延で吸収し切れなかった仮想時間(Virtual-time)からの不均一性です。

つまり、遅延は大きく取ればその分多時間系の不均一問題を解決してくれます。
しかしながらＰＣでは、大きな遅延を許していません。
理由は、他の処理（例えば動画等の表示）とずれを生じてしまうためです。
しかしながら、我々の目的は、ＰＣをトランスポートの一つとすることなので、他と同期する必要はありません。
逆に、ＰＣをコントロールセンタとしたいのであれば、音質を犠牲にしてでも、遅延は少なくする必要があります。
この辺りの目的の違いを無視すると、様々な情報に惑わされることになってしまいます。

先送りになってしまいましたが、次回こそはＳＡＬがこの二年ほど取り組んできた、「２．高架道路を乗せる」ことについて述べます。

このようにして録った17チャンネルの24bit/96KHzのリニアＰＣＭを今週からミックスしています。
作業用のＰＣは新らたに組み立てたi7/2600に16GBメモリー搭載したものを使っており、ＯＳはWindows7の64bit版、DAWも64bit版を使っています。
ＯＳとプログラムに64GBのSSD、作業データ用に64GBのSSD、保存用データストレージに2TBのHDDを用意したので、スピードが速くすこぶる快調です。
従来のＰＣもHDDは4台をストライプセットしていたので、当時は早い方でしたが、やはり新しいＰＣとは比べものになりません。
このような作業効率の良い環境のせいか、今回の音源制作は作業に集中できます。

アルバム制作のほか、ピアノの音だけを色々マイクアレンジして聴いてみた結果、なかなか興味深く面白いので、マイクアレンジ比較用として短時間でダウンロードできる程度の、著作権に関わりのない音源も作ってみようと考えています。

この音源制作の過程については、タイミングをみてブログに書きたいと思います。

今回からはＰＣを離れますので、一般のデジタルオーディオに共通のお話です。
多時間系の問題を克服して、なんとかＤＡＣまで標本値を欠損なく等時伝送できたとします。
しかしながら、ここから元のアナログ波形を得るには、二つの壁を乗り越える必要があります。それは、
１．各標本値をビット分解能の精度で再現
２．再現された各標本値を通り、元の波形に相似な連続波形を再現
しなければなりません。
例えて言うなら、１．橋脚を正確に立てて、２．高架道路を乗せる。
ようなものです。但し、道路は水平が基本なのに対して、こちらは正反対に凸凹が当り前なので、交互に逆転した太鼓橋のようなものをイメージしたほうが良いかもしれません。
また、橋脚は正（上）方向のみなのに対して、こちらは負（下）へも伸びますが、こちらは単に高さが符号付なだけです。

今回は、１に潜む問題点を述べたいと思います。
３２ｂｉｔＤＡＣが当たり前の昨今ですから、２４ｂｉｔのアナログ化（橋脚の高さ）には十分な精度があると仮定します。
勿論、この分解能を維持するアナログ装置（この場合はＳＮ比-140dB以下）が現存するか否かは、周知の通りなのですが…。
それを別にしても、橋脚の高さだけではなく立ち位置（間隔）の精度も重要なのは当然のことです。
そこで、再現周期の揺らぎについて注目することにします。

先ずは、高さに対してどの程度の精度が間隔にも必要か、見積もって見ます。
fs/4 の信号を想定すると、隣り合う橋脚高の差が振幅程度になりますので、この帯域が充分含まれている fs=44.1KHz では、再現周期にも高さと同様の精度が要求されます。
理論的には、fs/2 で円周率(≒3.14)倍の最大傾きがありえますが、取り敢えずは同程度として考察します。
（Gradient.exe の MaxGradient が 0×00800000 程度）

高さの分解能を符号付 24bit とすると、それに見合う時間の誤差は、fs=44.1KHz の場合でも、2.7ピコ秒(ps)と言うとてつもない精度が要求されます。
周波数換算で 367GHz ですから、揺らぎの範囲とはいえ、発信器やその伝送路での揺らぎ以前に、通常の半導体素子のスイッチング精度を超えていないのでしょうか？
これが、16bit であれば、0.692ナノ秒(ns) となって、手が届く範囲になってきます。
とは申しましても、サブナノ秒の世界なので、それなりの発信器や伝送経路が必要です。
複数の外聞に因れば、現在の製品技術水準では 20bit あたりが限界のようです。
それは時間にして、0.043ns(=43ps)程度の揺らぎです。（ＳＡＬはこれでもすごいと思います）
結果、16bit/44.1Hz or 48KHz であれば、現状の機器類でも選択や接続法を厳選すれば、標本点の再現はほぼ可能のようです。

即ち、充分に低揺らぎ(Jitter)の発信器を持つＤＡＣを使うか、その様な外部発信器からの供給（伝送路も含む）を受けることで、16bit/44.1KHz レベルの再生には透明になれそうです。
但し、多くの方が使われているような、ＤＤＣ→ＤＡＣ系なら、このクロックでＤＤＣ側も同期させておくことが必須です。
理由は、この間が完全な等時処理系だからです。
ついでに一言、
ＤＡＣ側への供給さえ充分低揺らぎならば、ＤＤＣ側への分岐供給クロックの精度については、ＤＡＣ側でデータエラーを起こさない程度の揺らぎを無視できます。
これが、デジタルと言うことなのです。

次回は、いよいよ「２．高架道路を乗せる」問題について、改めて述べたいと思います。

3月11日に開催された名古屋ウィメンズ&シティマラソンに参加してきました。

今回の大会は、従来の名古屋国際女子マラソンと名古屋シティマラソンを統合する形で「 マラソンフェスティバル ナゴヤ・ 愛知 2012」として開催された記念すべき第1回目の大会です。

前回の名古屋シティマラソンでは４ｋｍコースに出場し、何とか完走することができたので、調子に乗って今回は10kmコースにエントリーしました。

エントリー直後の「頑張ってトレーニングしよう」との決心は脆くも崩れ去り、トレーニングでは1度も10kmを走ったことが無いまま、ランナーズハイで何とか乗り切れるだろうという甘い考えで当日を迎えてしまいました。

当日会場のナゴヤドームに着いて、まず驚いたのは人の多さ!!
仮装している人もいて、もうお祭り騒ぎです。

そして、当日一番大変だったのはトイレの少なさ･････。
参加人数に対して仮設トイレの数が圧倒的に少なく、40分位並んで待ったため、スタート時間にギリギリになってしまいました。来年からは是非改善されることを切に願います。

人が多すぎて、スタート地点からしばらくは、お団子状態でほとんど歩いていましたが
500m過ぎたころからようやく走り出すことができました。

沿道には応援の人、人、人･･・で埋め尽くされていました。
「頑張って!!」と声援を送ってくれる子供、ハイタッチしてくれる女子高生、太鼓をたたいて応援してくれる人、ほんとに励みになりました。知らない方々からこうして応援してもらえるのもマラソンの楽しさの1つかなと思います。

沿道の方々の応援に後押しされ、何とか９ｋｍ地点まできたところで、地獄の上り坂が待っていました。体力がもう限界のところにきてこの上り坂は相当きつく、もう歩こうかなという誘惑に何度も負けそうになりましたが、頑張りました!! かなり頑張ったので自分で自分を褒めてあげました。　タイムは1時間7分。1時間切れなくて残念ですが、結構な達成感を味わうことができました。

そして、大会終了後は、お決まりの焼肉とビールで乾杯です。
完走した後のビールは格別!!です。

更なる達成感を味わうため、来年は頑張ってハーフかフルマラソンに挑戦したなと思います!!

少しだけでも元気を送ろうとの想いでウェアに貼らせていただき何とか完走しました。
さてさてタイムの方は・・・それは秘密です。
来年も参加しようかなあ？ハーフマラソン？？

前回は、「ＰＣの音声再生は、音源データの操作を前提としてる為に、それ以降は等時性が必須！」
と話ました。ＷＦＰのように、再生のみに特化し何も操作しないアプリでも、
既存のオーディオインターフェースを使う限り、この制約から逃れることはできません。
せいぜいが、この等時性の障害（邪魔）にならないようにするしかありません。

「アプリ側の方が、スレッド実行順位は低いから大丈夫」と思ってはいけません。
ストリーミングを行うには、どうしても再生中に、ＨＤやＮＩＣといった外部デバイスからデータを受け取り①、
それを、適当な単位でドライバに渡さ②なければなりません。
もう少し具体的に問題点を洗い出して見ましょう。

① Ｉ/Ｏ機器からのデータ取得には、ブロック転送等によるリソースの占拠期間があり、同様のＩ/Ｏ機器である音声装置へのアクセスに干渉します。
② アプリ側からの呼び出しにドライバ側が同期すると、実行順位の低さが等時性の足かせになります。
但し、②については、ＭＳの資料によれば「ＷＡＳＡＰＩの導入時に改善された」ようですが、逆に言うとＶｉｓｔａ以前は確実に影響が有ったということです。
更に注意して頂きたいのは、ＰＣフリークの言う「些細なこと」が、オーディオファイルの方にとっては「致命的」も有りうることです。

ＷＦＰは、アプリ側で一切ストリーミングを行わないことで、この問題を回避しています。
特に、Experimental では、ＰＣＭデータをメモリ上に置くことで、Ｉ/Ｏバスでの衝突も回避しています。
再生中のデータフローは「入力はメモリーから、出力はＩ/Ｏへ」と言う構造です。
また、等時性と言っても、若干の遅れ（Latency）を許せば、その分がゆとりになります。
一般的には評価の低いカーネルミキサーですが、ここでの遅れは意外と貴重です。
但し、レートコンバーターが働くと、データの有効桁数を大きく損ないますので、標本化周波数は必ず合わせておきます。

最後に、「私のマシンはビットパーフェクトが実証されているから大丈夫」と思っている方へ…
これまでの話で、お解りとは思いますが、ビットパーフェクトを実証する為には、ストリーミングを避けてはいけません。
何故なら、データを狂わす最大の原因がストリーミングだからです。
せめて、一曲分（五分程度）のデータをストリーミングで再生し、例えば S/PDIF 出力側で正確なテンポで正確な値を実証しなければなりません。
ストリーミングもしないような、小さなサイズのソースで行っても意味がありません。

但し、この問題を突破しても、ＤＡＣ迄の等時伝送や時間精度、ＤＡＣが抱える Alias による有効桁数の低下（音色の変化）が、次に控えています。

元々、愛機がハードウェアトラブルを抱えており、8をインストールするのに時間がかかってしまい、当初予定していた時間ほど触れていませんでしたが、今後、回を追って報告いたします。

さて、まずはインストール作業でしたが、インストール時間は思いのほか、かかりませんでした。計測はしていませんが、Vista、7に比べて体感で2/3程度だったように感じました。

アカウントがメルアド必須だったり、Windows Liveと関連付けられたりしてるのが嫌ですね（なのでスタート画面の画像のアカウント名は消してあります）

【追記】アカウントについては、グローバルアカウントとローカルアカウントと２種類あって、そのどちらでもアカウント作成ができるようです。グローバルアカウントではメールアドレス、ローカルアカウントでは旧来のログインネームでの設定のようです。ただし、初期設定の画面では、グローバールアカウントの設定表示が大きいので、画面隅っこにあると思われるローカルアカウントの設定は見落としがちになりますが・・・。

何の問題も無くインストールが終了し、さて、これがOS起動後のスタート画面です。

「ん？これデスクトップなん？」

今までのWindowsに慣れていると、当然、戸惑いますよね。よくみるとタイルの下の方にデスクトップが・・・。

シングルクリックしてみます。

従来のデスクトップ画面が表示されました。

そして、何故か金魚が・・・。インストール時にも出てきたキャラです。Microsoftのデスクトップ・デザイナーは弥富出身だったのでしょうか。でも、何か意味があるのでしょうね。

よーく見てみると、お気づきの方もいるかもしれませんが、デスクトップの画面にスタートメニューがありません・・・。

スタートメニューがない・・・先ほどの起動後の画面は「スタート」・・・。

わかりますね。

「全ての道はスタートから・・・スタートですか、そうですか」

でもスタートに戻る方法がわからない・・・。

あれやこれや格闘して偶然みつけた、画面上部をクリックすると、手のひらツールが表示され、どうやらデスクトップ上部をドラッグして、下にスワイプすればアプリが終了してスタートに戻るようです。

アプリ一覧

Internet Explorer10で弊社ホームページをブラウズしてみました。事前にIE10はかなりチューニングされているとは聞いていましたが、

現バージョンのIEやFireFoxに比べるとかなり早いです。Goolgle先生によれば、弊社ホームページは完全に表示されるまで平均2.5秒くらいの時間がかかるそうですが、IE10ですとわずか１秒程度です。うん、頑張った！IE10開発チーム！

面白い事にアプリで実行するIEとデスクトップ上で実行するIEは別々で実行されるようですね。

もともと個人的にはWindows8のタブレット版に魅力を感じており、デスクトップOSのWindows8ではどのようにMetro UIを実装してくるのかという所が、最大の関心事でした。

今回は軽く触ってみただけですので評価まではできませんが、第一印象としては「おそらくBusuiness版（Windowsドメインの中のクライアントOSとして）はそれほど7と変わらない内容なのだろうけど、Consumer版のUIに慣れるのに時間はかかりそうですね。

まだまだこれからなので、生暖かく見守っていきたいと思います。