fix(audio): map webm and mp4 container mime types to audio extensions - #1030
Open
mrmorgan-i wants to merge 1 commit into
Open
fix(audio): map webm and mp4 container mime types to audio extensions#1030mrmorgan-i wants to merge 1 commit into
mrmorgan-i wants to merge 1 commit into
Conversation
wishborn
added a commit
to Particle-Academy/prism
that referenced
this pull request
Aug 12, 2026
Upstream PR by @mrmorgan-i. Browsers report the CONTAINER type, so an audio-only MediaRecorder clip arrives as video/webm or video/mp4 and was being written out as audio.mp3 — the wrong extension on every browser recording, which providers then reject or mis-transcode. Applied upstream's mapping (video/mp4, video/ogg, video/webm) plus one gap it does not cover: MediaRecorder attaches codec parameters, so the very mime types this fix targets arrive as "audio/webm;codecs=opus" and fell straight through to the mp3 default anyway. The mime type is now reduced to its bare type and lowercased before matching, so the fix works on real browser output rather than only on the canonical strings.
|
@mrmorgan-i — this is now released in the maintained fork ( Your mapping went in as-is, plus one gap it didn't cover: Thanks for the fix. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
finforeports browserMediaRecorderoutput asvideo/webm, since WebM is a container format. That isn't inGeneratesAudioFilename's match list, so it falls through todefault => 'mp3'and the file gets uploaded asaudio.mp3with WebM bytes inside it. OpenAI fails to parse it with:Same thing happens with
video/mp4, which is what Safari'sMediaRecorderproduces.This adds the container types to the existing match list. The
default => 'mp3'fallback is unchanged, along with the three tests covering it.Related to #981. That issue covers the
audio/x-wavalias, and #1001 handles it at theMedialayer, which makes sense for aliases that are for sure audio.video/webmis different because it's a truthful mime type, and normalizing it inMediawould break genuine video input such as Gemini's. So this only touches the audio filename helper, and the two changes shouldn't conflict.