Windows reading entire audio file on open

Question

I spotted some slightly odd behaviour whilst playing with some MP3 files under Windows 7 (32-bit) I recently purchased from Amazon. They are stored on a network (Samba) share and, in essence, there seemed to be a significant delay on starting playback of them. I'd assumed, since I'd been using my own software here, that it was more than likely something I was doing; however, the delay is cropping up on the actual fopen call (extending this further, this also happens with the GetOpenFileName dialog, there is a noticeable pause after the file is selected, before the dialog is closed & control is returned to the code). This latter behaviour suggests the compiler/toolchain is irrelevant here since this is a native Win32 call being made.

A quick Wireshark trace shows that the open (or GetOpenFileName) call is triggering the read of the entire file. The problem also crops up if the file is located on another Windows box (so it's not some Samba quirk here). It seems to be related to the metadata attached to the file; if I strip it off, the file opens almost instantaneously. Of interest is that on a file that doesn't exhibit this problem, Wireshark shows that even then Windows will read ~64K at the front of the file and then ~32K at the end. Given you can have ID3 tags at both the start and end of the file, this looks like Windows is pre-reading the tag for its own ends, and for some reason the tags on these particular files are causing it to scan the entire file.

My Googling thus far led me to end up looking at property handlers, and specifically this link had lots of useful info on the matter. One small problem – I don't have any property handlers defined for .mp3, or any other audio content, for that matter, so am at a bit of a loss to explain this behaviour.

I had a thought that possibly this was an ID3v4 tag since I seem to recall that these could (in theory) be scattered throughout the file which would explain the thinking as to why Windows would read the entire file. It's not, it's ID2v3.

Answer 1

Having finally spent some time pulling the file apart, the problem seems to be related to a custom ID3 PRIV frame that Amazon include in their audio. This consists of a small portion of XML, strip that and the problem goes away. It's not definitively that clear cut though, normally this frame is near the beginning of the file however if you use something like Mp3tag to rewrite the tag data, it re-arranges everything, moving the PRIV frame from the start of the tag (where Amazon locate it) to the end. After which, the problem also doesn't occur.

My guess is that Windows (for whatever reason) is pre-parsing the initial part of the file for certain content when opened and in this case thinks the file is XML. At which point, it then reads everything in, possibly to improve parsing performance at a latter date? Who knows? By moving the data, so there is clearly a slab of binary at the start, it doesn't trip this logic and hence doesn't show the delay.