I was under the impression that the new FFmpeg nmr codec indeed outperforms the Apple one in every bitrate with Google's new Zimtohrli benchmark as well as ViSQOL. That would suggest Apple doesn't really have to open source anything, we should be good?<p>Still, I don't see the point. Unlike video, audio decoding is so cheap you can practically do it on software even on fairly constrained devices. So really only in places like Bluetooth headphones where codec complexity can have a direct impact on battery life does it actually factor in. I say for most purposes people should just be going Opus today: it is far ahead of basically anything else. In most cases, for old devices you can simply ship software codecs instead.<p>Hell, Wikipedia ships <i>video</i> software codecs in the form of ogv.js, mainly because a lot of Apple devices wouldn't expose VP8/VP9 support even on SoCs that had hardware support for it, and that works <i>surprisingly</i> well. So for something like Opus, obviously it is trivial even on older hardware, even in the confines of a web browser. (And of course, Wikipedia uses it for Opus as well, but my understanding is this is only necessary for 1-2% of Internet traffic since most devices/browsers support Opus these days)<p>That may leave some niches where AAC-LC is still a reasonable choice, like maybe old PMPs. However, I reckon that there are probably a lot of older PMPs that in fact, <i>don't</i> natively support AAC. For example, the trusty Sansa Clip+ from 2009 <i>doesn't</i> have AAC support. If you were to install third-party software such as Rockbox, well, then you'd have Opus support.<p>So for audio, I think barring any specific reason not to, the meta is to basically always choose Opus.
>I was under the impression.....<p>Yes. But subjective testing by IgorC ( of HydrogenAudio ) shows it wasn't as good as Apple. It was a lot better than previous FFMPEG though. I believe we will have a few more listening test results coming out soon.<p>>That may leave some niches...<p>iPod has over 80%+ of portable music players market share. And almost all the others shipped at the time, from Creative to other Chinese brands, car audio, TV and media player has AAC support. AAC-LC hit a sweet spot of near same MP3 hardware support while being so much better. 320Kbps MP3 still don't compete with 256Kbps AAC-LC on Apple Encoder. On the other hand, there are only a few samples where 256Kbps AAC-LC isn't transparent, barely noticeable difference but no artefacts compared to Opus in professional listening test, 95% of people wouldn't even notice. Opus do shines at 128Kbps to 160Kbps range where AAC-LC don't compete ( or dare I say wasn't even tuned ), but loses nearly all hardware compatibility.<p>If we were streaming, and storing music or audio tracks with 128Kbps then Opus would have had strong advantage. But we live in a world where we could even stream uncompressed audio files with plenty of bandwidth left. The file size of audio is so small it makes it negligible in consumer settings unless you are Youtube. ( I would still prefer a 256Kbps audio codec, for me it was instantly noticeable. I think Youtube at one point switched for premium but decided to switch it back )<p>For web then I guess there is an argument for Opus. But I keep saying the same with Video Codec as well. There is a whole world of Video and Audio Codec usage outside the web and PC / Smartphone. We could have used AAC and called it a day. And it is not just patent unencumbered, it is patent free.<p>If I was for a new Audio Codec, I just wish it could achieve what AAC-LC 256Kbps did with 128kbps. i.e I take quality first over potential bitrate savings. But the half bitrate marketing hasn't been true since MP3 Pro, HE-AAC, HEVC and VVC for "low bitrate". Neither HEVC or VVC could achieve what AVC did with 2Mbps in 1Mbps. VVC being very close, I would guess FVC / H.267 will finally be it, but at what complexity cost? We have hit sort of limit of compression. Both in Video and Audio. And today we have very different set of trade offs between file size, connection bandwidth, compatibility and encoding / decoding complexity then what we did 10-20 years ago. And I would choose compatibility + slightly larger file size for its simplicity.