It makes me vaguely ill to think that anything about WAV is patentable -- it's a simple tagged file format similar to TIFF, PNG, and numerous things from the 80s and 90s.

Is it the file format itself or some particular audio codecs that are going out of patent?

It looks like the specification for the WAV file format, the RIFF container format, and Microsoft's Linear PCM bitstream encoding format (the most common encoding for WAV files) was published in 1991. That means that if there were any patents associated with these formats, they will almost certainly be expired at the end of the year.

WAV also supports ACM compatible compression formats, some of which are patented like MP3. The vast majority of WAV files are uncompressed PCM audio, though, as people typically use other formats for compressed audio.

I believe all browsers support native play-back of uncompressed WAV files (either in an embed tag or loaded on it own), and all of them except Explorer support WAV playback through the HTML5 audio tag. It is also supported by virtually every audio editing program ever made, which gives it an advantage over FLAC (and Ogg Vorbis).

WAV doesn't seem to make much sense as a format, FLAC would be way better.
We don't allow people to upload in silly formats like .bmp only because they're supported by everything.

I think bug 20252 is a better solution, being also consistent with what we're trying to do with video, and also made possible (I suppose) by the expiration of patents, but without locking us with a format of possibly unclear legal status.

WAV files would at least need five times more space than HQ-vorbis files. (Even lossless FLAC is about half the size of PCM-encoded WAV files)... On slow internet connection the WAV would not even load and in general the server resourced would be wasted for nothing.

mdale wrote:

For the first phase of this bug, I think we should just support ingestion of wav files. I don't think we should not add wav as a transcode target.

This is useful for browser audio recording ( Rahul21 SOC project: https://www.mediawiki.org/wiki/User:Rahul21/Gsoc ), helps commons be more of an archive and high bitrate is probably fine for the initial target of in browser recording of pronunciation.

Since FLAC is loss-less, we could convert to that in the back-end if .wav file storage ever becomes an issue. Ideally the end user would upload in FLAC, but a common ingestion format will probably be AAC given mobile capture and upload support. But we can cross that bridge in a different bug.

For users playing content they should almost always use the .oga or future lossy compressed formats that we target.

This bug, involves adding a wavMediaHandler to TMH, then TMH will automatically transcode to oga from the wav file. We could add additional targets FLAC, mp3 etc in the future.

Related URL: https://gerrit.wikimedia.org/r/69401 (Gerrit Change I8344cb0d5564b28ce5ffb0d541f077c58e0b545f)

Related URL: https://gerrit.wikimedia.org/r/69952 (Gerrit Change I882ea12ce1800a068dc15495611e6765f7a88ae4)

Change 69401 merged by J:
Add support for WAV audio files

https://gerrit.wikimedia.org/r/69401

Change 71129 had a related patch set uploaded by Rahul21:
Add support for WAV audio files

https://gerrit.wikimedia.org/r/71129

Change 71129 merged by jenkins-bot:
Add support for WAV audio files (Fixed a small typo and made some minor changes to the i18n and qqq messages)

https://gerrit.wikimedia.org/r/71129