A bit of a rant about how Safari is a mess to deal with.
My last 2 posts have been about audio files. Resolving the little annoyance of not being able to host them on Neocities because of their (totally understandable) policy for free accounts was pretty simple: find a second hosting provider that allows audio files to be enbedded/hotlinked by a webpage. The choice was Cloudinary (mainly becuase they are the only ones that offer it for free), but they offer a limited amount of storage/bandwith so I need to play it smart.
First ideas when thinking about saving file size on the web:
- Reduce the bitrate (The audio player was meant only as a preview, you can find the original RAW or high quality files when unpacking the games)
- New generations encoders (AAC, Opus)
- Remove superfluos stuff (i.e. multiple channels)
After some testing my choice went to OPUS, mono, constrained bitrate at 29kbps with foobar2000 + vgmstream plugin.
I admit that at the moment I completely forgot to check the compatibilty with the various browsers, after all the OPUS codec has been around for 8 years and I know for sure that Youtube has been serving it on my laptop and smartphone without any problems whatsoever.
The alternative was AAC (or probably HE-AAC) but the quality of free AAC encoders is a bit meh so I dismissed it.
Okay, now we are all settled: let’s make the audio player.
We can go with a simple list of <audio></audio> but they don’t look that good on every browser and you have to build the state management (only one audio playing at any moment, play the next one as soon as one ends, etc) yourself.
Time to use an external library, after some browsing the libraries useful for my use case were:
- webamp
Drawbacks: Unusable on portable devices - amplitudejs
Drawbacks: Slow and sluggish in their own demos - paper audio player
Drawbacks: The whole building pipeline while trying to self-host it. - html5 audio player
Drawbacks: Missing some features but was overall good looking, fast and easy to work with.
After deciding on the last one and making it work, I had a doubt:
Does it work on Safari?
During the developement I usually preview/test on Firefox/Chrome for Android/Chrome/Edge/ (yeah, I know, the last two are basically the same) but I never tried WebKit based browsers (they are not that easy to install on Windows) and I know that Safari has been lagging behind on Chrome/Firefox in terms of features and support, but if it’s just some esthetic missmatch I don’t care that much (also because most of the time is 100% Apple’s fault).
But not being able to play audio is not an esthetic annoyance, maybe I should care.
Ok, let’s check it and …. yeah, Safari has a “yeah, it does support OPUS but with a caveat”.
Mhhhh, what the hell is a .caf file?
It’s a niche audio container used by some Apple-specific software, tbh it’s fairly easy to losslessly convert to from a .opus file.
ffmpeg -i file.opus -c:a copy file.caf
Sooo… what’s the the deal then?
No audio player library supports multiple formats, they all assume that all files just work (or that you can provide a file that can work for everyone).
Unironically the easiest way to have multiple format is to use the standard <audio></audio> tag with multiple <source>.
Should I try to add multiple sources support to the audio player? Maybe, the code is fairly easy to start with, but I can’t exactly test it.
Should I scrap the audio player library and go with the meh standard audio element? No, I don’t want to provide a worse user experience because of Apple.
Should I use the standard audio elements as a fallback for Apple users? Yes, I will need to remux the audio files and use double the storage but at least the site will work for them too ig. The audio/source tags are also simple to use so there is no need for complex iterative testing.