3

我正在开发一个从音乐文件中读取标签信息的 C 库。我已经处理了 ID3v2，但我无法弄清楚 Ogg 文件的结构。

我在 hexeditor 中打开了一个 .ogg 文件，我可以找到标签数据，因为这都是人类可读的。但是从文件开头到标签数据的所有内容看起来都像垃圾。这些数据是如何编码的？

我在实际代码中不需要任何帮助，我只需要帮助可视化 Ogg 标头的外观以及它使用的编码，以便我可以阅读它。我想使用一种非 hacky 的方法来读取 Ogg 文件。

我一直在看Flac 格式，这很有帮助。

我正在查看的 Flac 文件在“fLac”标识符和人类可读的注释部分之间有大约 350 个字节，并且在我的十六进制编辑器中没有一个是人类可读的，所以我确信那里一定有一些重要的东西.

我使用的是 Linux，我无意移植到 Windows 或 OS X。所以如果我需要使用仅 glibc 的函数来转换编码，我可以接受。

4

2 回答 2

5

此处记录了Ogg 文件格式。根据您的要求，有一个非常漂亮的图形可视化，并附有详细的书面描述。

您可能还想查看libogg，它是一个开源 BSD 许可库，用于读取和写入 Ogg 文件。

于 2009-12-08T17:07:17.047 回答
4

如您提供的链接中所述，以下元数据块可能出现在“fLaC”标记和 VORBIS_COMMENT 元数据块之间。

  • STREAMINFO：此块包含有关整个流的信息，例如采样率、通道数、采样总数等。它必须作为流中的第一个元数据块存在。其他元数据块可能会跟随，而解码器不理解的会跳过。
  • 应用程序：此块供第三方应用程序使用。唯一的必填字段是 32 位标识符。此 ID 是根据 FLAC 维护者向应用程序的请求授予的。块的其余部分由注册的应用程序定义。如果您想通过 FLAC 为您的应用程序注册一个 ID，请访问注册页面。
  • 填充：此块允许任意数量的填充。PADDING 块的内容没有意义。当已知元数据将在编码后进行编辑时，此块很有用；用户可以指示编码器保留足够大小的 PADDING 块，以便在添加元数据时，它会简单地覆盖填充（相对较快），而不必将其插入现有文件中的正确位置（这将通常需要重写整个文件）。
  • SEEKTABLE：这是一个用于存储搜索点的可选块。可以在没有查找表的情况下查找 FLAC 流中的任何给定样本，但延迟可能无法预测，因为比特率在流中可能变化很大。通过向流中添加搜索点，可以显着减少这种延迟。每个查找点占用 18 个字节，因此流中 1% 的分辨率增加了不到 2k。一个流中只能有一个 SEEKTABLE，但该表可以有任意数量的查找点。还有一个特殊的“占位符”搜索点将被解码器忽略，但可用于为将来的搜索点插入保留空间。

在上面的描述之后，还有每个块的格式规范。该链接还说

FLAC 比特流中使用的所有数字都是整数；没有浮点表示。所有数字都是大端编码的。除非另有说明，否则所有数字均无符号。

那么，你错过了什么？你说

我想要一种非 hacky 的方法来读取 Ogg 文件。

当它们已经存在时，为什么要重新编写一个库来做到这一点？

于 2009-12-08T17:07:58.867 回答