ADAGIO MISTERIOSO
著作権について
瑞相記 アプリ編 ミュージックプレイヤー開発日記
・MPA(ミュージックプレイヤーソフト)6
・MPA(ミュージックプレイヤーアプリ)5
・MPA(ミュージックプレイヤーアプリ)4
・ミュージックプレイヤーアプリ3
・ミュージックプレイヤーアプリ2
・ミュージックプレイヤーアプリ1
・PCオーディオ1
MPA(ミュージックプレイヤーソフト)6
前回、このページを更新してから１年ほど経過してしまいました。その間、何もやってないわけではなく、開発は進めておりました。ですが、あまりにも大きな壁にぶつかり、現在はどうしてよいのか分からず、完全に停滞しています。停滞するまでの進捗状況を記しておきます。
まず、ギャップレス再生はというと、前回記述したとおり完璧に成功しました。これが上手くいったときの喜びは半端なものではありませんでした。大きな前進でしたし、これで完成にもっていけると確信してましたから。実際、それ以降、ＧＵＩは”kivy”を使って悪戦苦闘しながらプレーヤーのスキンを作ってました。kivy自体が日本ではあまり使われていない言語らしく、ネットで検索してもあまりヒットしませんでした。が、問題が発生したとき、本家本元のアメリカのスタックオーバーフローで質問したら、数時間で解決してしまいました。そういうことが分かってからは、質問は本家のアメリカのスタックオーバーフローですることにしています。もちろん、英語ですが、なんとかなるもんです。
スキンを作っていく過程でＣＤリッピングとＣＤの曲目などの情報を取得する必要が出てきました。リッピングできないミュージックプレイヤーはないですから。リッピング機能を追加するのも苦しみましたが、ネット検索とスタックオーバーフローで質問することによりリッピングができるようになりました。オープンソースを使うことによって成功しました。今現在はＣＤが無くなりつつある状況ですから、リッピング機能は無くてもよくなるかもしれません。話が逸れました。ＣＤの曲目などの情報を取得することもフリーのＣＤＤａｔａＢａｓｅにアクセスすることにより取得可能にもっていけました。これも苦労しました。ＣＤＤａｔａＢａｓｅのサイトを見に行ってみると、やはり全て英語で書かれているので、アクセス方法を理解するのに一苦労。でも、その分成功したときの喜びは一塩です。
この後は完全にスキンを作るだけになりました。それも着々と進んでいました。が、その途中であることに気づきました。瑞相記でも書きましたが、ＣＤの需要が激減しているだけではなく、音楽ファイルのダウンロード販売にも陰りが見えてきたということです。音楽を聴くツールが変化してきていることに気づきました。音楽ファイルを完全にダウンロードして聴くのではなく、音楽ファイルをネット経由でストリーミングして聴くという聴き方に変化してきています。特にアメリカで。アメリカのスタンダードは世界のスタンダードですから、世界もいずれストリーミング再生が主流となるでしょう。とすると、パソコンを使用して音楽を聴く人は結構いるでしょうが、今まで使われてきたミュージックプレイヤーソフトではなく、ストリーミング配信をしている企業が提供するプレイヤーソフトを使用することになります。すると、個人でいくら高性能のミュージックプレイヤーソフトを作ろうとも使う人が少ないと思います。どころか、いずれ消滅の憂き目に遭遇するソフトになると思われます。哀しいかな。これが現実です。
と思っていたのですが、案外一部の人はそうでもないかもとも思いはじめました。ハイレゾ音源を聴きたい人、特にクラシックファンは、高音質を求めています。ですから、高音質のミュージックプレイヤーソフトを作れば使用してくれる人は結構いる気がしてきました。ニッチな市場ではありますが。そこで、今度は、再生部も自作のミュージックプレイヤーの開発に挑戦しようかと思ってます。ですが、そのためには、Pythonではなく、C++を使うことになりそうです。一応Ｃ++の基本知識は身に着けたと思ってますが、壁はまたまた高くなった気がしてます。
ページトップへ戻る
MPA(ミュージックプレイヤーアプリ)5
前回このページを更新してから1か月あまり経ってしまいました。前回の最後にmultiprocessingモジュールを使い、実行中のプロセスにアクセスするということをやりました。
できることはできるのですが、QueueやPipeを使って処理中のプロセスからvalueのやり取りを行いました。ですが、multiprocessing自体は速いのですが、QueueやPipeでの
データの受け渡しが遅いんです。当然と言えば当然で、データそのもののサイズが大きいので次のプロセスにデータを渡すのに時間がかかりました。しかも、threadingの方が、
処理が速いように思います。
ですから、曲を選んでから再生までの時間短縮はできませんでした。振り出しに戻ってしまいました。そこで、再生システムの構造を再考しました。次に思い付いたのは、
ストリーミング再生です。ストリーミングですと、１曲終わって次の曲を再生するときに、ストリーミングを再立ち上げしますから、その時間がどうしてもかかると思い、自分の作っている
アプリには不向きだと思っていました。ですが、python moduleのsounddeviceとsoundfileのサイトを参考にしたところ、ストリーミング再生でいけると思いました。と言うか、
現在思っているのは、ギャップレス再生にはこの方法しかないのでは？と思っています。
てなわけで、ギャップレス再生で、曲選択から曲の再生までの時間の短縮ができました。驚くほど速く再生が始まります。
現在は、GUIとしてkivyを使用して再生アプリのスキンを作っています。少し甘く見ていました。なかなか難しいです。ですが、着実に前進しています。ファイル選択画面を
作成中です。
ページトップへ戻る
MPA(ミュージックプレイヤーアプリ)4
ミュージックプレイヤーアプリをpython3.7で製作中です。前回「ミュージックプレイヤーアプリ3」で書いたように、ギャップレス再生ができるようになりました。ですが、問題も新たに
出てきました。ギャップレス再生するために、アルバム内のwavファイル全曲を一度に読み込んで繋げるのですが、その処理に10秒ほど掛かってしまってます。ミュージックプレイヤーの
「iTunes」やsonyの「music center」ですと、遅くとも1、2秒で再生準備が完了します。この差は一体何なのか？言語の違いかなとも思いました。pythonは、
インタープリタ言語ですから、C++ほど速くないことも分かりました。ネット検索すると、特にループ処理は避けたほうがいいとあります。そこで、対策をしました。
対策内容は、「アルバムを読み込むとき、１２曲収録されているとすると、３曲ごとに４分割して読み込むという方法」。この方法で読み込むとき、スレッドを４つ立ち上げて、
４つ平行で処理させる。使ったモジュールは「threading」の「Thread」です。４つの平行処理が終了した後、繋ぎ合わせます。この方法ですと、6、7秒で処理できます。
改善はしました。それでも、6、7秒は長いすぎる。読み込むときの処理内容を確認しました。まず、「soundfile」モジュールを使って、wavファイルのデータを16進数(int16)で
読み込みます。このとき、同時にサンプリング周波数（fs）も読み込んでくれます。読み込んだ後の処理は以下です。
1.fsを変数に格納。
2.データ数を算出。（左右チャンネル一対とします）
3.データ数をリストに追加格納
4.fsとデータ数から各曲の再生時間を算出。
5.各曲の再生時間をリストに追加格納。
6.読み込んだデータ(16進数)をnumpy配列に追加格納。
このファイル読み込みと1～6の処理を３つのwavファイルでループします。そのループを４つのスレッドで平行処理します。ループの処理時間を測定すると、回数が増えるごとに処理時間がかかる傾向が
分かりました。そこで、ループ内容を見直しました。
1.fsは全曲同じですから、格納は1つのスレッドのみとしました。
2.データ数の算出は元データさえあれば算出できるわけですから、ループ内で算出するのではなく、元データを全
て読み込んだ後に一括算出することにしました。
3.そのまま。
4.再生時間の算出もデータすべて読み込んだ後に一括で算出することにしました。
5.4の処理をループ外にしたので再生時間の格納もループ外になります。一括算出するときに同時に格納します。
6.そのまま
これで、ループ内の処理内容が大幅に減りました。
そこで、ループの処理時間を測定。・・・・・・・・。
がーーーーん。ほとんど変化なし。orz
なぜ？ループが遅いのではなかったのか！？
誰か教えてくれー！
気を取り直して、ループ内の各処理時間を細かく計測。原因を発見！。ループそのものの処理は速い。と思う。そりゃそうである。3回しか回してないのだから。最初、疑っていたのは、
「6」のnumpy配列(行列)にデータを追加していく処理。なんせデータ数が１秒あたり44100個×2（左右チャンネル）＝88200個もあるのだから。５分の曲のwavファイルなら、88200(個)×
5(分)×60(秒)=26460000(個)ものデータ数になる。このデータ行列を前の曲のデータ行列に追加するのだから、時間がかかると思っていた。しかし、処理時間を計測してビックリ。
一瞬で終わっていた。「6」が一瞬ということは、「3」はもっと速いと思う。とすると、残りは一つ。wavファイルの読み込み時間。正解！この処理にかかった時間の合計が３回ループの処理時間
であった。そこで、考えたのは、16進数で読み込むのではなく、そのまま読み込んで、すべて読み込んで繋げた後に一括で16進数に変換する方法。しかし、プログラミングのスキル不足か、
うまくいかない。
複数処理を同時に行う方法として、「threading」モジュールを使用しているのだが、以前、調べたとき、他に「multiprocessing」モジュールというのがあったことを思い出した。
調べた内容では、「threading」は平行処理と言っても、cpuに４つ論理プロセッサがあったとして、４つの内１つを使って、その中で４つの処理を平行して行うと書いてあった。
一方、「multiprocessing」は使用する論理プロセッサの数を指定して、平行処理すると書いてあった。だから、「multiprocessing」の方がずっと速いと。処理しているときの
タスクマネージャーのcpuのグラフ画像入りで解説してあった。ところが、自分のパソコンで調べてみたら、「threading」モジュールを使ったら、４つのcpu使用率グラフが同時に
上昇し始めた。４つの論理プロセッサを使用している。何分超初心者なので、詳しいことは分からないが、ひょっとすると、「threading」モジュールも改善されてupdateされたのかも
しれないと思った。それでも「multiprocessing」
のことを思い出して、使用してみることに。なぜ、最初に「threading」ではなく「multiprocessing」を使わなかったのか？実は使った。しかし、「multiprocessing」モジュールを
呼び出せなかった。それで、「threading」モジュールを使用しました。「threading」モジュールについての説明は
こちらのサイトが詳しいです。
もう一度「multiprocessing」に挑戦！しかし、あれこれ調べながら思い付く限りのことをやったのですが、ほとんど同じエラーが返ってくる。「'module' object is not callable」。
原因が全く分からず。そもそも、モジュール自体が、うまくインストールできていないのでは？と思い、最新のPython3.7をインストール。それでも、同じエラーを返される。本当に
モジュール自体が動いているのか調べるため、Python公式サイトの「multiprocessing」のページからサンプルソースをコピペして実行してみた。なんと！同じエラーが返ってきた！
やっぱり、モジュール自体がおかしい。とここで、不思議なことに気付く。「multiprocessing」の「process」というクラス？を使用しているのだが、使い方として、
「aaa = multiprocessing.process(target=メソッド,args=(引数,))」とインスタンス？を作る。この「process」という部分が気になった。公式ページでも、それ以外の
サイトでも解説やサンプルソースでは「process」ではなく「Process」となっているのだ。私は「VS 2017」のフリーバージョンをたいへんありがたく使わせていただいている。
「VS 2017」では、モジュール名などを入力すると、フォントカラーが変わる仕様になっている。綴りなどが間違っていたりすると、色が変わらないので間違いに気付く。しかも、
モジュールを使うと、モジュール名を入力した後に候補のクラス名をリストアップしてくれる機能が付いている。言うまでもなく、使い易いし、ありがたい。それで、サンプルソースを
コピペすると、モジュール名の後の「Process」というクラス名の色が変わらないので、表示されるクラス名の候補を探すと「process」が表示されているので、「process」と
入力し直していた。まさかと思ったが、この入力し直した「process」(p小文字)を「Process」(P大文字)に戻したら、あっさりうまくいった。!^^! 超初心者の私ぐらいかもしれないが、
天下のMicrosoft社でもこういうことがあるのかと思った。無事解決できてメデタシメデタシである。いやいや、めでたくない！結局、「multiprocessing」を使っても時間を
短縮することができなかった。
しかしながら、大きな収穫はあった。「multiprocessing」には「Pipe」や「Queue」というクラスがあって、それぞれの実行中のプロセス？にアクセスできるらしいのだ。
これを使ってwavファイルを読み込みながら再生するということをやってみようと思う。それができれば、ミュージックプレイヤーアプリ作成の最難関と考えているこの課題（素早く再生を
開始）はクリアできると思う。おっと、もう一つ特大の難関があったのを忘れていた。WASAPIやASIOである。製作中のアプリは、このAPIに対応できていなければ意味はない。
ページトップへ戻る
ミュージックプレイヤーアプリ3
前回の「ミュージックプレイヤーアプリ2」でギャップレス再生が上手くいったと書きました。その方法を書きます。最初にやったことは、１曲毎に音楽ファイル（wave形式）読み込み、
ストリーミング、ストリーミング終了というステップを繰り返すやり方です。
この方法で書いたpython3のプログラムの内容は以下のような順（フローチャート？）で書きました。
1.音楽ファイルの入っているフォルダNOを入力し選択
↓
フォルダ内のフォルダを「番号：フォルダ名」で表示
↓
2.フォルダ内に演奏者ごとに分かれたフォルダが入っているので、演奏者フォルダNOを入力し選択
↓
フォルダ内のフォルダを「番号：フォルダ名」で表示
↓
3.演奏者フォルダ内に各アルバム（曲名）のフォルダが入っているので、アルバムフォルダNOを入力し選択
↓
アルバムフォルダ内のファイルを「番号：曲名（ファイル名）」で表示
↓
4.１曲目の曲を読み込み（総フレーム、チャンネル数、サンプリング周波数、フレーム数）
↓
5.pyaudioでストリーミング再生開始
↓
6.再生終了＆ファイルクローズ
↓
7.２曲目の曲の読み込み
・
・
最終曲まで続行
上の流れですと、ギャップレス再生ができませんでした。因みに、ギャップレス再生とは、再生する曲間にギャップ（音の空白）ができないようにする再生のこと。対策として、
再生時のみスレッドを２つ立ち上げ（プログラム平行処理）、No.1スレッドは１曲目を再生＆再生後２曲目の演奏時間分待機、No.2スレッドは１曲目の演奏時間分
待機後２曲目を再生。要はNo.1スレッドは奇数番号の曲を再生、No.2スレッドは偶数番号の曲を再生。
時間の流れ：－－－－－－－－－－－－－－－＞
スレッド1：No.1再生・・・・・No.3再生準備・・・No.3再生・・・・・・No.5再生準備・・・・・・
スレッド2：NO.2再生準備・・・No.2再生・・・・・No.4再生準備・・・・No.4再生・・・・・・・・
調べたところ、曲間の処理に時間がかかるのなら、準備時間を空ければいいと分かりましたのでそうしました。
結果、ダメでした。
なぜダメなのか悩みましたが、一つずつ調べればいいと気づき、ギャップが発生している原因を突き止めました。ファイルの読み込みには、さほど時間はかかりません。0.005秒
とか、そのレベルです。for文で次の曲の再生を指示しているのですが、再生終了後、次の曲の再生指示までもさほど時間はかかってないです。開いたwavファイルを
ストリーミング始めるのに時間がかかってました。早くても0.5秒。その程度？と思うかもしれませんが、切れ目無しで続いている曲を聴くとツライです。2、3分ごとに細かく分割
されている曲など特に聴けるものではありません。
結局、ギャップ発生が、引っ張ってきている再生モジュールそのものに起因しているので、現時点の私の力量では手が出せません。
そもそも、「ミュージックプレイヤーアプリ1」でも書いたように、このモジュールの使用用途が間違っているように思いました。
そこで、「ミュージックプレイヤーアプリ2」で書いたsounddevice（再生モジュール）とsoundfile（ファイル読み書きモジュール）というモジュールを見つけ、使い方を調べました。
非常にシンプルでした。が、再生すると、やっぱりギャップが発生。。。。。orz ただ、sounddeviceは、再生するデータをlist型ではなく、arrayの配列で積み上げて
使用するように思いました。何分、英語のサイトなので、どこまで理解できているか自信がありません。それでも、配列を積み上げているということは、1曲目に2曲目の
配列を積み上げてしまえばいいのでは？と思いました。そうすれば、曲間の継ぎ目が無くなりますから。この考えはかなり自信がありました。
結果、あっさり上手くいきました。ただ、「numpy]というモジュールの扱いにはかなり苦労しました。
うまくはいきましたが、別の問題が出てきました。ギャップレス再生をするためには、一度に全曲読み込むので、再生準備に時間がかかるということです。長いアルバムですと、
7、8秒待ち時間があります。
現在、その問題を攻略中です。
ページトップへ戻る
ミュージックプレイヤーアプリ2
結局、pyaudioでは自分の作りたいアプリができないのではという結論に達したため、それなら自分でpyaudioのようなモジュールを作ってやろうじゃないかと思い、色々
調べてました。超初心者ではありますが、気合は入ってます。それで、音楽ファイル（wavなど）を再生するモジュールを作るためには、どうしたらいいのかと調べました。最初に
調べたのは、音楽ファイルをどう処理しているかということ。pyaudioを使用したとき、サンプリング周波数とか量子化ビット数とかフレーム数、チャンネル数というものが分かりました。
CDなどに保存してあるデータに上記の情報が入っていると分かりました。再生モジュールを作るとなると、それだけでは何をどうすればいいのかさっぱり分かりません。それで、下記
のことを調べました。
1.WAVE形式（CDに使用されている形式）とはどういったものなのか。
2.WAVE形式のデータをどのように再生するのか。
3.WASAPIとDIRECT SOUNDの違い。（大まかには知っていた）
4.デジタルデータの処理方法
5.USB-DACへデータを送信する際、どのようにするのか。
1.は理解できました。
WAVE形式は、まず保存してある音楽データ部の前にその音楽データの仕様が保存されています。
チャンネル数 ：
モノラルかステレオか。
サンプリング周波数 ：
１秒間の音を1/44100＝0.000022675秒毎にその音の周波数の振幅（大きさ）を記録してある。要は１秒間に音の周波数を44100回サンプル
取っているというわけ。
量子化ビット数 ：
１秒間に44100回、音の周波数の振幅（大きさ）のサンプルを取るとき、その大きさを何段階に分けるかという情報。通常、CDでは16bitを使用している。
16bitとは16段階という意味ではありません。2の16乗という意味です。2を16回掛けるという意味。2の16乗＝65536。即ち、65536段階で大きさを
表現しているということ。因みに24bitは2の24乗＝16777216段階です。
フレーム数 ：
記録してある音楽データの数。（データサイズ）
他にも情報が記録されているが、各情報を記録する際、それぞれ決められたバイト数（1バイト＝8ビット）が割り振られている。その為、CDに記録されている情報の内、音楽データ
が先頭から何バイト目から始まるか決まっている。
2.も大よそ理解できたつもりです。
サンプリングされた各データをつなぎ合わせて、元の音の波形を再現するという手法。ただ、その作業はデジタル→アナログへの変換を行うDAC（Digital Analog Converter)
の仕事になります。
3.も多分理解できてると思います。間違ってたら指摘してください。
WASAPIとはWindows Audio Session API。API（Application Program Interface）とは、他のプログラムと連携するときの接続仕様。
WASAPIには、共有モードと排他モードがあり、共有モードはWindowsの通常の再生デバイスのDIRECT SOUNDへ音楽再生アプリから再生データが送られる。排他モードは、
DIRECT SOUNDなどをパスして音楽再生アプリからDAC（PCオーディオの場合、USB-DACなど）へ再生データが送られる。
4.もおおよそ理解しました。
2.についてのもっと詳細な内容です。一言では書けません。
5.が一番やっかいでした。
DACへデータを送信するのだから、バイナリデータ（2進数データ）だなとか、USBからDACへデータを転送する仕組みとか、どういうプログラムを書けばいいのかとか。WASAPIを使うには
どうすればいいのかとか、WASAPIはC++で書かれているけどPythonで利用するにはどうすればいいのかなど。色々調べましたが、超初心者の私にはまだまだ理解が足りないようです。
しかし、pyaudioのような再生モジュールを作るためにはどうしてもこれらのことを理解することは必須で、避けては通れません。
以上のようなことを調べていたのですが、5について調べていたら、pyaudio以外に再生モジュールが見つかりました。sounddeviceというモジュールとsoundfileというモジュール。
WAVE形式のファイル処理はsoundfileで行い、再生をsounddeviceで行うものでした。
ギャップレスの連続再生が上手くいきました。長くなったので、次回そのへんのことを書きます。
ページトップへ戻る
ミュージックプレイヤーアプリ1
最近、PCオーディオからさらに踏み込んでミュージックプレイヤーのアプリを作り始めた。使用言語は、Python3.6です。作り始めたらこれがなかなか面白くてハマってます。
プログラミング超初心者です。pythonでwavファイルを再生しようと色々調べていたら、pythonにはwaveモジュールというものが見つかったので、再生できるものと思って
色々とwebで調べていたらwaveモジュールだけでは再生できなそうということが判明。さらに、webで検索を進めたらpyaudioというモジュールが見つかり、早速プログラムを
組んでみました。一発ではうまくいきませんでしたが、あれこれ調べながらやっていくうちに再生できました。wasapiとかそういうことは後回しで、まずは再生できるソフトを作れるか
どうかです。
次は、連続再生ができるプログラムに挑戦です。フォルダ内にあるwavファイルを連続再生するプログラムを作りました。フォルダ内にはwavファイルのほか、2種類別のファイルが
存在したので、フォルダ内のwavファイルだけをプログラムの中のリストに挿入して、そのリスト内のwavファイルを再生することにしました。リストを作るところまでは、すんなりと進みましたが
連続再生をさせるために、while文を使用してみましたが、うまくいかないので、for文で作成しました。超初心者ですから、while文とかfor文の使い方も調べながら進んでます。
for文でうまくいきました。次々に曲が再生されていったときはテンション上がりましたよ。因みに、再生した曲はバッハのゴルトベルク変奏曲。グールドです。ただ、ギャップレス再生に
なっているか判断できなかったので、今度はマーラーの交響曲第9番を再生。シノーポリ＆フィルハーモニア管です。この曲は各楽章が細かく分割されているので、曲と曲の間に
無音の隙間があると気づきます。確認のため再生したら、やはりギャップレス再生できてませんでした。隙間があるため、細かく分割されている曲は気に堪えません。
今度は、ギャップレス再生を可能にすべく調べまくって、試行錯誤の連続でした。現在、分かったのはpyaudioはweb上でのstreaming再生向けのモジュールなのではと
思い至りました。ですから、使用用途が違っていたようです。youtubeのような使い方をするモジュールだと思います。仕切り直して先へ進んでいます。
閑話休題
今月に入って、下半身を強化しようと思い至ってしまいました。iphoneのアプリ検索で見つけたのはNIKEのトレーニングアプリです。無料です。登録してビックリ！初級から上級
まで、器具を使うトレーニング、使わないトレーニング等様々なトレーニングメニューを用意してくれていました。私がやり始めたのは、クリスチャーノ・ロナウド選手のクイックヒットとかいう
下半身強化のメニューです。初級です。ウォームアップからトレーニングの最後まで18分。初級だろと思って舐めてました。始めた初日はトレーニング終了後、息が上がりまくってました。
キツイなんてものではなかったです。太腿はパンパン。プロテインを飲むために2階から1階へ階段を降りようとしたら、足がガクガク。もちろん、次の日は筋肉痛。3日後ようやく筋肉痛が、
治まりました。とは言え、鍛えればどんどん体力は戻ってくると思っていました。2回、3回と続けていくうちに少しづつ負荷が軽く感じるようになってきました。昨日で8回目。8月になったら、
上半身のトレーニングも始める予定です。
ページトップへ戻る
PCオーディオ1
私はパソコンに詳しいわけではないのだが、色々弄るのは嫌いではない。嫌いではない理由の一つに困り事があってもWEBで検索すれば大抵解決方法が見つかるからである。PCオーディオも同じでWASAPIだとかASIOという排他的モードというものをWEB検索により理解することができた。簡単に説明すると、ＣＤから音楽をパソコンに取り込むと.wav（ＣＤ再生音質）とか.mp3（ＣＤ再生音質より劣る）とかの音楽ファイルがハードディスク（パソコン内）にできる。その音楽ファイルをiTunes（アップル）とかMUSIC CENTER（ソニー）とかの音楽再生ソフトで再生する。そのとき、データがパソコンからスピーカーまで届く経路がパソコン→アンプ→スピーカーとすると、再生音にノイズがかなり乗ってしまう。デジタル信号なのにノイズは酷いことになっている。何故かというと、パソコン内の回路はノイズだらけということらしい。パソコンのノイズは、昔ラジオを聴いたときにバックで聞こえてた「サーーー」という音ではなく、パソコンのノイズは音を捻じ曲げてしまう質の悪い代物。実際、このノイズをカットできたとき音質の違いに愕然とした。
ノイズをカットする方法は、再生したデータを通常パソコン内で通過する経路をすっ飛ばしてＵＳＢ端子まで持って行くという方法なのだ。なので、捻じ曲げられることなく、パソコンの次のオーディオ機器へデータを送り込むことができる。ただ、パソコンとアンプの間にＵＳＢ－ＤＡＣというデジタル信号をアナログ信号に変換するオーディオ機器が必要になってくる。（最近ではアンプにデジタル/アナログ変換装置を内蔵しているものがある。）もちろん再生ソフトも「ＷＡＳＡＰＩ排他モード」もしくは「ＡＳＩＯ」に対応しているものでなくてはならない。残念ながらiTunesは対応していない。ＭＵＳＩＣ ＣＥＮＴＥＲは両方に対応している。しかも量子化ビットとサンプリング周波数を選択することができる。（サンプリング周波数のことは次の機会に書きます。）
なぜPCオーディオについて書いたかというと、音質の向上具合が半端ではないので、それを誰かに伝えたいと思ったというわけです。しかも、ハイレゾ音源を手軽に比較的安価で聴けるから。そして、ハイレゾの音楽ファイルをネットでダウンロードすれば高音質であっさり再生できてしまうのだ。ネットでダウンロードできるハイレゾ音楽ファイルは現在のCD容量700MB（８０分）を大きく超えてくる。24bit/96kHz仕様で８０分の音楽データが2.7GBになる。DVDだとかBDじゃないと記録できない。そう、だから比較的安価で聴くにはダウンロードするしかないのだ。と言いつつも私はまだネットからハイレゾ音源を購入したことはない。そのうち購入してみよう。
ページトップへ戻る