我需要创建一个 mp3 文件的独立于元数据的散列(即，可以在重新标记后计算相同的散列)。我如何才能将音频数据仅提取到内存中，而不实际通过解压缩器运行它？
MAD 似乎是一个很好的起点 - http://www.underbit.com/products/mad/但似乎并没有明显公开这样做的功能。
感谢任何指点!
最佳答案
How can I extract the audio data only out into memory, without actually running it through a decompressor?
您无法在不解压缩的情况下提取音频数据 - 它是压缩的!但是，如果您只想要原始压缩流，请继续阅读!
典型的 mp3 音频文件将分为几个部分:
[可能的元标记]
[可能是垃圾]
[可能的 XING/LAME 标签 [可能更多垃圾]]
[mp3 音频帧]
[可能的元标记]
可能的元标签: 大多数 mp3 音频文件都有一个 id3标记在他们的头上。请注意，某些用户可能会使用不同的标记格式标记他们的 mp3 文件，例如 APE ，所以你也需要考虑到这一点。
可能是垃圾:某些 mp3 音频文件已被多次标记、重新标记和转换，元标记 header 可能无法为您提供第一个音频帧的准确偏移量，因为先前标记的残余可以留下。 foobar2000有一个选项来解决这个问题。
可能的 XING/LAME 标签:这些标签包含在 mp3 音频帧中，尽管它们不包含实际音频。 madplay有代码向您展示如何读取和解析这些帧。 XING/LAME header 可能有帧数，因此值得解析这些 header 。同样，如果文件已通过许多不同的标记器和编辑器，则可能会在此处找到多个格式错误、无效的音频帧。
MP3 音频帧:实际的压缩流，分为“帧”。每个帧都将以同步位模式 0xFFE 开始。
可能的元标记:在文件末尾找到更多元标记的情况并不少见。 id3v1、APE、歌词都可以在这里找到。
要找到音频帧偏移量，您需要解析任何元标记 header ，然后开始寻找同步位模式。您不能只是从文件的开头开始寻找同步模式，因为并非所有标记器都正确支持 unsynchronization , 因此元标记本身可能包含 0xFFE 模式。
获得第一个音频帧的偏移量后，您应该查看文件末尾并计算那里有多少非音频数据，以便您知道何时停止解析音频。一旦有了音频数据开头的偏移量和音频数据末尾的偏移量，就可以通过哈希/校验和函数传递音频数据!
关于c++ - 如何从 mp3 文件中提取音频数据？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/5005476/