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.