Now that we've got MP3 uploads starting up, the less-controversial MP3
*transcodes* are now on as well. :D
This means that Safari, Edge, and IE users will start playing back audio in
an MP3 version instead of loading the JavaScript decoder shim (ogv.js).
This means faster load times, which will get even better when we finish
retooling the media player controls later on...
It also means that the mobile view, which is incompatible with our current
media controls, will start having working audio on iOS and other
non-Android devices. Rock on!
(Firefox, Chrome, and Android will continue to natively play back Ogg
Vorbis audio files, or the Ogg transcodes of other formats.)
Looks like it will be a few days before the batch jobs finish at their
current rate to fill in the back-catalog; newly-uploaded files will
automatically pick up MP3 transcodes.
The ogv.js decoder shim is still used for video on Safari/IE/Edge, and for
audio in cases where an MP3 transcode isn't present yet.
== How does it work? ==
Similar to video, we produce files in multiple formats:
* the original file
* transcode to Ogg Vorbis
* transcode to MP3
If the original file is already Ogg Vorbis, we don't produce an Ogg Vorbis
transcode -- same if it's MP3 we don't produce a second MP3. All the ones
we do have get listed out in separate <source> elements, in a
server-defined preference order.
For browsers without special player JS, the <audio> element picks up the
first source the browser is compatible with -- so Safari or Edge sees only
MP3, while Chrome or Firefox sees them. Our player JS in desktop mode also
picks up native-Ogg preferably to MP3, but will use MP3 preferably to
software-Ogg (ogv.js shim).
In theory this should all be pretty transparent, and most people shouldn't
notice which version is being played back. But there's likely more work to
be done, from redoing the frontend player code to making it easier to place
audio and video in the editor. :)
-- brion