問題タブ [id3v2]

MP3 から jpg を読み込もうとしています (これは Flash で行っていますが、ここでもそこでもありません)。16 進エディターでいくつかの MP3 を開き、タグの残りの部分を読み込んでいます。かなりはっきりしていますが、画像部分は謎です。「image/jpeg」というラベルがありますが、画像のバイト長または画像の終わりを区切る文字列キーに似たものを期待していますが、そのようなものは何も表示されず、タグのドキュメントはまったく役に立ちません.

私がここで探しているものについてのガイダンスが欲しいです。これがどれほど非直感的であるかに驚いています!

ティア

サーバー上のmp3ファイルをチェックして結果を取得するためのコードを作成していますが、それらの一部に誤った同期があるかどうかがわかります。要するに、私はfread（）関数を使用してPHPでこれらのファイルをロードし、変数でストリームを取得しています。そのストリームを分割して、id3v1（不要、同期の対象ではありません）、id3v2（主な問題）、およびオーディオの個別のストリームを取得した後、id3v2ストリームに対してそのスキームを実装する必要があります。

ID3v2の公式ドキュメントによると：

「非同期スキーム」の唯一の目的は、ID3v2タグを既存のソフトウェアと可能な限り互換性のあるものにすることです。ファイルが新しいソフトウェアによってのみ処理される場合は、「非同期」タグは使用できません。非同期化は、MPEG 2レイヤーI、II、IIIおよびMPEG2.5ファイルでのみ行うことができます。

タグ内で誤った同期が検出されると、最初の誤った同期バイトの後に1つのゼロ化されたバイトが挿入されます。ID3エンコーダーによって変更される必要がある正しい同期の形式は次のとおりです。

％11111111 111xxxxx

そして、次のように置き換える必要があります。

％11111111 00000000 111xxxxx

これには、すべての$ FF 00の組み合わせを変更する必要があるという副作用があるため、デコードプロセスの影響を受けません。したがって、非同期化中に、すべての$FF00の組み合わせを$FF0000の組み合わせに置き換える必要があります。

非同期の使用法を示すには、「ID3フラグ」の最初のビットを設定する必要があります（注：そのビットを見つけました）。このビットは、タグに修正された誤った同期が含まれている場合にのみ設定する必要があります。タグに誤った同期が含まれていない場合にのみ、ビットをクリアする必要があります。

エンコーダで圧縮方式を使用する場合は、後で非同期方式を適用する必要があることに注意してください。圧縮された「非同期」ファイルをデコードするときは、「非同期スキーム」を最初に解析し、後で解凍する必要があります。

私の質問は次のとおりです。

1. このビットパターンを検索して置き換える方法%11111111 111xxxxxは%11111111 00000000 111xxxxx？
2. 逆に、このビットパターンを検索して置き換える方法%11111111 00000000 111xxxxxは%11111111 111xxxxx？

... preg_replace（）を使用します。

これまでに作成したコードは完全に機能し、あと1行しかありません（正確には2行です）。

preg_replace（）関数を使用してこれらの2行を機能させる方法は？

PS私はある種のループでバイトごとにそれを読み取る方法を知っていますが、これは正規表現を使用して可能であると確信しています（ところで、正直なところ、私は正規表現を吸います）。

詳細が必要な場合はお知らせください。

もう一つ...

現在、このパターンを使用しています

最初のゼロバイトから最後まで文字列の一部を切り取ります。これを行うための正しい方法ですか？

アップデート

（@マリオの答え）。

最初の数回のテストで...このコードは正しい結果を返しました。

しかし、数分後、すべてが期待どおりの結果のように見えても、ストリームにFFE0+ペアが残っている特定のケースを見つけました。

ストリームに次のようなFF FF FF FFものが含まれている場合は、に置き換えられますFF 00 FF FF 00 FFが、である必要がありますFF 00 FF 00 FF 00 FF。そのFF FFペアは再びmp3同期を誤ってしまうので、私の使命はFFE0+オーディオストリームの前にすべてのパターンを回避することです（ID3v2タグストリームで。mp3はFFE0+バイトペアで始まり、オーディオデータの最初に最初に出現する必要があるため）。FFE0 +バイトペアなしでストリームを取得するまで、同じ正規表現をループできることがわかりました。ループを必要としない解決策はありますか？

素晴らしい仕事@マリオ、どうもありがとう！

mp3ファイルのID3V2のヘッダーを読み込もうとしています。ID3を取得/印刷でき、char型である「version」と「subversion」を印刷したいのですが、必要なものが取得できません。

ここにコードがあります：

A。

そこで、ID3 タグに格納された MP3 情報を収集するためのプログラムを書いています。（ID3v1は些細なことでした、これは面倒です！）

私が使用している一般的なプロセスは、FrameID (4 バイト)、次に長さ (4 バイト)、そしてデータ (長さバイト) を読み取ることです。

長さを読み取るとき、これは Syncsafe 整数であるため、基本的に各バイトの最上位ビットは 0 である必要があります。これは小さなデータ フレームでは問題ないように見えますが、データ フレームが長くなると、長さが 1 バイトに達することがあります。 ID3 仕様の慣例により、このビットを無視することになっていますが、そうするとアルゴリズムがめちゃくちゃになり、部分的なタグしか取得できなくなります。

特にタグの frhed ダンプ:

この時点で、長さは$00 00 00 c6であり、BigEndian int としては198であり、技術的にはここのタグの長さです。ただし、バイナリのc6は11000110です。同期セーフ アルゴリズムがその最初のビットを削除すると、カウントが70になりますが、これは正しくありません。フレームの長さでこれを行うために、Winamp 2.95 と iTunes 10 を入手しました。理解できません。これらのフレームを読み取っている間、整数を同期セーフにするか、そのままにしておくために探す必要がある条件はありますか?

ソースコード：

この例を実行した後の i と j の値は、それぞれ 198 と 70 です。

完全なヘッダーは次のとおりです (frhed ダンプ、MP3 ヘッダーの先頭に少し入っています)。

id3 フレームを読み取ろうとしていますが、完全なタイトルを取得できないという問題があります。mp3 のタイトルが長い場合、結果は末尾がなく、最初の 9 文字がない文字列になります。曲のタイトルが短い場合、結果は最初の 9 文字のないタイトルになります。

jid3lib を使用してアプリケーションを作成しようとしていますが、id3v1 の読み取り/書き込みに関してほとんどすべてが機能していますが、v2 ユニコードの場合、ユニコードを使用可能な文字列に変換してから再エンコードするための最善の方法がわかりません。フレームに書き戻します。

CharsetDecoder と CharsetEncoder を見つけましたが、何も変わっていないようです。

convertCharset は次のとおりです。

出力は次のようになります: http://i.stack.imgur.com/RLbKe.png

助けてくれてありがとう。

音楽プレーヤーのメタデータ修正機能が欲しいのですが、私が知っているように、そのようなことができるライブラリはありません。ただし、一部の C# アプリケーションでこれを実現できることがわかりました。

例

このプロジェクトを開始するには、いくつかのアドバイスと、おそらく適切な情報源が必要です。どんな助けでも大歓迎です。

ありがとう。

編集:これも見つけました。これは私がやりたいことと非常に似ていますが、ソースはほとんどありません。 http://wmpoweruser.com/finally-mp3-tag-editor-for-windows-mobile-available/

getid3 を使用して mp3 のアルバム カバーを取得する次のコードがありますが、問題は、この画像をコピーして指定したディレクトリに配置する方法です。

これは可能ですか？助けてくれてありがとう:)

だから、私の最終的なゲームは、オーディオ ファイルからアルバム アートを取得しています。私はtaglibとc ++を使用しています。埋め込まれた画像データを抽出する方法に関する情報を見つけましたが、Windows Media Player は画像自体を埋め込んでいないようです。代わりに、AlbumArt_{E3208100-4FAA-4030-BB9D-6DA5F9D93D18}_Large.jpg のような名前の jpg を保存します。明らかに、GUID を使用しています。これは、PRIV タグに保存されていると思います。皆さんへの私の質問は、どうすればそこにたどり着けますか? 私はこのようなものがうまくいくかもしれないと思った:

しかし、データには何の役にも立たないようです。何か案は？

私は最近 ID3v2.4.0 に取り組んでいます。2.4.0 ドキュメントを読んで、理解できない特定の部分を見つけました - 同期セーフ整数。ID3v2 がこの方法を使用するのはなぜですか?

もちろん、ID3v2 が非同期方式を使用する理由はわかっています。これは、MPEG デコーダーが ID3 タグを MPEG 同期データと見なさないようにするために使用されます。しかし、私が理解できなかったのは、非同期化スキームの代わりに同期セーフ整数を使用する理由 (= $00 の挿入) です。

$00 を挿入する代わりに、タグのサイズを表現するときに同期セーフ整数を採用する理由はありますか? これらの 2 つの方法では、まったく同じ結果が得られます。 

ID3v2 ドキュメントによると、同期されていないデータのサイズは事前にわかりません。しかし、その声明は意味がありません。タグデータがバッファに格納されている場合、問題のある文字を $FF 00 に置き換えるだけで、非同期データのサイズを知ることができます。

私を助けてくれる人はいますか？