I cannot reproduce this on any version or platform including 7.4.3 ubuntu as specified above, I don't have OSX available to test.

As a rule the total size of the file should have no impact here as these functions do not generally do anything other than looking at a small number of bytes from the start of the file - are you certain that the >50MB file(s) you have tested are correctly encoded? Can you verify whether anything else that wraps libmagic is able to correctly identify them? I'm wondering if this is an upstream problem, or possibly a broken magic.mime definition file.

If you are able to provide a sample MP3 file that causes the problem I will investigate further, though I realise this may not be possible.

Side note to anyone who happens to be passing with admin access to bugsnet, the fileinfo extension seems to be missing from the package list (or possibly I am just blind)

I'm pretty sure the MP3 is in order, although I don't know how to guarantee that. The file in question is a podcast episode that I encoded with Marco Arment's Forecast application on the Mac (https://overcast.fm/forecast). The file in question can be downloaded at https://iapodcast.net - it's "Episode 1: Taste the Rainbow". (Episode 0 was created with the same tools, but its type is correctly identified as 'audio/mpeg'). Both files play well in the players I've tried and the magic number at the head of the files is the same for both (49 44 33).


On both the Ubuntu and MacOS systems, the 'file' command is returning the same results that I was seeing in PHP:

  $ file --mime-type *.mp3
  2020-02-13-ia-000.mp3: audio/mpeg
  2020-02-28-ia-001.mp3: application/octet-stream

Strangely, the 'exiftool' command line utility returns 'audio/mpeg' as the MIME type for both MP3s, although I don't know how the application is determining that (maybe it's just based on file extension?).

It sounds like this may at least be an upstream issue, given that I can replicate the problem outside of PHP. But the cross-platform nature of this issue makes me think that Forecast may be doing something funny to the encode that I'm not picking up on, so I will follow-up on that as well.

And thanks for the quick reply - definitely wasn't expecting that!

If `file` doesn't recognize it then it's no surprise PHP does not either.

The MP3 may be wrapped in a container; ffmpeg should be able to give you more precise information about the file.