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.

  • 1
    It might help if you identified / described your development environment (i.e., what compiler you are using).  Please do not respond in comments; edit your question to make it clearer and more complete. – Scott Jun 6 '17 at 20:06
  • I think windows itself adds some handlers. If you can add a column like bitrate to an explorer window in detail view by right clicking in the header there has to be a handler present. – LotPings Jun 6 '17 at 22:33
  • Can certainly add bitrate to the view, doesn't get populated mind. I take it though all this is telling me then is that there is a handler somewhere which can generate this information but it doesn't necessarily mean it's for audio content. – fridgemagnet Jun 7 '17 at 19:11
  • In the case of shares, seeking to the end of file may result in a full transfer, might it not? In other words: "does samba support fseek"? – Yorik Jun 7 '17 at 19:52
  • Note that I mentioned "The problem also crops up if the file is located on another Windows box (so it's not some Samba quirk here)". Also for files that don't exhibit this problem, you still see a read of the start & end of file occurring in the trace. – fridgemagnet Jun 9 '17 at 18:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.