質問

私は音楽ファイルからタグ情報を読み取るCライブラリに取り組んでいます。ID3v2 はすでに処理されていますが、Ogg ファイルがどのように構成されているかがわかりません。

ヘキエディタで .ogg ファイルを開くと、すべて人間が判読できるタグ データを見つけることができました。しかし、ファイルの先頭からタグデータまですべてがゴミのように見えました。このデータはどのようにエンコードされているのでしょうか?

実際のコードには何の助けも必要ありません。Ogg ヘッダーがどのようなもので、どのようなエンコーディングが使用されているかを視覚化して、それを読めるようにするだけの助けが必要です。Ogg ファイルを読み取るためにハッキングされていないアプローチを使用したいと考えています。

私はずっと見てきました Flac形式, 、役に立ちました。

私が見ている Flac ファイルには、「fLac」識別子と人間が読めるコメント セクションの間に約 350 バイトがあり、私の 16 進エディタでは人間が読めるものはありません。 何か そこにある重要なもの。

私は Linux を使用していますが、Windows や OS X に移植するつもりはありません。したがって、エンコーディングを変換するために glibc のみの関数を使用する必要がある場合は、それで問題ありません。

役に立ちましたか?

解決

提供したリンクで説明されているように、「fLaC」マーカーと VORBIS_COMMENT メタデータ ブロックの間に次のメタデータ ブロックが発生する可能性があります。

  • ストリーミングフォ:このブロックには、サンプル レート、チャンネル数、サンプルの合計数など、ストリーム全体に関する情報が含まれています。これはストリーム内の最初のメタデータ ブロックとして存在する必要があります。他のメタデータ ブロックが続く場合もありますが、デコーダが理解できないものはスキップされます。
  • 応用:このブロックはサードパーティのアプリケーションで使用するためのものです。唯一の必須フィールドは 32 ビット識別子です。この ID は、FLAC メンテナーによるアプリケーションへの要求に応じて付与されます。ブロックの残りの部分は、登録されたアプリケーションによって定義されます。FLAC にアプリケーションの ID を登録したい場合は、登録ページにアクセスしてください。
  • パディング:このブロックでは、任意の量のパディングが可能です。PADDING ブロックの内容には意味がありません。このブロックは、メタデータがエンコード後に編集されることがわかっている場合に役立ちます。ユーザーはエンコーダに十分なサイズの PADDING ブロックを予約するように指示できます。これにより、メタデータが追加されたときに、既存のファイルの適切な場所にパディングを挿入する代わりに、パディングを単純に上書きします (これは比較的高速です)。通常はファイル全体を書き直す必要があります)。
  • シークテーブル:これはシーク ポイントを保存するためのオプションのブロックです。シーク テーブルを使用せずに FLAC ストリーム内の任意のサンプルをシークすることは可能ですが、ストリーム内でビットレートが大きく異なる可能性があるため、遅延が予測できない可能性があります。ストリームにシーク ポイントを追加すると、この遅延を大幅に短縮できます。各シーク ポイントには 18 バイトがかかるため、ストリーム内の 1% の解像度の追加は 2k 未満です。ストリーム内に存在できる SEEKTABLE は 1 つだけですが、テーブルには任意の数のシーク ポイントを含めることができます。デコーダによって無視される特別な「プレースホルダー」シークポイントもありますが、これは将来のシーク ポイント挿入用のスペースを予約するために使用できます。

上記の説明の直後に、これらの各ブロックのフォーマットの指定もあります。リンクにはこうも書かれています

FLAC ビットストリームで使用される数値はすべて整数です。浮動小数点表現はありません。すべての数値はビッグエンディアンでコード化されています。特に指定がない限り、すべての数値は符号なしです。

では、何が足りないのでしょうか?あなたは言う

Ogg ファイルを読み取るためのハッキングされていないアプローチが必要です。

ライブラリがすでに存在しているのに、なぜそれを行うためにライブラリを書き直すのでしょうか?

ライセンス: CC-BY-SA帰属
所属していません StackOverflow
scroll top