php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #79325 MIME type of MP3s over 50MB is incorrect
Submitted: 2020-02-29 18:48 UTC Modified: 2020-03-02 04:33 UTC
From: michael at beorn dot me Assigned:
Status: Not a bug Package: Filesystem function related
PHP Version: 7.4.3 OS: macOS, Ubuntu
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: michael at beorn dot me
New email:
PHP Version: OS:

 

 [2020-02-29 18:48 UTC] michael at beorn dot me
Description:
------------
---
From manual page: https://php.net/function.mime-content-type
---

An MP3 file over 50,000,000 bytes (50 MB base-10) is reported to have a MIME type of “application/octet-stream” instead of the correct “audio/mpeg”:

Test script:
---------------
echo mime_content_type('test-over-50mb.mp3') . " > " . filesize('test-over-50mb.mp3');
application/octet-stream > 50030096

echo mime_content_type(‘test-under-50mb.mp3') . " > " . filesize(‘test-under-50mb.mp3');
audio/mpeg > 49730577

Expected result:
----------------
The expected result is that an MP3 audio file over 50MB is reported as having a MIME type of "audio/mpeg".

Actual result:
--------------
An MP3 file over 50,000,000 bytes (50 MB base-10) is reported to have a MIME type of “application/octet-stream”.

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2020-02-29 20:02 UTC] daverandom@php.net
-Status: Open +Status: Feedback -Type: Documentation Problem +Type: Bug
 [2020-02-29 20:02 UTC] daverandom@php.net
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.
 [2020-02-29 20:04 UTC] daverandom@php.net
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)
 [2020-03-02 03:30 UTC] michael at beorn dot me
-Status: Feedback +Status: Open
 [2020-03-02 03:30 UTC] michael at beorn dot me
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!
 [2020-03-02 04:33 UTC] requinix@php.net
-Status: Open +Status: Not a bug
 [2020-03-02 04:33 UTC] requinix@php.net
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.
 
PHP Copyright © 2001-2020 The PHP Group
All rights reserved.
Last updated: Fri Dec 04 01:01:23 2020 UTC