Pure Digital Audio 考察：　SDカードやHDDの音楽ファイルのデータを改善してくれる：　Rewrite data 1.05

考察：　SDカードやHDDの音楽ファイルのデータを改善してくれる：　Rewrite data 1.05

SDカードを書き換えることによって音が良くなる理由について、少し考えてみた。
これが正しいのかどうかは断定は出来ないが、一つの可能性ではあり、結構可能性は高いのではないかと思う。

SDカードやHDDはデータを読み書きする仕組みとしてファイルシステムという方式を使っている。
一般的に良く使われるのは、FATというものやNTFSなどが多い。SDカードは１００％がFATだといっても良いのではないか。理由はPCでもLINUXなどUNIX系のOSでもどちらでも見えるからだそうな。

ファイルシステムと言うのは、磁気記録の円盤が回転して記憶しているハードディスクに、いかに適切にデータを読み書きするかのためのアクセス方式。

詳しくは、下記のWebなど見て頂くとして、

　　FATファイルシステム

　　FAT ファイルシステム

　　FAT FS フォーマット

一言で言うなら、2番目の文書にある、

FAT ファイルシステム

MS-DOSにおけるブロックデバイス(フロッピーディスク、ハードディスク)上のファイルを管理するためのしくみ。ユーザーが論理的に扱うファイルやディレクトリを、実際の物理的なディスク上に対応させ、ファイルやディレクトリ自体を構成する体系をファイルシステムと呼ぶ。MS-DOSのファイルシステムは、ディレクトリエントリとFAT(File Allocation Table)という情報によって管理されている。 MS-DOSでは、ファイルのアクセスはセクタ単位で行なわれるが、ファイルに対してディスク上の物理セクタを割り当てる場合、セクタではなく、クラスタと呼ばれる単位で割り当てを行なう。1クラスタは、物理セクタの2のべき乗倍となるように、ディスクの種別や容量によって決まっている。ファイルはクラスタを単位として構成されているが、クラスタのディスク上の物理的な位置は常に連続しているわけではない。そのため、FATによってそれらのクラスタがどのような順につながって、1つのファイルを構成しているかが管理されている。FATの各エントリは、ディスクの各クラスタと1対1に対応しており、該当するクラスタの使用状況を表わしている。ファイルの開始クラスタは、ファイル名やファイルのサイズとともにディレクトリエントリに記録されており、その次のクラスタを指しているのは、最初のクラスタに対応するFATのエントリの内容である。

というのが一番端的にあらわしていると思う。

難しい話はさておき、ここで大事なのは、ファイルを記憶するのに、ディスク上の物理的なメモリーの位置はバランバランであるということ。

音楽データは一つのデータの後には必ず次のデータが来るのだが、HDD上ではどこにあるのか全く予想もつかないということ。そしてそれがどこに書いてあるかを表わしているのが、”FAT"というテーブルであるということ。

要するに、異なるファイルシステム上にあるデータは、PCを使ってファイルとして比較して同じであっても、HDDやSD上でどこにどう書いてあるかは全く異なるということ。

巷では、”SDカードやHDDを何度も書き換えていくとどんどん音が悪くなる”　みたいな事が言われているようだけれど、ファイルシステムを使ってデータを書き換えていけば、どんどんデータの並びがバラバラになって、HDDならばヘッドの移動時間が長くなるし、ヘッドの移動のための電流も多くなるから、PCのノイズが増えて、音が悪くなるのは当たり前だと思う。極端なことを言えば、データの１クラスター（数十～数百キロバイト）毎にハードディスクのヘッドが最内周と最外周を頻繁に移動するという事だって起こりうるはずだ。そうなればヘッドの移動には数十ミリＳＥＣかかるはずだから、データが間に合わないって可能性だってあると思う。

Rewrite data 1.05　がファイルシステム上でのデータの並びを何かしら綺麗にしてくれる様なソフトウェア（たとえば、データの並びを綺麗に順番道理に並べてくれるとか）なら、音が変わる可能性はあると思う。

本当にＰＣ（デジタル）オーディオの高音質化を考えるなら、音楽やビデオの様な連続ファイルをきちんと扱うためのファイルシステムの設計から考えないといけないのだと思うけどね。そんなまともなことをやる会社は無いんだろうな。。。

<<追加実験：　SDカードやHDDの音楽ファイルのデータを改善してくれる：　Rewrite data 1.05 | ホーム | その後：　SDカードやHDDの音楽ファイルのデータを改善してくれる：　Rewrite data 1.05>>

仰るとおり、データ比較しても同じデータとのことなので、0/1はあくまでも0/1で、
書き込み深度が影響しているのかもですね。

データ転送経由(I/OやBus)が多くなれば遅延が余計に生じbitデータ幅が狭くなる
よって書き込み深度に影響しているのか？

考えられるのは、以下のデータの流れとプログラムの高速最適化
通常：SDカード -> I/O -> CPU -> RAM(キャッシュ) -> CPU -> I/O -> SDカード
Rewrite：SDカード(HD) -> I/O -> CPU ->I/O -> SDカード(HD)

2015/01/05(月) 18:30:44 |
URL |
tsdoctor #-
[ 編集 ]

tsdoctor さん
こんにちは。不思議ですね。
デフラグがどこまでキレイにデータを並べてくれるのか解りませんが、データの並び以外に私には差がある可能性を思いつきません。さすがに、１と０以外に０・９があるなんてバカな事は言う気にはなれないし、いくら書き込みアルゴリズムが違ったって、最終的にＳＤカード上で何か違わないと音が違うはず無いですもんね。。。
データの並び方以外に何かあり得るでしょうか？？
あとは、書き込みの深さみたいな事は有るかも知れないですね。何度かファイルが読めなくなる事が有りました。

2015/01/05(月) 14:03:56 |
URL |
Cocoパパ #-
[ 編集 ]

テクニックを教えますから、同時書き込みを避け、各メディアの専用バッファを設ける
（HDやOSのキャッシュを無効にする）、
そしてプログラムの最適化で高速処理を行っている。
拡張命令のMMX（データ転送・算術演算・論理演算・比較・パック演算・EMMS ）で、
メモリを使って処理しないでMMXレジスタを利用して高速化処理している。
ただ単純にキャッシュ制御とプログラムの最適化高速処理でコピーしているようです。

2015/01/05(月) 11:20:50 |
URL |
tsdoctor #-
[ 編集 ]

ハードディスク内部やOSのキャッシュを無効にする。
と書かれている部分があるので、キャッシュ関係が問題では無いのでしょうか。
アプリケーションソフトもRewriteすれば良くなるとも書かれていますね。

断片データ配置の問題であれば、
データ断片化の再配置(デフラグ)や物理フォーマット(論理でも良いかも)を行い書込めば
良いだけでは無いでしょうか。

同じ速度規格のSDカードに同じデータをコピーしても同じ音が出ないことも
同じような要因が関係しているのか？

でも確かに音は良くなっていますね。