音楽ファイルは10年後も同じ音で再生できるか

リッピングした音源を10年後に開いたとき、当時と同じ音で再生できる保証はあるでしょうか。

HDDは物理的に壊れますし、ビットロットと呼ばれる目に見えない破損も現実に存在します。データセンターの大規模調査でも、膨大なファイルのうちごく一部が静かに壊れていく現象が確認されています。

この記事では、音楽ファイルの整合性を保つための3つの柱「コピー時のビット一致」、「保管中の破損検知」、「多重バックアップ」をオーディオ観点で整理します。

FastCopyとPowerShellを使った具体的な手順、FLACとWAVでチェックサムの扱い方がどう違うのか、そして万一エラーが出たときの復旧方法まで踏み込みます。読み終えたときには、手元の音源を安心して長期保管するための現実的な運用が見えているはずです。

音楽ファイルを守る3つの柱

細かい手順に入る前に、全体像から示します。音楽ファイルを長期的に守るために必要な要素は、突き詰めると3つだけです。

コピー時のビット一致を担保すること。

バックアップ先にコピーした時点で、既に1ビット壊れていたら意味がありません。FastCopyのベリファイ機能がこの役割を担います。

保管中の破損を検知する仕組み。

コピー直後は完全でも、保存しているディスクの中で数年かけて静かにビットが反転することがあります。これを検知するのがチェックサムの本来の役割です。

コピーを複数持つこと。

いくら検知できても、壊れたデータしか手元になければ復旧できません。最低でもオリジナルと2つのバックアップ、合計3コピーが目安になります。

この3つが揃って初めて、音源は長期的に守られます。どれかひとつでも欠けると、気づいた時には手遅れになる可能性があります。

そもそも音楽ファイルは壊れるのか

「デジタルデータは劣化しない」と言われることがありますが、これは半分正しくて半分間違っています。コピーや再生で劣化はしませんが、保管中は物理媒体の影響を受けて壊れることがあります。

サイレントデータ破損という現象

HDDの物理故障なら気づけます。起動しない、異音がする、読み取りエラーが出る。分かりやすい形で現れるからです。

厄介なのはサイレントデータ破損と呼ばれる現象で、ディスクもOSもエラーを報告しないままファイルの中身だけが書き換わってしまう状態を指します。音楽ファイルでこれが起きると、特定の箇所でノイズや音飛びが出たり、最悪の場合は再生自体ができなくなったりします。しかも再生するまで気づけません。

実際の破損率

CERNが行った調査では、6ヶ月間に97ペタバイトのデータを検証し、約128メガバイトが恒久的に破損していました。NetAppが150万台のHDDを41ヶ月追跡した結果では、40万件以上のサイレントデータ破損が検出され、そのうち3万件はRAIDコントローラーでも検知できませんでした。

Backblazeの2025年レポートではデータセンター内のHDDの年間故障率が1.36%、つまり100台に1台強が1年以内に壊れる計算です。

家庭環境はデータセンターより温度や電源の条件が厳しいことが多く、むしろリスクは高い側と見るべきです。破損の頻度は低くても、リッピングに費やした時間を考えれば対策する価値は十分にあります。

では、この破損をどう検知するか。次に取り上げるチェックサムという仕組みが、その答えになります。

チェックサムの基本

具体的な手順に入る前に、チェックサムとは何かを整理しておきます。ここを理解しておくと、以降の話が全て腑に落ちます。

チェックサムはファイルの指紋

チェックサムは、ファイルの中身から計算された短い数値です。ファイル全体を特定の計算式で処理して固有の値を作り出すので、中身が1ビットでも変われば値も変わります。人間の指紋のようなもので、同じファイルなら必ず同じ値、違うファイルならほぼ確実に違う値になります。

音楽ファイルの世界でよく使われるのがMD5という計算方式で、32文字のアルファベットと数字の組み合わせで表されます。リッピング直後にMD5を記録しておけば、数年後に再計算して突き合わせるだけで「このファイルは作成時と同じか、どこか変わっているか」を判定できます。

重要なのは、チェックサムは 「最初に記録した基準値との比較」 でしか破損を判定できないという点です。ファイル単体を見ても「これが正しい状態か」は判定できません。基準となる値を先に記録しておき、後から再計算した値と比較するー これがチェックサム運用の本質です。使っている手法がFLACの内蔵MD5でも、PowerShellのGet-FileHashでも、NASのBtrfsでも、この構造は共通しています。

FLACは内部にMD5を持っている

FLACはエンコード時にオーディオデータのMD5ハッシュを計算し、ファイル自身のヘッダーに書き込んでいます。つまりファイル単体で「作成時の内容」を記憶しています。検証はコマンドラインで flac -t ファイル名.flac を実行するだけで済み、外部にハッシュリストを管理する必要がありません。

FLACを選ぶ最大の実用的メリットは、圧縮率ではなくこの内蔵チェックサム機能だと個人的には考えています。

FLACのもうひとつの利点は、入手直後のファイルをいきなり検証できる点です。ネットで購入したハイレゾFLACも、中古で譲り受けた音源も、その場で flac -t やfoobar2000を実行すれば健全かどうか判定できます。外部にハッシュリストを持つWAVやDSFでは、自分で基準を記録してからでないと検証が始められないため、初回検証のしやすさはFLACならではの強みです。

WAV、DSF、AIFFは外部管理が必須

一方、WAVとAIFFは音声データを素直に並べただけの単純な形式で、ファイル内にハッシュを持ちません。DSF(DSDファイル)も同様です。ファイルを開いて読み出せるかどうかは確認できても、中身が作成時と同じかどうかはファイル単体では判定不可能なのです。

したがってWAV/DSF/AIFFを長期保管する場合は、外部にハッシュリストを持ち、定期的に現在のファイルから計算したハッシュと突き合わせる必要があります。面倒ですが、この一手間が破損検知の唯一の方法です。

基準ハッシュを取るタイミングは、リッピングまたはダウンロード直後が最も理想的です。時間が経つほど「いつから壊れていたか分からない」状態のまま基準を取ることになり、信頼性が下がります。

私はWAVとDSF、AIFFを使う機会が多いため、この外部ハッシュ管理の運用を続けています。次章では、FLACも含めて全ての音源を一元管理できるPowerShellベースの運用を紹介します。

バックアップの取り方

3つの柱のうち最初に扱うのは、コピー時のビット一致と多重化、つまりバックアップそのものの運用です。ここではFastCopyを使った手順と推奨モードを整理します。

FastCopyのベリファイと差分コピー

FastCopyは通常のコピー&ペーストより優れている点が2つあります。ベリファイ機能と差分コピーです。
公式：FastCopy

ベリファイを有効にすると、コピー完了後に書き込んだ側のハッシュを計算し、元ファイルのハッシュと照合してくれます。Windowsの通常コピーはエラーが出ない限り「コピー成功」と判断しますが、これでは実は1ビットズレていたという事故を防げません。ベリファイは書き込みが物理的に完了した状態で読み直して確認するので、より信頼性が高い処理になります。

もうひとつの特徴が差分コピーです。コピー先に既にあるファイルを全て再コピーするのではなく、変更があったファイルだけを対象にするので、マスターに数枚アルバムを追加した程度のメンテナンスなら数秒で同期が終わります。

推奨モードは「差分(最新日付)」

FastCopyには複数の動作モードがありますが、バックアップ用途では「差分(最新日付)」モードを推奨します。これはコピー元の更新日時がコピー先より新しい場合のみコピーを実行するモードです。

同期モード(削除も反映するモード)は、マスター側で誤ってファイルを削除するとバックアップからも消えてしまいます。バックアップの本来の目的に反する動作なので避けましょう。差分(最新日付)なら誤削除がバックアップに伝播せず、万が一のときに復元元として機能します。

なお、差分コピーは「コピー元と同じ状態に保つ」動作なので、タグ編集などでファイルが更新されればバックアップ側も上書きされます。編集前の状態を残したい場合は、編集前に手動でコピーを取る必要があります。

私の運用では、差分(最新日付)+ベリファイONを基本設定にしています。マスターHDDに新しいリッピング音源を追加したあと、バックアップ先へ同じジョブを流すだけで、追加分だけが整合性チェック付きでコピーされます。日常のバックアップ作業として、これ以上手軽で確実な方法は思いつきません。

FastCopyの盲点とチェックサムの役割分担

ここで注意したいのが、FastCopyは「コピー元とコピー先の一致」を保証するツールであって、「コピー元の正しさ」は保証しないという点です。マスターが破損した状態でコピーすれば、破損したままバックアップに書き込まれる可能性があります。

そこで必要になるのが次章のチェックサム検証です。FastCopyがコピー時の整合性を担保し、チェックサムが保管中の整合性を担保するー この役割分担で初めて、音源は本当の意味で守られます。

チェックサムの実行方法

保管中の破損を検知する方法として、ここではPowerShellを主軸に据えます。FLACでもWAVでもDSFでも、1つのツールで全ての音源を一元管理できるためです。

PowerShellで全音源を一元管理

Windows 10以降に標準搭載されているGet-FileHashコマンドを使えば、追加のソフト無しでハッシュ管理が可能です。FLACだけを使うユーザーには後述のfoobar2000の方が手軽ですが、将来WAVやDSFも扱う可能性を考えると、最初からPowerShellに慣れておく方が応用が効きます。

PowerShellでの運用は、大きく「初回の基準記録」と「定期検証」の2段階です。初回はハッシュ値をCSVファイルに保存して基準を作り、以降は半年〜1年に1度のペースで再計算して基準と突き合わせます。以下に手順を順を追って説明します。

事前準備ー PowerShellの基本

本格的な手順に入る前に、PowerShellを使ううえでの最低限の知識をまとめておきます。

起動方法ー Windowsキーを押して「PowerShell」と入力し、表示された候補からクリックすれば起動します。読み取り中心の処理なので管理者権限は不要で、通常起動で問題ありません。

音源フォルダのパスー 以降のコードでは音源フォルダを D:\Music と指定しています。実際の環境に合わせて書き換えてください。Cドライブ直下のMusicフォルダなら C:\Music、ユーザーフォルダ内のMusicなら C:\Users\ユーザー名\Music のような形になります。フォルダのエクスプローラ画面でアドレスバーをクリックすれば、パスを文字列として確認できます。

ハッシュリストの保存先ー 結果を保存するCSVファイルのパスも同様に書き換えます。記事中では D:\hash_baseline.csv としていますが、デスクトップに保存するなら C:\Users\ユーザー名\Desktop\hash_baseline.csv などに変更してください。

実行方法ー 以下のコードブロックをコピーし、PowerShellウィンドウに貼り付けてEnterを押すだけです。複数行のコードもそのまま貼り付けられます。

初回のハッシュリスト作成

この初回処理は「今のハッシュ値を基準として記録する」作業で、エラーの判定はまだ行いません。半年〜1年後に再計算したハッシュと比較することで、初めて破損の有無が分かります。

次のコマンドを実行してください。

Get-ChildItem -Path "D:\Music" -Recurse -Include *.flac,*.wav,*.dsf,*.aif,*.aiff |
Get-FileHash -Algorithm MD5 |
Select-Object Hash, Path |
Export-Csv -Path "D:\hash_baseline.csv" -NoTypeInformation -Encoding UTF8

実際にPowerShellに貼り付けて実行すると、上のような画面になります。コマンド行末に |(パイプ)がある場合、次の行の先頭に自動で >> が表示されますが、これは「続きの入力待ち」を示すもので正常な動作です。

実行すると、指定フォルダ以下のFLAC、WAV、DSF、AIFFファイル全てのMD5ハッシュがCSVファイルとして保存されます。処理時間の目安は、内蔵HDDで1TBあたり1.5〜3時間、内蔵SSDなら10〜15分程度です。10TB規模の音源で内蔵HDDの場合、半日〜1日かかることもあるので、寝る前や外出前に走らせるのが現実的です。

処理中はCSVファイルをExcelなど他のソフトで開かないでください。ファイルがロックされて書き込みエラーになり、処理が正しく進まなくなります。内容を確認したい場合は、処理完了を待ってから開くか、PowerShellの Import-Csv コマンドで内容を表示してください。

もうひとつ、Windowsにはファイルパスが260文字を超えるとアクセスできない制限があります。曲名が長いクラシック音楽のDSF/WAVなどで遭遇することがあり、実行時に「項目が見つかりませんでした」エラーとして表示されます。この場合、Windows設定で「Win32の長いパスを有効にする」を有効化するか、ファイル名を短縮して対処します。

完了すると、指定した場所にCSVファイルが作成されます。Excelで開くと、Hash列とPath列にハッシュ値とファイルパスが1行ずつ記録されていることが確認できます。

定期検証

ビットロットは数年単位でじわじわ進む現象なので、月次のような頻繁な検証は必要ありません。半年〜1年に1回の頻度で十分です。

初回のハッシュリストができたら、あとは同じ計算を行い、差分があるかを確認します。検証用スクリプトは次のような内容になります。

# 現在のハッシュを再計算
$current = Get-ChildItem -Path "D:\Music" -Recurse -Include *.flac,*.wav,*.dsf,*.aif,*.aiff |
  Get-FileHash -Algorithm MD5 |
  Select-Object Hash, Path

# 基準ハッシュを読み込み
$baseline = Import-Csv "D:\hash_baseline.csv"

# 差分を検出
$baseline | ForEach-Object {
  $b = $_
  $c = $current | Where-Object { $_.Path -eq $b.Path }
  if (-not $c) {
    Write-Host "MISSING: $($b.Path)" -ForegroundColor Yellow
  } elseif ($c.Hash -ne $b.Hash) {
    Write-Host "CORRUPTED: $($b.Path)" -ForegroundColor Red
  }
}

破損しているファイルがあれば赤字でCORRUPTEDと表示され、ファイルが消えていればMISSINGと出ます。何も表示されなければ、全ファイルが初回時点から1ビットも変化していないということです。

基準CSVの更新ルール

運用の基本は、タグ編集はリッピングや購入の直後にまとめて行い、その状態で基準ハッシュを記録することです。タグ編集とチェックサムを同じタイミングで済ませると、後の運用が楽になります。

問題は、時間が経ってからタグを編集したくなった場合です。ファイルのハッシュは変わりますがパスは同じままなので、自動検出スクリプトでは「新規」として認識されず、半年後の定期検証でCORRUPTEDと表示されます。

この場合の対応は2択です。ひとつはそのままにしておき、次の検証でCORRUPTEDが出たらタグ編集分と判断してスルーする方法。もうひとつは、タグ編集前にフォルダ名へ年号を付けるなど軽い変更を加え、新規として認識させてから基準CSVに追加する方法です。

前者は手軽でRoonの再生履歴も保たれますが、定期検証の判定が曖昧になります。後者は検証の信頼性が高い代わりに、Roonで別アルバム扱いになります。どちらを選ぶかは、再生ソフトの使い方と運用の手間のバランスで決めてください。

よく使うコマンドの早見表

運用でよく使うコマンドをまとめておきます。ファイルパスは実際の環境に合わせて書き換えてください。

単体ファイルのハッシュ確認は、次章のエラー対処で特に重要になります。

他のチェックサム手段

PowerShell以外にも、環境や用途に応じて使える手段があります。どれもPowerShellの代替というより補助として位置付けるのが現実的です。

foobar2000のVerify Integrity(FLAC限定の簡易手段)

FLACのみを扱うユーザーには、foobar2000の「Verify Integrity」機能が最も手軽です。ライブラリでFLACファイルを全選択し、右クリックからUtilities→Verify Integrityを選ぶと、破損ファイルがあればレポートに一覧表示されます。内部では flac -t と同じMD5検証を行っているため、信頼性はコマンドラインと同等です。

ただしWAVやDSFには対応しないため、混在ライブラリでは前述のPowerShell運用が必要になります。

Synology NASのBtrfsスクラビング

Synology NASを使っている場合、ボリュームをBtrfsでフォーマットしていれば、OSレベルでのチェックサム検証が使えます。Btrfsはブロック単位でチェックサムを自動記録する仕組みを持ち、スクラビング処理で全ボリュームを検証できます。

DSMのストレージマネージャからストレージプールを選び、「タスクのスケジュール」→「データスクラビング」で月次または四半期ごとの自動実行を設定できます。詳しい設定手順はSynology公式ドキュメントのデータスクラビングページを参照してください。

NAS環境を活用できる点が強みですが、PC側の音源は別途PowerShellで管理する必要があります。

エラーが出た時の対処法

定期検証で赤字のCORRUPTED表示が出ると、慌てる気持ちになります。しかしここで焦って対処すると、かえって被害が拡大する危険があります。深呼吸して、以下の手順で対処していきましょう。

破損が検知されたら最初にやること

CORRUPTED表示を見たら、慌ててFastCopyで同期を走らせてはいけません。マスター側が破損している場合、バックアップに破損が伝播する可能性があります。まずはマスターのバックアップを止めた状態で、以下の確認を進めます。

もうひとつ確認したいのが、最近そのファイルをタグ編集していないかです。mp3tagなどでタグを書き換えると、ファイル全体のMD5が変わるため基準ハッシュと一致しなくなり、誤検知としてCORRUPTEDが表示されます。編集の記憶があれば、破損ではなく基準ハッシュを更新すれば済む話です。

どのコピーが正しいかの判定

タグ編集の誤検知でない場合、次は「どのコピーが健全か」を判定します。使える手がかりは3つあります。

1. 基準CSVとの照合ー バックアップ側のファイルのハッシュを単独計算し、基準CSVに記録されたハッシュと比較します。一致すればバックアップは健全です。基準CSVの記録時点でマスターが健全だったことが前提になりますが、最も確実な判定手段です。

2. 3コピー間の多数決ー マスター、NAS、外付けHDDの3つでそれぞれハッシュを計算し、2つ以上一致する値を正解と判定します。ZFSやBtrfsの自己修復と同じ原理で、1つが破損していても確実に正解を導けます。

3. FLACなら内蔵MD5で独立検証ー FLACは flac -t が「作成時の状態」を判定できるため、基準CSVがなくてもバックアップ側のファイル単体で健全性を確認できます。これもFLACを使うメリットのひとつです。

バックアップからの復旧手順

健全なコピーが特定できたら、以下の手順で復旧します。

まずバックアップ側のハッシュ値を確認します。次のコマンドで単体ファイルのハッシュを計算できます。

Get-FileHash "E:\Music\AlbumA\01.wav" -Algorithm MD5

この値が基準CSVに記録されたハッシュと一致すれば、バックアップは健全と判定できます。一致を確認してから、該当ファイルをマスターに上書きコピーします。エクスプローラで直接コピー&ペーストするか、FastCopyで該当フォルダだけ逆方向に同期します。

復元が終わったら、マスター側の該当ファイルのハッシュを再計算し、基準CSVと一致することを確認します。一致すれば復旧完了です。その後、通常のバックアップ運用を再開します。

なお、理想的には基準ハッシュはリッピング直後の状態で記録しておくのが最良です。バックアップ開始時点でマスターが既に破損していると、その破損した状態を正しい値として基準CSVに記録してしまいます。FLACの内蔵MD5はこの問題を自動的に回避していると言えます。

音源バックアップの実運用

ここまで説明してきた考え方を、実際にどう組み合わせて運用しているかを紹介します。完全な正解ではありませんが、3コピー体制の具体例として参考にしていただければと思います。

3コピー体制の実例

私の場合、音源は次の3箇所に保持しています。

ひとつ目のマスターはリッピング作業用PCに接続した内蔵HDDで、約10TBの音源を格納しています。新しく取り込んだ音源は、まずここに入ります。

ふたつ目がRoonサーバー用のSynology NAS(DS720+)で、SSD 8TB×2のRAID0構成です。マスターからFastCopyのベリファイ機能で差分転送しており、実際の再生はここから行っています。

みっつ目が外付けHDDで、こちらもFastCopyで定期的に差分バックアップを取っています。こちらは普段は電源を切って保管しており、ランサムウェア対策としてのオフラインバックアップも兼ねています。

CDを数千枚FLACでリッピングする一般的な環境であれば、2〜4TB程度の容量で十分収まります。市場に出回っているオーディオ用NASの容量帯もそのあたりが中心です。規模は違っても、3コピー体制の考え方は共通して有効です。

NASにBtrfsを使う意味

私のRoonサーバーはBtrfsで運用しています。前述のスクラビングによる破損検知が定期的に自動で走るため、PowerShellでの検証と合わせて二重のチェック体制になります。

ただしBtrfsの自動修復機能が働くのはSHR-2やRAID1などの冗長構成のみです。RAID0では検知はできても修復はできず、別のバックアップから手動で復元する必要があります。それでも、ext4のような従来のファイルシステムでは破損を気づけないまま再生時のノイズで発覚することになるため、検知できるだけでも大きな意味があります。Synology NASのセットアップと最適化については、別記事で詳しく扱っています。

所有規模別の現実的な落としどころ

チェックサム運用をどこまでやるかは、音源の規模と再リッピングの手間で決めるのが現実的です。数百GB程度ならFastCopyのベリファイ+2コピー体制で十分ですが、数TB規模になると再リッピングは現実的でなくなり、3コピー体制とハッシュ検証の組み合わせが必須になります。唯一無二の音源を抱えている場合は、物理的に離れた場所にもう1コピー置くことも検討する価値があります。

まとめ

音楽ファイルの長期保管で押さえるべきポイントを、最後に整理します。

• サイレントデータ破損は稀だが実在する。CERNやNetAppの大規模調査でも検出されている
• チェックサムは「最初に記録した基準値との比較」でしか破損を判定できない。基準はリッピング直後に取るのが理想
• FastCopyは「差分(最新日付)」モードが推奨。ベリファイONでコピー時のビット一致を担保
• PowerShellのGet-FileHashでFLAC・WAV・DSFを一元管理。foobar2000はFLAC限定の簡易手段、Synology NASはBtrfsスクラビングで補強
• エラー検知時は慌てず、基準CSV照合か3コピー多数決で健全なコピーを特定してから復元
• 3コピー体制が最低ライン。唯一無二の音源があればオフサイト保管も検討

リッピングに費やした時間は、二度と取り戻せません。チェックサムとバックアップは、その時間を守るための保険です。