There’s struggling in waking up and testing the new Safari/Mac version.
If you are wondering it doesn’t currently work with our Cloud Web Player.
A bit of background, the issues started after an update to Safari 4.0.5.
On Mac OS X Safari uses an internal component, called CoreMedia, that takes care of rendering what it matters to us, audio.
After updating we realized that something was wrong since it cannot play some mp3s, so after a deep investigation I notified Apple about this bug through their bug tracker; I got a little response from an Apple employeer demanding more data to test, even though my bug description was extremely clear and had attached all the required files.
The bug was presenting itself in the new HTML 5 audio tag, if Safari/Mac tries to load a remote file, i.e. a mp3 file hosted on a remote location, it just fails silently.
I updated the Apple ticket two or three times but never got a response.
For our AudioBox.fm we had only one solution, a fallback to Adobe Flash was needed, thus skipping the HTML 5 part.
The issue that is raised then is that sometimes it doesn’t switch automatically to the next track, and that’s a major headache for us.
You now may ask why Google Chrome does indeed work since it have the same rendering engine.
The answer is pretty simple, while Chrome does use WebKit it doesn’t take ‘advantage’ of CoreMedia to render audio files.
Yesterday Apple released Safari 5, at first I thought “Great, they may have been fixed this bug, let’s try”.
To my disappoint not only they didn’t fixed anything, but my tests reveals that CoreMedia now isn’t able to playback anything.
So, again, we will recognize the new Safari identification string and fallback to Adobe Flash.
I’m talking to Valerio and Fabio to understand if it’s just an incredible bug in CoreMedia that just gotten worse or it’s made on purpose.
Either way we strongly advise switching to Google Chrome.
