Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use mimetype audio/wav for .wav files #620

Merged
merged 1 commit into from
Jan 7, 2024

Conversation

luckv
Copy link
Contributor

@luckv luckv commented Dec 30, 2023

Use mimetype audio/wav for .wav files instead of unsupported audio/vnd.wave

As pointed out in this comment, the correct mimetype supported by all major browsers (chrome, firefox, safari) is audio/wav and not audio/vnd.wave.

I made a simple html page to test the behaviour, which also include a test for .avi files. The test show that I didn't find any supported mimetype for .avi files, so I will not do a PR for that.

test-mimetype.zip

Use mimetype `audio/wav` for `.wav` files instead of unsupported `audio/vnd.wave`
@Borewit
Copy link
Collaborator

Borewit commented Jan 7, 2024

Wiki mentions 3 used MIME types for the "WAV audio file format":

  1. audio/vnd.wave
  2. audio/wav
  3. audio/wave
  4. audio/x-wav

None of those is solid, as there is no authoritative IANA registration.

audio/vnd.wave is mentioned in RFC 2361 WAVE and AVI Codec Registries

vnd. is prefixed for vendor as specified in RFC 6838 Media Type Specifications and Registration Procedures. After the .vnd the vendor name should appear, so audio/vnd.microsoft.wave would be a more sensible MIME type in my humble opinion. Given that the WAV format is in nowadays more common good then proprietary, to register this format as vendor specific does not make much sense to me.

WAV is using the RIFF container format, which is documented with a unregistered MIME type: application/x-riff. To fall back on the container format, does not seem to be the convention.

Unregistered entries should be prefixed x- (no 4) *. By that definition, number four is valid. But the The paradoxical statement made also in RFC 6838 is that these x- should only be used in private / local environments. The reality is, is that WAV files are widely used in public, and just to prevent this kind of painful solution, if I would be working for IANA, I would just register audio/wav for the sake of normalization. Yet I do not work for IANA.

Then there is audio/wav. wav is the original Microsoft extension, in the MIME types there is no need to stick to the 3 character extension, and in that aspect audio/wave or audio/waveform would be more logic.

I have no objections to change to audio/wav, it's a bit of an arbitrary choice. One can choose the most widely spread convention, unfortunately this is also something which is hard to measure.

If the Mozilla listing of audio/wav can be accepted as a common browser convention, we could follow their convention as well.

@Borewit
Copy link
Collaborator

Borewit commented Jan 7, 2024

Sorry, I noticed the discussion on #150 after I wrote my response. Conclusion is aligned.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants