mp3 file with different file mime type and content type when uploading should not be rejected

[soleo]

<?php
$files = [
    'recording6021333337014136895.mp3',
    'SampleAudio_0.7mb.mp3',
    'to_test_on_timby_voice_note.m4a'
];
if (  extension_loaded( 'fileinfo' ) ) {
    foreach ($files as $file ) {
        $finfo     = finfo_open( FILEINFO_MIME_TYPE );
        $real_mime = finfo_file( $finfo, $file );
        finfo_close( $finfo );
        echo "$file $real_mime\r\n";
    }
}

Results:

recording6021333337014136895.mp3 video/mp4
SampleAudio_0.7mb.mp3 audio/mpeg
to_test_on_timby_voice_note.m4a application/octet-stream

All the files are valid, but recording6021333337014136895.mp3 and to_test_on_timby_voice_note.m4a because of the mime type.

​https://github.com/WordPress/WordPress/commit/3af00578e46efa3b59fb8ed9f4177d632a123a2e is the commit which introduces this issue

[soleo]

Recording from phone

[soleo]

Another recording

[soleo]

Regular test sample audio

[subrataemfluence]

Welcome to trac and thanks for the report!

recording6021333337014136895.mp3 video/mp4
to_test_on_timby_voice_note.m4a application/octet-stream

The issue with the above files should ideally be fixed by adding right associations in wp_get_mime_types function inside wp_includes/functions.php file.

'mp3'   => 'video/mp4',
'm4a'   => 'application/octet-stream',

The issue with recording6021333337014136895.mp3 video/mp4 has actually resolved by the above approach but the m4a one is not responding to it!

I downloaded few sample m4a sample files and they uploaded correctly since the mime-types of those are all audio/x-m4a, and this is the value returned by get_real_type function.

Although adding a correct association should work ('m4a' => 'application/octet-stream') and the mime-type of your file is indeed application/octet-stream I am not sure why it is being rejected! However, none of the m4a files I downloaded is of application/octet-stream.

Can you send another m4a of application/octet-stream type file for further testing please?

[soleo]

Another example for m4a audio file

[soleo]

Thanks for taking care of it.

I just attached another m4a file (xj.m4a). It was recorded using Vocienote app built in SAMSUNG S8.

Could you explain how you are going to fix it? The fix should work for the following types

• an mp3 file could have a set of mime types such as audio/mpeg, video/mp4
• similarly, an m4a file could have mime type audio/mpeg, audio/x-m4a or application/octet-stream

This is not a complete list of all variations of possible mime types, because every recording app handles it differently. Adding another set of mime type for mp3,m4a might solve this current bug, but it is very likely that there are other cases we may miss.

Is there a reason that we have to do mime type checking that strict?

Replying to subrataemfluence:

Welcome to trac and thanks for the report!

recording6021333337014136895.mp3 video/mp4
to_test_on_timby_voice_note.m4a application/octet-stream

The issue with the above files should ideally be fixed by adding right associations in wp_get_mime_types function inside wp_includes/functions.php file.

'mp3'   => 'video/mp4',
'm4a'   => 'application/octet-stream',

The issue with recording6021333337014136895.mp3 video/mp4 has actually resolved by the above approach but the m4a one is not responding to it!

I downloaded few sample m4a sample files and they uploaded correctly since the mime-types of those are all audio/x-m4a, and this is the value returned by get_real_type function.

Although adding a correct association should work ('m4a' => 'application/octet-stream') and the mime-type of your file is indeed application/octet-stream I am not sure why it is being rejected! However, none of the m4a files I downloaded is of application/octet-stream.

Can you send another m4a of application/octet-stream type file for further testing please?

[ironprogrammer]

#57530 was marked as a duplicate.

[ironprogrammer]

Reproduction Report

I'm providing an updated test report to confirm this issue still exists.

Steps to Reproduce

1. In your test WordPress site, navigate to Media.
2. Attempt to upload an audio file that has a MIME type of video/mp4 (e.g. Monday%20at%202-57%20AM.m4a).
3. 🐞 The uploader responds with the error: "Sorry, you are not allowed to upload this file type."

Environment

• Hardware: MacBook Pro Apple M1 Pro
• OS: macOS 12.6.2
• Browser: Safari 16.2
• Server: nginx/1.23.3
• PHP: 7.4.33
• WordPress: 6.2-alpha-54642-src

Expected Results

• ✅ The uploader should allow audio files with a MIME type of video/mp4, which is common for Android.

Actual Results

• ❌ The uploader does not allow upload of an audio file with MIME type video/mp4 and responds with an error. This occurred for a sample .mp3 and .m4a file.

Additional Notes

When using macOS Safari, .m4a files may be converted to .mp3 when using Trac's attachment download link. However, this does not change the MIME type, so the resultant converted .mp3 file should still validate the error. To avoid ambiguity, when downloading contributor-supplied samples, I recommend using a different browser, or curl -O <url-to-file> instead.

The sample audio file's MIME type was verified using (includes Safari's .mp3 conversion):

$ file -I Monday\ at\ 2-57\ AM* 
Monday at 2-57 AM.m4a:     video/mp4; charset=binary
Monday at 2-57 AM.m4a.mp3: video/mp4; charset=binary

A sample iOS-generated .m4a was verified using:

$ file -I iPhone-sample.m4a
iPhone-sample.m4a: audio/x-m4a; charset=binary

Supplemental Artifacts

The sample Android recorder audio file was supplied by @pontifier in #57530.