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