This issue mirrors #3133613: MPEG-4 Audio Files (M4A) with "Audio" Display Don't Play in Safari 13.1 → in the File Entity queue for Drupal 7.
We recently started working a lot with audio files on our Drupal-based platform, and the format that we receive the audio from our media asset management system is MPEG-4. We have our file fields configuring to use the "Audio" display format. When M4A files are uploaded to the platform and displayed, the audio player appears and works properly in all major browsers (Chrome 81, Firefox 75, Edge 44, and Edge 81) except for Safari (tested in 13.1).
<!-- break -->For clarity -- since I know that an M4A file is actually a container file type -- the Linux file command reports our M4A files as:
ISO Media, MPEG v4 system, iTunes AAC-LC
And VLC reports:
It appears that Safari takes issue with the MIME Type reported in the HTML markup for the audio file -- the <audio> tag advertises a MIME type of audio/mpeg. If I open the M4A source path in a new Safari tab (e.g. https://mysite.com/sites/default/files/audio/sample1.m4a), it opens and plays fine in the browser. Developer tools indicates that the MIME type that the Pantheon servers report to Safari is audio/x-m4a.
From various searches I've done, audio/x-m4a is less standard/older than audio/mpeg, and Safari (incorrectly) assumes that audio/mpeg means "MPEG-1, Layer 3". Then again, the IANA spec does not mention M4A in the registration for audio/mpeg. And, according to the /etc/mime.types that ships with Fedora 22, the mapping for M4A is supposedly audio/mp4. So, perhaps core's default mapping for M4A is just plain incorrect.
I have observed that if I manually edit the database and change the MIME type of an M4A file to audio/x-m4a instead of audio/mpeg, the audio will play in the page in all browser I test it with. So, it would appear either that Safari does not recognize audio/mpeg for this type of file (confirmed that it's the former by using the File MIME module).
As an aside, we did not see this behavior when we were using MP3 audio files on our platform. This issue appears to only affect MPEG-4 audio files.
Three approaches that might work to fix this:
ExtensionMimeTypeGuesser::$defaultMapping uses audio/x-m4a for m4a files instead of audio/mpeg, then write a migration to touch/update all existing file entities that have a mime type of "audio/mpeg" so that the database reflects the new MIME type; OR<audio> tags for the same source URL -- one with a MIME type of audio/mpeg and another with the Safari-desired audio/x-m4a MIME type; ORClosed: cannot reproduce
9.5
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
@mfb, thank you for testing!
In #11, this was not reproducible so I am closing this as cannot reproduce. If you are experiencing this problem, set the status to 'Active' and provide steps to reproduce.
Thanks.
Here's a patch which should resolve the incorrect MIME type: 🐛 .m4a files should use audio/mp4 MIME type, not audio/mpeg Fixed