我正在开发一个从音乐文件中读取标签信息的C库。我已经得到了ID3v2，但我无法弄清楚Ogg文件的结构。
我在hexeditor中打开了一个.ogg文件，我可以找到标签数据，因为这是人类可读的。但是从文件开头到标签数据的所有内容都像垃圾一样。这些数据是如何编码的？
我在实际代码中不需要任何帮助，我只需要帮助可视化Ogg标题的样子以及它使用的编码，以便我可以阅读它。我想使用非hacky方法来阅读Ogg文件。
我一直在关注Flac format，这很有帮助。
我正在查看的Flac文件在“fLac”标识符和人类可读的Comments部分之间有大约350个字节，并且在我的十六进制编辑器中没有一个是人类可读的，所以我确定必须有<那里有重要的东西。
我正在使用Linux，我无意移植到Windows或OS X.所以如果我需要使用glibc only函数来转换编码，我就可以了。
答案 0 :(得分：5)
答案 1 :(得分：4)
如您提供的链接中所述，“fLaC”标记和VORBIS_COMMENT元数据块之间可能会出现以下元数据块。
- STREAMINFO：此块包含有关整个流的信息，如采样率，通道数，样本总数等。它必须作为流中的第一个元数据块出现。其他元数据块可能会跟随，而解码器不理解的那些，它将跳过。
- APPLICATION：此块供第三方应用程序使用。唯一的必填字段是32位标识符。 FLAC维护人员根据请求向该应用程序授予此ID。块的其余部分由注册的应用程序定义。如果您想通过FLAC注册申请ID，请访问注册页面。
- PADDING：此块允许任意数量的填充。 PADDING块的内容没有意义。当已知编码后将编辑元数据时，此块很有用;用户可以指示编码器保留足够大小的PADDING块，以便在添加元数据时，它只会覆盖填充（相对较快），而不必将其插入现有文件中的正确位置（这将通常需要重写整个文件。）
- SEEKTABLE：这是一个用于存储搜索点的可选块。可以在没有搜索表的FLAC流中寻找任何给定样本，但是延迟可能是不可预测的，因为比特率可能在流内变化很大。通过向流添加搜索点，可以显着减少此延迟。每个搜索点占用18个字节，因此流中1％的分辨率增加不到2k。流中只能有一个SEEKTABLE，但该表可以有任意数量的搜索点。还有一个特殊的“占位符”搜索点，它将被解码器忽略，但可用于为将来的搜索点插入预留空间。
在上面的描述之后，还有每个块的格式规范。该链接还说
FLAC比特流中使用的所有数字都是整数;没有浮点表示。所有数字都是大端编码。除非另有说明，否则所有数字均未签名。
那么，你错过了什么？你说
我想要一种非hacky方法来阅读Ogg文件。
为什么要重写一个库来存在它们呢？