Audio codec support has been a thorn in our side for years. It was a problem when we first got going in 2011, and six years later, browser support is not a whole lot better. Construct 2 still uses two audio formats to support all browsers, MPEG-4 AAC (.m4a) and Ogg Vorbis (.ogg). AAC is a patent-encumbered format and distributing encoders incurs a fee, which would make the Free Edition uneconomical. In Construct 2 we use a clever workaround: Windows 7+ has an AAC encoder built-in which we use when importing audio, and thus we avoid having to ship an encoder ourselves. However the encoder cannot be accessed from a browser, and is not available on all other operating systems anyway. So for Construct 3 this posed a problem: how do we support Safari and Edge, which don't support Ogg Vorbis?
Looking to an Opus future
We've been keeping an eye on Opus, a modern new audio codec with excellent compression while maintaining very high quality. Chrome and Firefox have supported Opus in a WebM container for a while now, and Edge almost supports it — it can use it in some scenarios, but not Web Audio yet from what we can tell. Presumably the decoder's there in the browser so it should be possible to enable it for Web Audio too.
Assuming Edge eventually fully supports it that only leaves Safari, which is working on WebRTC support, which also commonly uses Opus. So it's plausible it could eventually be supported in all major browsers, making WebM Opus the most likely candidate for full cross-browser support.
Opus in Construct 3
Consequently in Construct 3, importing audio encodes it to WebM Opus. By the way, this is done entirely in the browser using an asm.js compiled encoder — no need for any extra tools or uploading to servers.
However, Edge and Safari today still don't have built-in Opus support. To cover them, the runtime also provides its own WebM Opus decoder which Iain has been working on for some time. It's compiled with asm.js for native-like performance, and as of r50, thanks to Iain's latest efforts, also has an alternative WebAssembly version for maximum performance. Safari and Edge get WebAssembly support later this year and this will help ensure decoding is done optimally. Both asm.js and WebAssembly versions are scheduled to run across multiple CPUs for maximum performance, allowing multiple audio files to be decoded in parallel.
In the end, this means in browsers without native support we decode WebM Opus ourselves, and can then play back the decoded versions with the Web Audio API. It does use a bit more memory than having native support, but it's very similar to the workaround we've been using for some time in WKWebView (for iOS apps) without ill effect. This means your WebM Opus audio files can play in all modern browsers. As soon as either Safari or Edge gets support for built-in decoding of WebM Opus, the runtime will automatically detect this and switch over to the browser's decoder. Ultimately if both Safari and Edge have built-in support for WebM Opus we'll probably eventually remove our own decoder, but that could take some time; our own decoder will fill in until then.
The only browser left out is Internet Explorer: it neither supports WebM Opus nor has the Web Audio API, so there aren't really any sensible workarounds left. However IE has a falling market share as it is steadily being replaced by Edge, and for some exporters IE support is irrelevant (like Cordova and NW.js). Additionally you can still encode .m4a or .mp3 versions of audio files yourself and import them to C3, and audio will work again on IE.
One format after all
So we're hoping in the long term, this finally leaves us with just one audio format that works everywhere: WebM Opus! This will make managing audio easier, reduce the size of your exported games, simplify deploying to the web, and make use of the latest codec with the best quality and compression available. The only browser left out is Internet Explorer, but those who need to cover old browsers can use a separate encoder to create their .m4a or .mp3 files and import them to Construct 3, where it will fall back to using them just like in Construct 2.
So if you were wondering why Construct 3 has started creating .webm files when you import audio, that's why!