A perfect illustration for how Chromium's monopoly is killing the open web. The sample audio doesn't play in Firefox, because who cares about anything other than Chrome, right?
To be fair, this looks like a firefox bug rather than google inventing their own 'standards'.
It's a bog-standard HTML5 audio tag with a WAV file. One file is 8khz and the other 24khz, both standard frequencies. One is Microsoft PCM format, while the other is IEEE float. I suspect the latter is the issue - even though it's been around for decades, I bet it isn't a well tested codepath in firefox.
It makes sense they use floats for machine learning outputs. Unless someone specifically thought to quantize the data to a specific bit depth, whatever wav file writing library google used probably thought it was being helpful by using the 'right' encoding.
I'm a Firefox fan myself, but this is on Firefox and nobody else. It should just work on Firefox; I wouldn't actually expect someone to do "testing" on a research article.
Maybe. On the other hand, the audio tag is pretty standard and the format is standard too, and if you look at w3c support page [1] it looks like ffox supports wav files (and it does, just not all of them. And they might just have tested if the first file plays (or even the second). I would say it's a firefox "bug" instead, there's not a good reason not to support this wav format.
And I say that as a Firefox user that never betrayed the fox for that shiny metallic look.
Especially since firefox probably ought to be using the underlying OS libraries for media decoding (and on windows, mac, and linux all the major libraries support this format).
Firefoxes "we need to invent it ourself so we aren't at the whim of the platform" has bitten them here.
Also, a patch to support this format is probably only 10 lines of code... Simply a for loop over every sample converting to 16 bit PCM.
They might not have tested it at all. It's just a blog post after all. Plenty of blog posts get published with broken links or duplicate paragraphs and basically anything else that isn't immediately obvious at a glance. Being published on a Google domain doesn't guarantee that they have a sophisticated testing process to catch these kinds of errors even in Chrome.
Sure, it's silly that Firefox doesn't support 24/32bit audio. But it's still Googlers assuming, as usual, that the entire world uses Google products and nothing else. If you can do audio code this impressive, then you can also downsample a waveform.
More like all the internal extensions at Google only work on Chrome (most importantly the U2F stuff for authentication which at some point might have better support in the future). That means it's a huge hassle to use a separate browser to even view an internal webpage (as this would be before publishing).
Right or wrong this isn't really about the Googlers that wrote this page or did the research but on the IT policy at Google that supports only Chrome. The policy itself isn't necessarily unreasonable either. What would you do given a finite headcount supporting 100k users across the world in all sorts of time zones? I'll also note that IT support at Google is probably the best, smoothest & on top of their game I've experienced having worked at a lot of companies including the biggest ones, so they're doing something right.
I wouldn't be surprised though that if this kind of negative feedback reaches this team they'll correct this page + make sure to test such interop issues for media going forward systematically in some way but these kind of blindspots are hard to catch especially when you're using standards that Firefox claims to support (I'll note that Safari doesn't have any issues with the audio).
