我最近在亚马逊购买了 Windows 7（32 位）的 MP3 文件，在播放这些文件时，我发现了一些奇怪的行为。这些文件存储在网络（Samba）共享中，实际上，播放时似乎有明显的延迟。我假设，因为我一直在使用自己的软件，所以这很可能是我做的某件事；然而，延迟出现在实际fopen调用中（进一步说，GetOpenFileName 对话框中也会出现这种情况，在选择文件后，在关闭对话框并将控制权返回给代码之前，会出现明显的停顿）。后一种行为表明编译器/工具链在这里无关紧要，因为这是一个本机 Win32 调用。
快速 Wireshark 跟踪显示，打开（或 GetOpenFileName）调用触发了对整个文件的读取。如果文件位于另一个 Windows 机器上，也会出现此问题（因此这不是 Samba 的怪癖）。这似乎与附加到文件的元数据有关；如果我将其剥离，文件几乎会立即打开。有趣的是，对于没有出现此问题的文件，Wireshark 显示即使如此，Windows 也会读取文件开头的 ~64K，然后读取结尾的 ~32K。鉴于您可以在文件的开头和结尾处都有 ID3 标签，这看起来像是 Windows 正在为其自身目的预读标签，并且由于某种原因，这些特定文件上的标签导致它扫描整个文件。
到目前为止，我在谷歌上搜索到的最终结果是属性处理程序，特别是此链接有很多关于此事的有用信息。但有一个小问题——我没有为 .mp3 或任何其他音频内容定义任何属性处理程序，因此我有点不知如何解释这种行为。
我曾想过这可能是一个 ID3v4 标签，因为我似乎记得这些标签（理论上）可能分散在整个文件中，这可以解释为什么 Windows 会读取整个文件。但事实并非如此，这是 ID2v3。
答案1
终于花了一些时间将文件拆开后，问题似乎与亚马逊在其音频中包含的自定义 ID3 PRIV 框架有关。这由一小部分 XML 组成，删除它，问题就解决了。不过，问题并不是那么明显，通常这个框架位于文件开头附近，但是如果你使用类似Mp3标签为了重写标签数据，它重新安排了所有内容，将 PRIV 框架从标签的开头（Amazon 定位它的位置）移动到结尾。之后，问题也不会发生。
我的猜测是，Windows（无论出于什么原因）在打开文件时会预先解析文件的初始部分以获取某些内容，并且在这种情况下认为该文件是 XML。此时，它会读入所有内容，可能是为了在以后提高解析性能？谁知道呢？通过移动数据，因此在开始时显然有一块二进制文件，它不会触发此逻辑，因此不会显示延迟。