mp3ファイルのmd5ハッシュのカウント

そのため、MP3ファイルのハッシュ量を計算する必要があります。 md5.exeを使用したファイルの単純な実行は、ファイルにメタ情報（時間とともに変化する傾向のあるタグ）が含まれているため、適切ではありません。 したがって、ファイル内のタグを更新するだけで、異なるハッシュ量が得られますが、これはまったく良くありません。

ちなみに、FLACおよびAPE形式の場合、通常、エンコーダーによって規定されたオーディオデータのハッシュ和が最初に含まれるため、この問題は実質的にありません。 FLACの場合、値はmetaflac --show-md5sumコマンドで取得できます。

次は、MP3に格納されたバイナリデータに基づいて（知覚的でない）ハッシュを計算するかなり信頼できる方法です。

1）アプローチ1
2）アプローチ2
3）XingおよびLameタグ
4）再同期
5）信頼性のカウント

アプローチ番号1。 不要なものを取り除く

アイデアは、ファイル（タグ）から不要なものをすべて削除すると、必要な情報（オーディオデータ）のみが残り、そこからハッシュを計算できるということです。

Mp3ファイル構造：
-タグID3v2
-mpegフレーム-実際のオーディオデータ
-歌詞タグ
-APEタグ
-タグID3v1（最終）

（すべてのタグはオプションです。）

ID3v2は、以前のバージョンとは異なり、ファイルの先頭にあります。これにより、たとえば、ファイルがネットワーク経由で送信された場合、クライアントはすぐにメタ情報を読み取ることができます。 3つのASCII文字「ID3」で始まり、エンコードされたタグの長さが続きます。

 if buf[0:3] == 'ID3':   id3_v2_len = 20 if ord(buf[5]) & 0x10 else 10   id3_v2_len += ((ord(buf[6]) * 128 + ord(buf[7])) * 128 + ord(buf[8])) * 128 + ord(buf[9])   audio_start = id3_v2_len 

次はオーディオフレームです。 1251エンコーディングでファイルを開き、文字「yy」を見つけると、それらの始まりを視覚的に確認できます。

最後から行きましょう。 ID3v1は、ASCII文字列「TAG」で始まる、ファイルの最後の128バイトブロックとして認識されます。 その後、末尾から「LYRICSBEGIN」を検索すると、Lyrics3タグが見つかります。 そして、「APETAGEX」がAPEv2タグの場合。

これをすべてカットすると、オーディオデータのみが残ります。 このアプローチの後には、mp3tag.deプログラムが続きます。これは、プライベートスクリプトとタグ付けライブラリの集まりであり、そのほとんどがID3のみに焦点を当てていますが、これはもちろん邪魔です。

しかし、悪いことは、タグが壊れたり、互いの上に書き込まれたりする可能性があることです。 このアプローチでは、ガベージヒープはオーディオデータとして取得されます。これにより、1つのハッシュ量が計算され、タグを別のハッシュ量に変更した後、許可されません。

その結果、このような方法で書かれたプログラムは、現実との衝突後に捨てなければなりませんでした。

アプローチ番号2。 右を離れる

MP3プレーヤーは逆に動作します-興味のあるものを分離します-フレームのように見えないものをすべてスキップし、非常に成功します-通常、「悪い」ファイルで「sobs」は聞こえません。 同じことをするのは賢明です。

foob​​ar2000プレーヤーがこれを行うように見えますが、これは私の推測では完全に機能しますが、この場合は廃棄することは理解できます。

MPlayerも同じことを行う必要がありますが、実際には誤ったタグでつまずき、それらを残してしまうため、疑問が生じます。 彼のファイルを消去するコマンドは、 mplayer in.mp3 -dumpaudio -dumpfile out.mp3です。

メディアライブラリもあります-mp3デコーダー。 これらはmad、gstreamer、libmpg123であり、異なるテスターに​​よって非選択的に使用されます。 最初の2つは試していませんが、libmpg123は大成功で終了しました。このコードは長年にわたって多くのプロジェクトでテストされており、私自身の研究と比較の結果によると高品質です。 doc/examplesには、 extract_frames.cという名前のマイクロプログラムのソースコードがあります。 プログラムは元のmp3ファイルを入力として受け入れ、クリーンなオーディオフレームを出力に送信します。

libmpg123はcygwinとmingwで問題なくコンパイルできます（mingwバージョンはstdin / stdoutで何らかのバグがありますので、バイナリモードでファイルを開いてソースを修正する必要がありました）。 プログラムを少し変更して、フレームの代わりにすぐにmd5を出力し、以下で説明するいくつかの変更を行いました。 興味のある人のためのソースコード：

dl.dropbox.com/u/1883230/my/habr/mp3hash.zip

XingおよびLameタグ

しかし、削除したいメタ情報はオーディオフレームに保存することもできます-これらはxingタグとlameタグで、vbr-streamに沿った動きを最適化するために使用される追加情報と、エンコードに使用されるパラメーターがエンコードされます。 一般に、少数の人ができるようにximをleimから残すことができ、変更しますが、foobar2000で突然「utilities / fix vbr mp3 header」操作を実行すると、ファイルのハッシュ量が変更されます。 したがって、このメタをスローする方が良いでしょう。 次のパラメーターをlibmpg123に渡すことで、ハッシュ時にこれらのタグの考慮を停止できます。

 // "remove ignore"  ,    ret = mpg123_param(m, MPG123_REMOVE_FLAGS, MPG123_IGNORE_INFOFRAME, 0.); 

再同期

再同期の制限を削除することも役立ちました。 これが行われないと、プログラムは長時間（4KB）オーディオフレームを満たさないときに「つまずき」ます。これは、たとえばID3v2に大きな画像が含まれるファイルで発生します。 私のプログラムのバージョンでは、ハッシュの合計は同じように計算されますが、表示されるエラーフラグはすべてを台無しにしているため、エラーなしで結果が得られたことを確認できなくなりました。 そして、このパラメーターで、すべてがうまくいきます：

 mpg123_param(m, MPG123_RESYNC_LIMIT, -1, 0.0); 

信頼性を数える

私の限られた見方では、foobar2000は完全に機能します（メタ情報を取り除きます）。 パッチを当てたextract_frames.cプログラムextract_frames.cまれなファイルを処理extract_frames.cんが、fubarでの「ストリームの再構築」操作の後、100件中95件が正しくカウントされます（fubarと互換性があります）。 さらに、mplayerは少し悪くなります-ほとんどの場合、 extract_frames互換性があります（もちろんアカウンティングモードのlame / xingで）が、既に書いたように、ゴミタグに該当することもあります。 さらに、かなり正しいタグを必要とするさまざまなタガーがあり、より安定した代替手段が利用可能な場合、ハッシュの問題はほとんど適用されません。

一般に、1つの大きな失敗といくつかの側面との戦いの後、私は個人的にこのアルゴリズムに満足し、多数のファイルでチェックしました。