Opus 1.2 Released
jmvalin.ca
jmvalin.ca
My last company (Zip Phone, YC S14) was a direct result of the fantastic work that the Opus team has done in the last few years. I remember researching audio codecs around the end of 2013 and stumbling across Opus, and being amazed at what it could do at extremely low bitrates, and everything was available completely for free! Spent my fair share of time on the Opus IRC channel on freenode (shout out to derf, gmaxwell, jmspeex, mark4o) bugging them with basic queries, and getting excellent support.
Opus rocks.
I usually encode music in Opus at around 140 Kb/s assuming it's transparent enough. At least using this: http://wiki.hydrogenaud.io/index.php?title=Opus#Music_encodi...
Xiph is amazing; I hope Daala actually becomes commonplace, but with the recent Apple announcements it's looking like a chance to usurp h.265 is basically gone.
What announcement?
https://www.apple.com/newsroom/2017/06/macos-high-sierra-del...
If AV1 would be released sooner it wouldn't be even as good as HEVC, which would be bad. VP9 is already that free-but-not-as-good-as-HEVC codec. Also they would need to release AV2 in 1 or 2 years (as the better-than-HEVC codec), which is just too soon after AV1 and would put a big question on why AV1 was released at all...
I.e. it makes sense to develop Daala further. Not sure what's going on in practice though. I guess it's better to ask Xiph / Mozilla.
We may return to Daala in the long term: it has competitive performance with HEVC on perceptual metrics despite a vastly simpler design than AV1 or even VP9, and despite being less mature than the classic block-based approaches and missing many tools that we simply didn't have a chance to implement (e.g., Daala has only basic MPEG2-style B-frames with no bi-prediction, as just one example).
Like the old adage says, if you have two baseball players who can run to first base in the same time, and one has perfect form while the other one looks lousy, which one do you pick? The guy with lousy form, because teach him the right form...
However, a lot of Daala's design is predicated on having a very constrained legal budget and not being able to rely on anyone else's patents. With the Alliance for Open Media, both of those constraints are relaxed. So even in the best case the result is likely to look pretty different from the way Daala looks today. Ultimately we're interested in making a codec people will actually use, and that means working with our partners.
Daala isn't dead and will continue to have value, at the very least as an experimental/development codec, but it may also form the base of a future static image format (it compares very well against JPG and HEVC/BPG. This is comparison is over a year old so it's even better now: https://people.xiph.org/~jm/daala/revisiting/compare.html
Same as FYI, not as in reference implementation or anything like that.
Unfortunately some of the most innovative techniques around frequency-domain prediction ended up not panning out. :(
If you want to build your own implementation, either to implement it in hardware, or to release it under a different license, then you’ll be fucked.
Anyway, as TD-Linux said above, any implementation is allowed.
> 1.1. Patent License. Subject to the terms and conditions of this License, each Licensor, on behalf of itself and successors in interest and assigns, grants Licensee a non-sublicensable, perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as expressly stated in this License) patent license to its Necessary Claims to make, use, sell, offer for sale, import or distribute any Implementation.
> 2.6. Implementation. “Implementation” means any implementation, including the Reference Implementation, that is an Encoder and/or a Decoder. An Implementation also includes components of an Implementation only to the extent they are used as part of an Implementation.
http://aomedia.org/license/patent/
I really have no idea what "to the extent they are used as part of an Implementation" means though.
Say, for example, you make a chip that does motion search acceleration and you want to sell it to people who do both AV1 and H.264 encoding. You'd be covered for any patents included under this license to the extent the chip was used for AV1 encoding, even though you didn't make a complete encoder. To the extent someone wanted to use it for H.264 encoding, your or they would still have to negotiate a separate license (just as you would have if AV1 didn't exist).
Source: I helped write this license.
https://www.zotac.com/product/mini_pcs/zbox_p_series
Intel's Compute Card is aimed at giving you a way to upgrade the computing side of devices like TVs without having to buy a new TV:
https://arstechnica.com/gadgets/2017/01/intels-compute-card-...
I wonder why the MP3 at low bitrate sounds a bit like a lowpass filter.
It is still pretty crazy that I find a sub 100 kbps sound sample to be indistinguishable from lossless. Definitely considering transcoding my flac library to 96 vbr opus for backup purposes.
I'm not sure what you mean. FLAC should be the backup.
For instance, if you want to encrypt speech, and don't want to leak information about its contents.
I reasoned the additional lossy encoding of Bluetooth would be too much with lower bitrates, but now I'm not so sure...
EDIT: It looks like TFA says that Android does use Opus:
> Opus is now widely deployed on a large range of platforms and devices (including Android, iOS, and all major browsers) and is exposed to untrusted data.
That claims they need to be in a MKV container, but I just use the output of opusenc.
My tests (on a Pixel running 7.0 and the O beta) have determined that Opus is usually fine as long as the container and file extensions are both Ogg. I have had a few issues with certain files but I'm not sure why yet, I suspect it's album art or something.
I don't believe Android <= 6.0 supports Opus as audio on its own. The CDD initially only required support for Opus in a Matroska container and I attempted to put an Opus-only Matroska file on my phone and none of the players were able to play it. As of either 6.0 or 7.0 (can't remember which), Ogg support is required though.
https://play.google.com/store/apps/details?id=com.jrtstudio....
It's just amazing.
You can throw anything at it. No matter the sample rate and the bitrate and the output has good quality without any of that narrowband, wideband, ultra-wideband speex nonsense.
All that is missing is an "hybrid" mode just like wavpack that produces combined output of roughly the same size as flac.
re: wavpack, from wikipedia:
> WavPack also incorporates a "hybrid" mode which still provides the features of lossless compression, but it creates two files: a relatively small, high-quality, lossy file (.wv) that can be used by itself; and a "correction" file (.wvc) that, when combined with the lossy file, provides full lossless restoration. This allows the use of lossy and lossless codecs together.
This hybrid encoding format lets you keep files for both purposes (lossless for audio production and archiving, pre-encoded to HQ lossy for audio consumption) in less space than would be required to keep e.g. an ALAC file + a cached lossy M4A encoding of it, the way iTunes does when you specify "optimize tracks' space-usage for portable devices."
Such a hybrid design is ideal for e.g. the Internet Archive, where they want to keep lossless archival representations of files for historians to study, and to create encodings from; but also want to serve usable representations of those artifacts to users who care more about transfer-speed and bandwidth cost than perfect fidelity.
I have about 600GiB FLAC music from bandcamp, random publishers, and CDs. I then have, separately, the same directory structure but encoded as 96k and 128k Opus. Still all fits just fine on a mere TiB disk. In a couple years the difference between 96k and 128 in terms of space won't matter and I'll drop 96.
And yeah, it's very nice to have the FLACs when I want to timewarp, transcribe, analyze, or remix. I usually do that at home though, so I can splurge on the bandwidth.
WRT the Internet Archive, Wavpack hybrid decoding is probably too slow and too rare to bother including in any major browser. Even if they did, if lossy listening is a priority, a dedicated lossy codec will save them money in short order on bandwidth. Indeed, this is exactly how IA does things, they even have wav in addition to flac and two or three lossy versions of (almost?) every recording.
Then, you could actually do mixing in apps like DJay straight on your iPad, on a whim, sometimes—without having planned for it in advance—and make it straight through to mastering and uploading the result... unless you filled up your whole iPad with random videos/apps/etc. in the meantime, in which case the lossless versions would be gone, you'd have to work with the lossy copies, and then, when you get home, restore the lossless copies (or transfer the project to your PC) to master the encoding.
So, not so much when you want the lossless version as canonical (most times when you have a lot of space), but rather when you want the lossy version to be canonical, and the lossless version to be there as a sort of "optional file to enable mastering using this track" file, that's sometimes available and sometimes not.
Other attempts include Dolby TrueHD and DTS HD - but both of those ended up larger than just separate FLAC and Opus files.
I made some very crude tests a few minutes ago and got about 15% size increase in total size (opus + diff.flac vs flac --best)
However, as a result, the difference between an Opus decode and the original will only get you lossless reconstruction if you decode with the same build of Opus on the same machine. Also, since Opus uses IIR filters that ring to infinity, even on the same machine you only get bit-exact results if you decode each file from the beginning. It won't work if you seek.
Really, if you're concerned about the disk space required for separate FLAC and Opus encodes, delete the Opus version. FLAC decoding is extremely fast (5x faster than Wavpack), and Opus encoding is pretty efficient, too (on the same order as Wavpack decoding).
It's not published yet, though I might. It's pretty simple, just grabs a static JSON manifest (which is generated by the shell script I run when I add music to the collection, which adds replaygain tags and transcodes) which includes basic metadata and the ReplayGain tags so that I can set that manually in the browser. Uses the standard rule for continuous play and replaygain: play whatever was in the view when you played the first song then shuffle play, when the song you're playing is followed by the next song or follows the previous song on the same album, apply album gain, else apply track gain.
I have yet to add dynamic features like cross-player play count tracking, and server-side play counts for the webapp. I think these would be a lot more work than I put in.
My Github is https://github.com/xorgy if you want to follow/check in to see if I publish it.
(Re: quantization change in encoder. Also known as statistical or statistician rounding.)
Anyway I assume they're taking their well deserved credit for the implementation, not necessarily the discovery.