After more than two years of development, we have released Opus (http://opus-codec.org/) 1.1. This includes:
- new analysis code and tuning that significantly improves encoding quality, especially for variable-bitrate (VBR)
- automatic detection of speech or music to decide which encoding mode to use.
- surround with good quality at 128 kbps for 5.1 and usable down to 48 kbps.
- speed improvements on all architectures, especially ARM, where decoding uses around 40% less CPU and encoding uses around 30% less CPU.
These improvements are explained in more details in Monty's demo (http://people.xiph.org/~xiphmont/demo/opus/demo3.shtml) (updated from the 1.1 beta demo).
Of course, this new version is still fully compliant with the Opus specification (RFC 6716).
Thank You to all developers and people involved in development of Opus.
This is a very impressive release.
How much time and effort have been put into it.
I wonder how long it'll take to get a binary?
I wonder how long it'll take to get a binary?
It's already there: http://opus-codec.org/downloads/ (http://opus-codec.org/downloads/)
opus-tools 0.1.8 has libopus 1.1.
Big thanks to the Opus team. This is a fantastic release with great new features.
Thank you! Is there a list somewhere which details the fixed bugs, or my only source for this is the commit log right now?
I'm very angry now for the Poweramp guy to not include the decoder in it's player. We've asked for that more than a year ago.
Thank you! Is there a list somewhere which details the fixed bugs, or my only source for this is the commit log right now?
For the bug fixes (as opposed to the new features in Monty's demo), I guess the shortlog (http://git.xiph.org/?p=opus.git;a=shortlog;h=refs/tags/v1.1) is your only option.
surround with good quality at 128 kbps for 5.1 and usable down to 48 kbps, and
I'm curious if there's upcoming directshow filter for opus, like updated OpenCodecs or another 3rd codec bundle?
(...) These improvements are explained in more details in Monty's demo (http://people.xiph.org/~xiphmont/demo/opus/demo3.shtml) (updated from the 1.1 beta demo).
Of course, this new version is still fully compliant with the Opus specification (RFC 6716).
Really impressive work (along with the way you present those changes - which really caters to laymen such as myself).
Thank you!
I wanted to post the results of rockbox runtime on the clip+ with the 1.1, then realized I forgot to start the battery benchmark... It does seem to have a longer battery time now though, compared to previous build.
Surround masking takes advantage of cross-channel masking between free-field loudspeakers. Obviously, we can't do that for stereo, as stereo is often listened to on headphones or nearfield monitors, but for surround encodings played on typical surround placements with listeners placed well within the soundfield, there's considerable savings to be had by assuming freefield masking.
Curious, what does this mean for the few real surround headphones? (3 speakers per side)
Guess I'll finally give this a try, thanks for all the hard work.
1.1 had a stable quality already starting from alpha build. Probably people should lose a prejudice to don't try anything that's not a 100% final.
Instead they could report some certain situations those could be improved. Everybody would win.
Are there again public ABX listening tests, like these famous events by Roberto J. Amorim? Version 1.1 promises a severe quality-per-bitrate boost, I wonder how certain this is approved by the audience.
Last time we have organized test it was 2011 and that was CELT 0.11.2.
I've sent a few mails and talked with some other people who was involved into last public test.
Most probably there will be a test, this time I will be just a co-organizer (or even less than that). It should be a new person who will recolect the results among the other functions.
I'm curious if there's upcoming directshow filter for opus,
LAV filters has supported Opus for a while now.
This new release is great!
Seems to perform just fine and now handles some of my previously problematic files like I expect it to do.
Can't wait till it can be used properly for surround sound in movies (VLC doesn't yet like it very much in an MKV but a dev said it was on its list).
Looks like rockbox+opus now manages to squeeze out 30 minutes more of runtime on my clip+ (10:04:40 -> 10:38:05 @160kbps).
That's great, but still way behind FLAC (16:09:49@lv8) or MPC (16:13:47@192kbps). Logs for comparison here (https://www.dropbox.com/s/lnhzisi3tgy217d/Clip%2B%20battery%20bench.zip)
Looks like rockbox+opus now manages to squeeze out 30 minutes more of runtime on my clip+ (10:04:40 -> 10:38:05 @160kbps).
That's great, but still way behind FLAC (16:09:49@lv8) or MPC (16:13:47@192kbps). Logs for comparison here (https://www.dropbox.com/s/lnhzisi3tgy217d/Clip%2B%20battery%20bench.zip)
Just an hour behind your mp3 scores, which isn't too bad. I'm surprised mp3/vorbis do so poorly though, I get longer out of MP3 then you do out of any format.
I think it's because of the settings. MP3 one is -V0. Vorbis was q4.0.
I forgot to specify the bitrates for the rest of them.
It might also be related to the CPU the clip+ has, or the fact I'm playing them off µSD, but that's something you know more about, I guess.
In any case, not a bad performance, but I'll still stick with FLAC for convenience of simply copying the files over, since my playlists are small and change frequently.
Can you test AAC? Particularly Apple's AAC?
Documentation (opusenc.html) claims that Opus supports bitrates beginning from 6 kbps per channel. But actually for bitrates <30 it performs downmixing to mono. At 30 kbps we have something (but very sick) on the side channel, and starting from 32 kbps we really have a stereo effect, but stereo pan is much narrower than original.
On other side FhG AAC's parametric stereo handles stereo at low bitrates very well. So which stereo encoding technology is used by the Opus? Looks like a simple Mid/Side encoding (but maybe separate for each frequency band, like in AAC).
P.S. Starting from about 40 kbps I get almost independent stereo encoding (I mean very low stereo crosstalk). However, I wonder what's this transition interval between 30 and 40 kbps.
Documentation (opusenc.html) claims that Opus supports bitrates neginning from 6 kbps per channel. But actually for bitrates <30 it performs downmixing to mono. At 30 kbps we have something (but very sick) on the side channel, and starting from 32 kbps we really have a stereo effect, but stereo pan is much narrower than original.
Not all applications need stereo. At 6 kb/s, which is low bitrate even by VoIP standards, what you can have is narrowband mono.
On other side FhG AAC's parametric stereo handles stereo at low bitrates very well. So which stereo encoding technology is used by the Opus? Looks like a simple Mid/Side encoding (but maybe separate for each frequency band, like in AAC).
Opus uses "normalized mid-side", which unlike MP3-type mid-side cannot introduce cross-talk (i.e. we could use it on every frame and still sound good). We also do a variant of intensity stereo. We do *not* do the kind of parametric stereo that HE-AAC v2 uses for multiple reasons. Obviously there'd be patent issues, but beyond that, parametric stereo introduces time-domain post-processing, which would increase latency (defeats one of the goals of Opus), increase complexity, and still not result in good quality (it's more of a race to the bottom). Personally, I find v2's PS extremely unpleasant to listen to (gives me motion sickness when listening with headphones) and I prefer mono. It makes nice demos, but that's about it.
P.S. Starting from about 40 kbps I get almost independent stereo encoding (I mean very low stereo crosstalk). However, I wonder what's this transition interval between 30 and 40 kbps.
This is correct. The 1.1 encoder gradually transitions from mono to stereo between 30 and 38 kb/s. It's a tradeoff between coding artefacts and stereo image, but there's still some tuning left to do on this. If you're interested in fiddling with it, it's just a matter of changing two lines of code and recompiling.
Not all applications need stereo. At 6 kb/s, which is low bitrate even by VoIP standards, what you can have is narrowband mono.
Sure, but in fact that statement is incorrect and minimum 16 kbps per channel is needed to get stereo effects. Maybe you should make some corrections to the manual.
Not all applications need stereo. At 6 kb/s, which is low bitrate even by VoIP standards, what you can have is narrowband mono.
Sure, but in fact that statement is incorrect and minimum 16 kbps per channel is needed to get stereo effects. Maybe you should make some corrections to the manual.
Euh, what exactly are you saying is incorrect in my statement? What does the manual say that you think should be changed?
If the minimum bitrate is 6 kbps per channel (as stated in opusenc.html), then minimum bitrate for stereo encoding is 6*2=12 kbps. But in fact we get a mono encoding (one channel) at 12 kbps (and even up to 30 kbps).
If the minimum bitrate is 6 kbps per channel (as stated in opusenc.html), then minimum bitrate for stereo encoding is 6*2=12 kbps. But in fact we get a mono encoding (one channel) at 12 kbps (and even up to 30 kbps).
The quality is also minimum at 6kbps. If I have only 12kbps of bandwidth, I'd like to use that additional 6kbps to increase the audibility, rather than to get the fancy stereo effect, while retaining the minimal quality.
If the minimum bitrate is 6 kbps per channel (as stated in opusenc.html), then minimum bitrate for stereo encoding is 6*2=12 kbps. But in fact we get a mono encoding (one channel) at 12 kbps (and even up to 30 kbps).
The quality is also minimum at 6kbps. If I have only 12kbps of bandwidth, I'd like to use that additional 6kbps to increase the audibility, rather than to get the fancy stereo effect, while retaining the minimal quality.
Agree. But I'm saying just that statement in documentation is incorrect and some correction (or notes maybe) are needed.
Can you test AAC? Particularly Apple's AAC?
If you can tell me how to set it up without installing iTunes/Quicktime, I would. Personally, I don't really have any interest in AAC, it was pretty intransparent up to a high bitrate for me (the nero aac encoder) a few years ago. Haven't tested it recently though, so not going to claim anything
Can you test AAC? Particularly Apple's AAC?
If you can tell me how to set it up without installing iTunes/Quicktime, I would. Personally, I don't really have any interest in AAC, it was pretty intransparent up to a high bitrate for me (the nero aac encoder) a few years ago. Haven't tested it recently though, so not going to claim anything
If you download qaac 2.27 and makeportable from here https://sites.google.com/site/qaacpage/cabinet (https://sites.google.com/site/qaacpage/cabinet) you can make it portable.
Is there any improvement in sound quality from 1.1 beta to the 1.1 final release? Thanks
Is there any improvement in sound quality from 1.1 beta to the 1.1 final release? Thanks
Yes, though not as much as from 1.0.x to 1.1-beta.
I wish the tagging of Opus could include using more efficient image formats for album art. Like WebP.
Is this something to develop in future releases? (I guess this would be an extension of OGG container?)
Opus is all about hq at low bitrate, I think that "vision" should include album art too.
WebP is a google format. Devices on Android can read it native afaik. Would be very usefull
I wish the tagging of Opus could include using more efficient image formats for album art.
Does Opus even include album art in the specification?
The "advantages" of WebP are rather controversial in the first place:
http://people.mozilla.org/~josh/lossy_comp...y_october_2013/ (http://people.mozilla.org/~josh/lossy_compressed_image_study_october_2013/)
I think you can already put any image you want in Ogg. At least people keep reporting "broken" Ogg files with all kinds of embedded images that they expect to work.
I wish the tagging of Opus could include using more efficient image formats for album art.
Does Opus even include album art in the specification?
The "advantages" of WebP are rather controversial in the first place:
http://people.mozilla.org/~josh/lossy_comp...y_october_2013/ (http://people.mozilla.org/~josh/lossy_compressed_image_study_october_2013/)
I think wait until WebP is based off VP9, in it's current state it's really not that much of an advantage.
If the minimum bitrate is 6 kbps per channel (as stated in opusenc.html), then minimum bitrate for stereo encoding is 6*2=12 kbps. But in fact we get a mono encoding (one channel) at 12 kbps (and even up to 30 kbps).
I think it actually says 6kbps is the minimum "target" bitrate. I think for low-frequency in surround sound it gets less than that, so 6kbps doesn't seem to be a technical limitation.
I think it actually says 6kbps is the minimum "target" bitrate. I think for low-frequency in surround sound it gets less than that, so 6kbps doesn't seem to be a technical limitation.
The 6 kb/s we generally quote is the lowest "usable rate", i.e. the lowest we think someone sane might want to use. If you want you can reduce the rate down to 2 kb/s, but at that rate all you get is modulated low-frequency noise. We can even losslessly encode digital silence at 1.2 kb/s.
I'm very angry now for the Poweramp guy to not include the decoder in it's player. We've asked for that more than a year ago.
Have you looked into http://www.bsplayer.com/ (http://www.bsplayer.com/) ? They were very responsive to my request and added it to their Android app several months after I made the request.
Is there any chance we'll see updated builds on RareWares? http://www.rarewares.org/opus.php (http://www.rarewares.org/opus.php)
And is there an oggdropxpd-equivalent for opus available somewhere?
Thanks.
And is there an oggdropxpd-equivalent for opus available somewhere?
http://www.hydrogenaudio.org/forums/index....howtopic=100950 (http://www.hydrogenaudio.org/forums/index.php?showtopic=100950)
I've decided to encode my collection into Opus 1.1 @ 256kbps unconstrained VBR which sounds like an overkill but i've just listened to the U96 sample which i reported earlier as a problematic one (http://www.hydrogenaudio.org/forums/index.php?showtopic=101993) for Opus-1.1 beta and i can confirm that i can still ABX it at this setting with the release encoder:
foo_abx 1.3.4 report
foobar2000 v1.2.9
2014/01/04 01:17:48
File A: D:\sample.flac
File B: D:\sample.opus
01:17:48 : Test started.
01:18:48 : 01/01 50.0%
01:19:53 : 02/02 25.0%
01:20:25 : 03/03 12.5%
01:24:19 : 04/04 6.3%
01:24:43 : 05/05 3.1%
01:24:46 : Test finished.
----------
Total: 5/5 (3.1%)
Opus notices the difficulty and with the --vbr 256 setting the final bitrate is 303kbps but it still produces noticeable pre-echo noises.
It's a lot easier to understand the problem if it's encoded at a lower bitrate, like 96kbps.
I was experimenting more today with Opus and found out that encoding the U96 problematic sample with the --framesize 10 setting makes the pre-echo artifact almost completely gone away at 256kbps and i haven't done an ABX yet, but it seems impossible for me to detect it at --framesize 5.
If i understood it correctly the percussion error is coming from the transient problem the babyeater build tried to solved earlier by varying the frame size if a transient was detected. So it's not a suprise that forcing a decrease in framesize makes things better by this sample.
I've read on the Hydrogenaudio wiki (http://wiki.hydrogenaudio.org/index.php?title=Opus#CELT_layer_latency_versus_quality.2Fbitrate_trade-off) that decreasing the frame size hurts frequency resolution and bitrate have to be increased to keep the quality level. At 5ms frames 32.5% bitrate increase is required to keep up with the changes. This means that instead of 256kbps i had to use 339,2 kbps, but i was going with 320kbps since it's not that far away from that and it's approaching the common 320kbps CBR mp3 bitrate more so the final file size is comparable.
So i've came up with a --vbr --framesize 5 --bitrate 320 setting right now and i'm willing to test it with a longer encode of my collection.
I'm interested about what kind of artifacts will arise if i'm using the --framesize 5 setting, what should i looking for?
Also i'm thinking about using --cvbr instead of --vbr at this bitrate. Some of my tracks are getting very huge bitrate boost from the tonal estimator (mostly chiptune music or electronic music with saw-wave like sound) and it might be not necessary at such high bitrates.
A very good example for this is Benny Benassi's track: Able To Love (from the Album: Hypnotica) which has a strong synth sound in the beginning for a long period. Sometimes it even peaks to >=450kbps when encoded at 256kbps VBR according to the foobar2000's realtime bitrate display.
Another example comes from from farbrausch 64kb music disk (http://www.pouet.net/prod.php?which=7416). It's track four which is the soundtrack of fr-010 which a cover of the famour Sanxion tune by Rob Hubbard. Encoded at 256kbps the final bitrate is 378kbps and bitrate is always near 400kbps, except the intro passage. Encoded with this new 320kbps setting (using unconstrained VBR) it ends up at 420kbps.
I will do a test anyway but i thought to share my thinking here so you might be able to say if i'm doing stupid things
Yes, the samples which contain transients should benefit from use of a shorter frames.
Have tried this sample. http://www.rarewares.org/test_samples/velvet.wv (http://www.rarewares.org/test_samples/velvet.wv)
From best to worst: 5 ms, 10 ms, 20 ms, 2.5 ms.
Though there is a side effect as some distortion in low frequency range, not that noticeable on 10 ms, somewhat on 5 ms and clearly audible on 2.5 ms. A good solution can be variable/adaptive frame size. A good implementation of variable frame size would be most optimal for all kind of signals.
Though there is a side effect as some distortion in low frequency range, not that noticeable on 10 ms, somewhat on 5 ms and clearly audible on 2.5 ms.
Is this even true for such high bitrate encode modes like --vbr 320 --framesize 5 I've described? Can you notice low frequency distortion even at this setting?
A variable frame length capable encoder would be really good but the BABYEATER build sadly came out as a dead end I hope there's still some way to resurrect this feature.
darkbyte,
I'll try higher bitrate tommorow or so.
Here's the log of 128 kbps. http://pastebin.com/Z3UbLiSm (http://pastebin.com/Z3UbLiSm)
I'll try higher bitrate tommorow or so.
Thanks! I'm curious. Based on your test --framesize 10 seems to be a good choice on mid range bitrates (~128-160kbps)
After some additional tests on Velvet sample I can say that 5/10/20 ms have similar performance at 160 kbps. It's very hard to prefer one of them as they all do pretty good.
And all 5/10/20 ms frame sizes were transparent at 192 kbps. At least it will require very critical listening to spot some artifacts there.
Except 2.5 ms which still had low frequency distortion on bass drum at 160-192 kbps.