HydrogenAudio

Lossy Audio Compression => Opus => Topic started by: jmvalin on 2011-02-04 16:36:30

Title: IETF Opus codec now ready for testing
Post by: jmvalin on 2011-02-04 16:36:30
We'd like to announce that the Opus codec is now ready for testing. The bit-stream is now is a "pseudo-freeze", which means that unless a problem is found during testing/review, there are no longer any changes planned. The only exception to this are the SILK-mode FEC and the stereo SILK mode, which should be landing in the next few days. Considering that these are not critical features, we felt like the testing phase could already begin.

You can get the source code in two different ways. There is a release tarball at http://jmvalin.ca/opus/opus-0.9.0.tar.gz (http://jmvalin.ca/opus/opus-0.9.0.tar.gz) . You can also extract the source directly from the I-D ( http://www.ietf.org/id/draft-ietf-codec-opus-02.txt (http://www.ietf.org/id/draft-ietf-codec-opus-02.txt) ) with the following command:

cat draft-ietf-codec-opus-02.txt | grep '^\ \ \ ###' |
sed 's/\s\s\s###//' | base64 -d > opus_source.tar.gz

Now the Opus codec supports three mores, one of which is identical to CELT 0.11, which was just released (not announced officially yet).

It would be nice if the HA community could help test this codec. Opus targets a very wide range of bit-rates, from 6 kb/s narrowband speech up to 510 kb/s stereo music. Perhaps a 64-96 kb/s stereo music test would be interesting to do. Anyone would like to help?
Title: IETF Opus codec now ready for testing
Post by: mudlord on 2011-05-05 11:33:53
Did some testing....
I noticed one particulary bad sample....

Code: [Select]
foo_abx 1.3.4 report
foobar2000 v1.1.7 beta 1
2011/05/05 20:12:50

File A: E:\music\modules\buzz_rtltune.XM
File B: C:\Users\mud\Desktop\buzz - RTL.tune001  .ogg

20:12:50 : Test started.
20:13:18 : 00/01  100.0%
20:13:31 : 01/02  75.0%
20:14:32 : 02/03  50.0%
20:14:57 : 03/04  31.3%
20:15:47 : 04/05  18.8%
20:16:06 : 05/06  10.9%
20:17:49 : 06/07  6.3%
20:18:00 : 07/08  3.5%
20:18:07 : 08/09  2.0%
20:18:20 : 09/10  1.1%
20:18:27 : 10/11  0.6%
20:19:02 : 11/12  0.3%
20:19:09 : 12/13  0.2%
20:19:17 : 13/14  0.1%
20:19:25 : 14/15  0.0%
20:19:33 : 15/16  0.0%
20:19:46 : 16/17  0.0%
20:20:04 : 17/18  0.0%
20:20:12 : 18/19  0.0%
20:20:20 : 19/20  0.0%
20:20:27 : 20/21  0.0%
20:20:30 : Test finished.

----------
Total: 20/21 (0.0%)


Bitrate is 96kbps.

Note that the OGG file is indeed encoded with CELT, and a packet decoder was used in FB2K for native CELT playback and ABXing. Can't give a link to the packet decoder yet as its still pre-alpha and its Peter's work, too.

Since the XM file is public, I don't see the harm in posting a complete sample and the original XM file.
Original file: http://mudlord.emuxhaven.net/buzz_rtltune.XM (http://mudlord.emuxhaven.net/buzz_rtltune.XM)
CELT: http://mudlord.emuxhaven.net/buzz_rtltune.ogg (http://mudlord.emuxhaven.net/buzz_rtltune.ogg)

On the cymbals, there is a noticable volume difference, not sure how to describe it, but it seems sure as hell as a artifact.
Used the most recent foo_dumb component for the original XM.
Title: IETF Opus codec now ready for testing
Post by: mudlord on 2011-05-07 15:01:10
Peter fixed this, now cant ABX the samples.
Issue with decoder end.
Title: IETF Opus codec now ready for testing
Post by: Tom Servo on 2011-06-19 00:46:48
Sorry for looking like a tool for asking this, but with support for up to 500kb/s bitrate for music, does that mean that CELT/Opus is also going to be positioned into regular audio-to-file encoding like MP3 and AAC?
Title: IETF Opus codec now ready for testing
Post by: NullC on 2011-07-27 20:04:08
Sorry for looking like a tool for asking this, but with support for up to 500kb/s bitrate for music, does that mean that CELT/Opus is also going to be positioned into regular audio-to-file encoding like MP3 and AAC?


The encoder (and tools) will need to mature some, of course, but yes: It's suitable for stored file usage too. That wasn't an original goal, but we kept pushing the quality envelope to the point where this is a realistic application of the codec.
Title: IETF Opus codec now ready for testing
Post by: mudlord on 2011-09-04 23:13:28
Oh, since your here, did jmvalin add the resampler yet?
Title: IETF Opus codec now ready for testing
Post by: romor on 2011-09-04 23:44:19
subscribe (http://git.xiph.org/?p=opus.git;a=rss)?
Title: IETF Opus codec now ready for testing
Post by: mudlord on 2011-09-05 12:58:21
ah yes, just noticed that, opusenc includes the resampler.
Yay.
Title: IETF Opus codec now ready for testing
Post by: FreaqyFrequency on 2011-10-13 16:04:55
I'll go ahead and bump this thread as well, while we're talking about it in a different thread. 

Have we heard any more news from anyone on this front?  Hopefully we're nearing bitstream freeze, assuming most of the issues have been fleshed out and dealt with.
Title: IETF Opus codec now ready for testing
Post by: Speckmade on 2011-11-26 14:05:33
The codec's featureset sounds as if it could be a promising candidate for a new free standard for lossy audio to follow the beloved Vorbis codecs. Therefore I wonder if it is in principle possible to use it for multichannel audio (e.g. 5.1 channel movie audio).?. Can there be an encoder for multichannel stuff in the future?
Title: IETF Opus codec now ready for testing
Post by: FreaqyFrequency on 2011-11-27 03:57:27
I'm hoping that Opus will be used more widely as a VoIP codec (since low latency necessarily means compromising coding efficiency anyway), and that xiph's new brainchild Ghost will be what replaces Vorbis for music archival.  So I'd be more okay with Ghost getting the multichannel support over Opus, so long as Ghost comes along, that is.

I'm very tempted to try to learn more about coding just to try to lend my own hand to the process in whatever way possible.
Title: IETF Opus codec now ready for testing
Post by: greensdrive on 2011-11-27 15:20:50
I was under the impression that low latency usually (if not always) means higher quality.  just an impression I got.

a couple days ago, I compiled opusenc/opusdec, and apparently they plan multichannel for Opus.  I thought this because of the --bitrate option being "6-256 per-channel".  more on target, commit 6dd8086d (http://git.xiph.org/?p=users/greg/opus-tools.git;a=commit;h=6dd8086d4d1bed7dcd5948651d24649809f90e1f) in users/greg/opus-tools.git says "First cut at working multichannel support".
Title: IETF Opus codec now ready for testing
Post by: Speckmade on 2011-11-28 02:11:43
I'm hoping that Opus will be used more widely as a VoIP codec (since low latency necessarily means compromising coding efficiency anyway), and that xiph's new brainchild Ghost will be what replaces Vorbis for music archival.  So I'd be more okay with Ghost getting the multichannel support over Opus, so long as Ghost comes along, that is.

In fact, Opus is one of the outcomes of the Ghost project - next to Monty's plans that'll maybe stay in a state that may not even be called proper vaporware.
Opus is what we've got, and it's damn good. The compromised quality is speculation - look at the facts: The prototypes clearly beat HE-AAC, less complexity and more efficiency than Vorbis, competitive on a much broader bitrate range, official recommendation as an internet standard, probably it'll also be endorsed by the ITU - and on top of all that the super-low latency, specialised speech mode built-in - what else could I wish for? Also, you can kind of "turn off" the low latency: Have you noticed that you can turn up the block size to almost 60 ms?..

a couple days ago, I compiled opusenc/opusdec, and apparently they plan multichannel for Opus.  I thought this because of the --bitrate option being "6-256 per-channel".  more on target, commit 6dd8086d (http://git.xiph.org/?p=users/greg/opus-tools.git;a=commit;h=6dd8086d4d1bed7dcd5948651d24649809f90e1f) in users/greg/opus-tools.git says "First cut at working multichannel support".

Given the VoIP background, where monaural audio is still predominant, could it be that "multichannel" means no more than stereo? I've never heard them speak of something beyond...
Title: IETF Opus codec now ready for testing
Post by: greensdrive on 2011-11-28 03:46:17
could it be that "multichannel" means no more than stereo? I've never heard them speak of something beyond...

no.  I have since deleted my compiles, but looking at the source code (at line 127 of opusenc.c in Gregory Maxwell's opus-tools.git):
Code: [Select]
--downmix-stereo   Downmix to to stereo (if >2 channels)

note that it's "greater than two channels"...  I didn't test this, though.

also (line 116 and 117 of the same file):
Code: [Select]
--speech           Optimize for speech
--music            Optimize for music

so I assume that xiph.org is not making this for spoken-only environments.  in other words, it may have a speech background, but they are creating space for music intentions as well.
Title: IETF Opus codec now ready for testing
Post by: Speckmade on 2011-12-01 00:55:37
could it be that "multichannel" means no more than stereo?

no.

Oh, nice, thanks. - I'm happy to hear that! :-)
Title: IETF Opus codec now ready for testing
Post by: NullC on 2011-12-01 03:08:59
Opus is what we've got, and it's damn good. The compromised quality is speculation - look at the facts: The prototypes clearly beat HE-AAC, less complexity and more efficiency than Vorbis, competitive on a much broader bitrate range, official recommendation as an internet standard, probably it'll also be endorsed by the ITU - and on top of all that the super-low latency, specialised speech mode built-in - what else could I wish for? Also, you can kind of "turn off" the low latency: Have you noticed that you can turn up the block size to almost 60 ms?..


I don't know so much about less complexity.  In the MDCT modes our encoder is quite low complexity compared to typical codecs for lossy music (e.g. Vorbis / AAC / HE-AAC), yes.  For communications purposes you need both an encoder and a decoder, so we've traded a bit there— the decoder is more complex though it needs much less memory, so in practice its easier to implement the decoder on many small devices than Vorbis. (And especially les than the "worst case" vorbis decoder, which needs something like 32mbytes of ram).

Don't hold your breath on an ITU endorsement. The ITU both officially, and via their participants has opposed the process, though perhaps there will be some kind of reversal after the fact. The politics have been extensive and have substantially delayed the finalization of the codec (but thats okay, we put the time to good use squashing bug in the silk stuff)... and perhaps some day I'll get to write a political intrigue novel about all the crazy nonsense that has gone on with people trying their best to block/slow the process.

Turning up the size to 60ms doesn't really matter much except at very low bitrates: It only saves a few bytes from some better prediction and eliminating a bit of overhead.
(and, in fact, there is a bug in the currently released encoder that prevents high bitrates for 40/60ms frames, though the fix which is in my tree should be merged within a few days)

We couldn't have 'real' large frames without doubling the worst case memory usage— and just adding them wouldn't actually help much because of all the other design decisions centered around low latency/small frame sizes. At one point I switched to 2k frames and wasn't able to get it to sound good in a couple hours of twiddling. (And, in fact, at very high rates I've seen some evidence that our 10ms frames may be generally better than the 20ms ones for many signals. Future encoders will likely do smart things with automatic frame size selection)

In any case, the only samples that we seem to really suffer from the small transform size is are highly tonal frames with irregular tonality (e.g. harpsichord). These are rare enough that for unconstrained VBR users (the same people who wouldn't mind a codec with 100ms delay, I assume) we can just detect and boost the rate for these frames.  Jean-marc has a branch that does this. The results are quite impressive. I expect the hydrogen audio folks to be quite pleased.

Quote
Given the VoIP background, where monaural audio is still predominant, could it be that "multichannel" means no more than stereo? I've never heard them speak of something beyond...


As noted, this is actual surround support.  Opus will never be an awesome low-rate surround codec: our coupling model is too limited— and the limits are fundamental. But it's well defined for the sake of being One Codec To Rule Them All.  Then again, it seems all the rage in surround coding is this parametric stuff and, personally, I think all the parametric stereo/surround I've heard sounds like crap.  I'd prefer mono audio to motion sickness kthnx.

The opus-tools in my repository is fairly raw at this point but I'd like to get it up to initial release grade soon. I'm trying to balance time between working on that and on the codec.  It would be helpful to me for some people to try it out and give me feedback.  (I know opusdec gets the output channel order wrong, before anyone reports that — I haven't finished the multichannel work there yet).

There is also ffmpeg and gstreamer support in the works.  The container support should be final now, but I'm not prepared to call it final until I've done interoperability testing with multiple implementations. If anyone is working on support in applications please join #opus on freenode. (There is a web client on the opus-codec webpage, of course everyone else is welcome too).
Title: IETF Opus codec now ready for testing
Post by: IgorC on 2011-12-01 14:44:44
Speaking about complexity the things are changing quickly. iPad can play LCAAC during 140 hours or  HEAAC v2 during approx. 60 hours. Eventuallty display consumes much more so anyway a user will run out of battery much more faster.

During last 2 years there was a big break trough for energy efficiency. It's not surprise that embedded and mobile devices can  handle decoding of  OptimFrog slowest mode (HD video, etc).
Title: IETF Opus codec now ready for testing
Post by: punkrockdude on 2012-01-15 10:45:35
Will the CELT encoder accept 24 bit wav files? I am for fun trying out how different lossy encoders manages 24 bits audio. Regards.
Title: IETF Opus codec now ready for testing
Post by: Caroliano on 2012-01-20 04:48:56
I saw the IETF draft, and, as expected, the final word on the specification will be reference implementation itself. I suppose that it means that, like VP8 and others, any bug or quirky platform dependent behavior in the reference implementation will become the standard itself. This is specially worrying because SILK was closed source for a long time.

So, I would like to know if the IEFT specification was tested. That is: if someone has tried to write at least a decoder based on it. I haven't found any other opus implementation besides the reference one. You guys maybe should talk with ffmpeg/libav people, that will probably write their own opus implementation sooner or latter anyway, to do that. They may even give some useful advice on the codec specification.

And is there any plans for an "Opus-HD" (high delay) in the future? 

Or the low-delay design is too fundamental to the codec design, and some additional bigger window overlaps and frame sizes will be too difficult to implement/not make enough difference? I guess that with the economy in signaling bits, there is no bits left to extend the codec... right?

Anyway, Opus is looking great as it is. I hope to see it everywhere soon! 
Title: IETF Opus codec now ready for testing
Post by: rillian on 2012-01-23 22:49:43
So, I would like to know if the IEFT specification was tested. That is: if someone has tried to write at least a decoder based on it.


Tim Terriberry has written an alternate implementation. As I understand it, this is based on reading the reference code, and then trying to implement the same ideas in a different way. The CELT side works; the SILK side is close, but doesn't yet pass all the compliance tests.

So there are two independent implementations, even if one of them is actually the spec.
Title: IETF Opus codec now ready for testing
Post by: NullC on 2012-01-23 23:28:55
I saw the IETF draft, and, as expected, the final word on the specification will be reference implementation itself. I suppose that it means that, like VP8 and others, any bug or quirky platform dependent behavior in the reference implementation will become the standard itself. This is specially worrying because SILK was closed source for a long time.


The silk part of the codebase has seen a year and a half of open source development along with substantial rewriting and many boneheaded mistakes being fixed by the original developers and the folks from the CELT development team as well as other participants. The silk part of bitstream isn't even remotely compatible with the original due to the fixes, redesigns, etc.

Quirky platform dependent behavior was minimized by concurrent development on many platforms, and by simply producing a completely portable implementation. (Though, admittedly the silk code is influenced by the fast operators on ARM— though I don't think anyone would find much reason to complain about that— and its no accident).

Quote
So, I would like to know if the IEFT specification was tested. That is: if someone has tried to write at least a decoder based on it. I haven't found any other opus implementation besides the reference one. You guys maybe should talk with ffmpeg/libav people, that will probably write their own opus implementation sooner or latter anyway, to do that. They may even give some useful advice on the codec specification.


Tim has written an almost complete no-code-sharing reimplementation of the format (http://people.xiph.org/~tterribe/celt/opus...03-float.tar.gz (http://people.xiph.org/~tterribe/celt/opusdec-0.003-float.tar.gz)), which in many places was designed to be maximally different in approach from the reference in order to validate that the implementation flexibility which we believed was there was actually there.

The MDCT (formally CELT modes) have been complete in it for a long time— almost a year— the LP/hybrid parts of it were only recently written and still have some cases incomplete.  The reimplementation discovered a number of erroneous behaviors of the sort you're concerned about, and they've been corrected.

We asked the libav folks in the past and didn't get much interest— moreover, after working with their libvorbis implementation to fix some non-conformance a year or so ago, I think that if Opus was done in the same style it wouldn't provide a lot of spec validating reimplementation value,  since a lot of the code was clearly copied from libvorbis and then just modified to meet libav conventions. (I don't say this to begrudge their efforts, they did a good job speeding up some parts— and the fact that it line for line duplicates libvorbis made it much easier to track down some cases where their type conversions caused overflows)

The reference implementation of Opus is also itself a bit more like one and a quarter implementations— because it includes both fixed and floating point (though with a healthy amount of code sharing).

The presentation from IETF 82 covers many of the things we did for testing, specifically with these concerns in mind http://www.ietf.org/proceedings/82/slides/codec-4.pdf (http://www.ietf.org/proceedings/82/slides/codec-4.pdf)

A point here is that the style of "the spec is not code" also means "the spec is not executable" which also means "the spec itself can never be completely tested", in those cases all you can do is test some implementations of the spec and hope that bugs in the spec carried through rather than being identically fixed by accident by the implementers.  If it were to turn out that the implementations and spec did not agree, what would you do? "Fix" the implementations thus breaking the interoperability which is the whole point of a standard? or "Fix" the spec? which would really imply that the implementations were really the real specification all along.  I'd argue that the value is in having multiple implementations, not in having the description of what the code should be doing in a form so precisely that someone could implement it cold but not precise or formal enough for it to be actually be executable itself.  And we have evidence from multiple implementations— though it would be nice to have had more of it.

(In some hypothetical ideal world of unbounded resources, I'd love to have had a team writing a formal specification in Coq from which an executable version could be mechanically extracted and compared to a practical implementation— a solution which would address many concerns, but sadly on the list of priorities that kind of resource investment falls below many other things, below improving perceptual quality, below patent clearance auditing, below QA on the code that millions of people will actually be running and with which interop will be essential no matter what the spec says, etc)

Quote
And is there any plans for an "Opus-HD" (high delay) in the future? 

Or the low-delay design is too fundamental to the codec design, and some additional bigger window overlaps and frame sizes will be too difficult to implement/not make enough difference? I guess that with the economy in signaling bits, there is no bits left to extend the codec... right?


No, no plans for high delay.  There is plenty of room to improve things via a smarter encoder while remaining compatible.  I don't see any value in incompatible extensions— if we're going to be incompatible we can do much better by throwing things out and without the low delay assumptions we'd do some things quite differently.
Title: IETF Opus codec now ready for testing
Post by: bawjaws on 2012-03-16 13:47:29
The presentation from IETF 82 covers many of the things we did for testing, specifically with these concerns in mind http://www.ietf.org/proceedings/82/slides/codec-4.pdf (http://www.ietf.org/proceedings/82/slides/codec-4.pdf)


As someone who is occasionally depressed by the half-assery that often passes for software development, that's an inspiring document. Someday (hopefully soon) all standards work will be done like this.
Title: IETF Opus codec now ready for testing
Post by: .alexander. on 2012-03-27 14:14:44
CELT/OPUS has been designed before 2/06/12 and I'm curious does it have any advantages over iSAC?
Title: IETF Opus codec now ready for testing
Post by: NullC on 2012-04-10 00:29:19
CELT/OPUS has been designed before 2/06/12 and I'm curious does it have any advantages over iSAC?


I'm not aware of any good listening tests — just going from the design I expect opus to outperform iSAC at iSAC's bitrate's, but a comparison would be interesting to see. The ex-gips folks from Google spoke pretty highly of Opus to me, though perhaps they were just being polite.

Beyond that, Opus scales to (near-) perceptual transparency while iSAC doesn't even support a high enough sampling rate for transparency. Opus supports much lower latencies (down to 5ms, vs ~33ms or so).  Opus was developed with a public open and transparent process, while iSAC is a formerly proprietary codec which appears to have royalty free licensing which is limited to webrtc use.  For what iSAC does they may be fairly close, but Opus is just a lot more versatile.
Title: IETF Opus codec now ready for testing
Post by: polemon on 2012-05-04 14:42:27
Can we have some updates about OPUS? there isn't much info on the opus-code.org page. In fact, it seems pretty stagnant. Maybe on a technology readiness level or something?

The last thing I've seen was the presentation about OPUS. I was looking through the IETF website (some links seem dead from the tread post), but even there seems to be close to no changes.

The only sign of changes and therefore activity, was the change date of this document: http://datatracker.ietf.org/doc/draft-ietf-codec-opus/ (http://datatracker.ietf.org/doc/draft-ietf-codec-opus/)
On the history table ( http://datatracker.ietf.org/doc/draft-ietf...c-opus/history/ (http://datatracker.ietf.org/doc/draft-ietf-codec-opus/history/) ) it seems, the codec is somewhat in an idle state, waiting for approval from other departments.

The reason why I'm asking about updates, is because there is very little discussions going on about using OPUS being used as archiving codec. I know the codec is designed to be an interactive codec, for VoIP and the likes, but the presentation that I've been watching, suggested that it is also very capable of creating transparent results at lower bitrates than Vorbis is even AAC. So, does OPUS make sense as archiving codec for music collections? I haven't found any documents discussing this.
Title: IETF Opus codec now ready for testing
Post by: bawjaws on 2012-05-21 14:38:15
Can we have some updates about OPUS? there isn't much info on the opus-code.org page. In fact, it seems pretty stagnant. Maybe on a technology readiness level or something?

The last thing I've seen was the presentation about OPUS. I was looking through the IETF website (some links seem dead from the tread post), but even there seems to be close to no changes.

The only sign of changes and therefore activity, was the change date of this document: http://datatracker.ietf.org/doc/draft-ietf-codec-opus/ (http://datatracker.ietf.org/doc/draft-ietf-codec-opus/)
On the history table ( http://datatracker.ietf.org/doc/draft-ietf...c-opus/history/ (http://datatracker.ietf.org/doc/draft-ietf-codec-opus/history/) ) it seems, the codec is somewhat in an idle state, waiting for approval from other departments.

The reason why I'm asking about updates, is because there is very little discussions going on about using OPUS being used as archiving codec. I know the codec is designed to be an interactive codec, for VoIP and the likes, but the presentation that I've been watching, suggested that it is also very capable of creating transparent results at lower bitrates than Vorbis is even AAC. So, does OPUS make sense as archiving codec for music collections? I haven't found any documents discussing this.


I think the main developers are focused on getting it published by the IETF so it's all about getting the spec documentation polished up. But because they are at that stage I also believe this means the decoder is 99.9% done and isn't going to change.

The encoder on the other hand, is designed to be improvable even after the decoder is fixed, so I'd guess you might soon see further improvements around the time the spec gets publicised as "done", either because of renewed external interest or because the main developers have more time to work on that side of things.

But I'd guess, at least at first, they'll be aiming for the areas where Opus is fairly unique and has big advantages and building on that, rather than spending time taking on MP3 and AAC on their home turf. I'd guess any improvement in that domain will most likely be a by-product of other work.
Title: IETF Opus codec now ready for testing
Post by: IgorC on 2012-05-21 21:16:35
Yes, encoder has a big room for improvements.
Some ABC/HR results  for experimental branch (exp4) at 64 kbps http://git.xiph.org/?p=opus.git;a=shortlog.../heads/exp_wip4 (http://git.xiph.org/?p=opus.git;a=shortlog;h=refs/heads/exp_wip4)

CELT 0.11.2 - 3.08
exp4 (20120503) - 3.22

(http://i47.tinypic.com/8zqomg.png)

Code: [Select]
CELT_0.11.2   exp4
2,0          3,2
1,1          3,0
4,7          3,7
3,8          2,8
3,4          3,2
2,7          2,8
3,4          4,0
2,5          4,5
2,9          4,0
3,7          3,7
2,3          3,2
3,5          2,8
3,0          2,7
3,3          3,0
4,3          4,0
3,3          2,5
1,5          3,2
3,0          3,2
2,7          3,0
3,4          3,0
4,0          3,8
3,6          2,8
3,6          2,7
4,0          2,8
3,0          3,0
1,0          2,7
3,5          3,5
2,0          3,7
3,2          2,7
4,0          3,4
Mean
3,08       3,22
Title: IETF Opus codec now ready for testing
Post by: 2012 on 2012-05-22 12:26:35
Indivisual/Average bitrates would have been great so we can have the full picture.
Title: IETF Opus codec now ready for testing
Post by: IgorC on 2012-05-22 14:05:30
Bitrate calibration was done on 45 tracks of different musical genres.
Encoder - Settings - Average bitrate:
CELT 0.11.2 - complexity 10, VBR 67.5 kbps  -  66.3 kbps
Exp4  - complexity 10, VBR 61 kbps - 66.7 kbps


Average bitrate on tested samples:
CELT 0.11.2 - 66.6 kbps
exp4 - 66.9 kbps


All 30 tested original samples were concatenated into one file and resampled by SSRC resampler with highest quality settings (Ultra mode)  44.1 kHz -> 48 kHz.  Then these files (48 kHz) were encoded by tested encoders.
If You want to reproduce an individial bitrates You can get original files from here http://www.hydrogenaudio.org/forums/index....st&p=749742 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=87785&view=findpost&p=749742)
Title: IETF Opus codec now ready for testing
Post by: 2012 on 2012-05-22 15:00:44
Thanks.
Title: IETF Opus codec now ready for testing
Post by: NullC on 2012-05-24 04:49:45
Can we have some updates about OPUS? there isn't much info on the opus-code.org page. In fact, it seems pretty stagnant. Maybe on a technology readiness level or something?
The last thing I've seen was the presentation about OPUS. I was looking through the IETF website (some links seem dead from the tread post), but even there seems to be close to no changes.
[...]
The reason why I'm asking about updates, is because there is very little discussions going on about using OPUS being used as archiving codec. I know the codec is designed to be an interactive codec, for VoIP and the likes, but the presentation that I've been watching, suggested that it is also very capable of creating transparent results at lower bitrates than Vorbis is even AAC. So, does OPUS make sense as archiving codec for music collections? I haven't found any documents discussing this.


First—  You're aware of http://opus-codec.org/ (http://opus-codec.org/)  Right? 

You're correct that the main focus right now is on getting the standard published, so most commits (http://git.xiph.org/?p=opus.git;a=shortlog) are related to that.

There is an experimental branch with some pretty substantial (see posts above by IgorC) encoder perceptual enhancements— mostly serving the purpose of actually taking advantage of VBR... but other than fixing some regressions not a lot has happened with it lately.  Right now the Xiph team is splitting resources between Opus and our new video codec work... and just shepherding the format through the IETF is itself a lot of work.

That said— file based usage is absolutely a priority for the time of the 1.0 release (which will happen along with publication of the standard).  I've been spending time getting opus-tools (http://git.xiph.org/?p=users/greg/opus-tools.git),  a set of simple command-line tools for encoding/decoding Opus in fixed files, ready for an initial official release— hopefully this coming weekend.  I would _really_ appreciate testing and feedback, and if people need windows binaries made for testing, please let me know and I'd be glad to build some.

And the biggest news on this front is that we have support in Firefox (https://people.xiph.org/~giles/2012/opus/), in the audio tag.  It's only in the 'nightly' versions now and is preferences off and has a couple bugs, but it generally works great.  This means that fairly rapidly after Opus' release the files will be playable on a significant fraction of desktop PCs— the browser is not exactly an ideal audio-player but compatibility is important..

There are a lot of things that need to be done (this list is far from inclusive) (https://wiki.xiph.org/OpusRelease) for the big 1.0 release, and if Opus interests you please come lend a hand (the easiest way to join in is via the IRC channel that you can reach through the Opus website).
Title: IETF Opus codec now ready for testing
Post by: NullC on 2012-05-28 01:22:09
For any Windows users who are waiting on binaries to play around with Opus, I've prepared a binary build of opus-tools.
Feedback would be greatly appreciated.  (I'm interested in if "opusdec.exe file.opus"  plays audio on real windows systems, or if it only works in wine). I especially want to hear any bug reports or critical missing features.

https://people.xiph.org/~greg/opus-tools.zip (https://people.xiph.org/~greg/opus-tools.zip)

As we approach the official release I'll get automated builds setup for opus and the exp4 tuning branches.

If anyone is interested in building a GUI oggdrop style tool for encoding Opus, perhaps just a GUI front end on opusenc, I think it would be very useful to people— if it's portable to *nix I'll help out (at least with review and testing), but I don't have the time free to drive the development myself.
Title: IETF Opus codec now ready for testing
Post by: kode54 on 2012-05-28 02:30:20
Plays audio on my Windows 7 system. Also decodes these Opus tracks I encoded back in January, using the exp_wip3 branch, but I guess nothing has been broken since then.
Title: IETF Opus codec now ready for testing
Post by: mdefranc on 2012-05-28 05:12:11
Works on my Vista system, as well.
Title: IETF Opus codec now ready for testing
Post by: Gainless on 2012-05-28 12:53:43
Can someone explain how to use the command line decoder without Foobar? Atm I don't even know how to open the decoder properly in Windows...

Edit: Ok, got to work it right now.
Title: IETF Opus codec now ready for testing
Post by: dr.schanker on 2012-05-28 15:38:39
Works fine under WindowsXP SP3 32bit. However, i found 2 issues:

1) Channel order (multichannel files)
The channel order may be incorrect for multichannel files. Feeding the encoder WAVEFORMAT_PCM (no channelmask) and WAVEFORMAT_EXTENSIBLE (channelmask) makes no difference. I have no idea if this is an encoder or decoder issue, the .wav files were analyzed with Audacity/foobar2000.

Channelnumber - Source WAV - Opus->WAV
1 - FL - FL
2 - FR - FC
3 - FC - FR
4 - LFE - SL
5 - SL - SR
6 - SR - LFE

Example files: Source WAV (http://www.mediafire.com/download.php?7bnfifwc5211rwo) / Opus (http://www.mediafire.com/download.php?hh909u99erjpelp) / Decoded Opus->WAV (http://www.mediafire.com/download.php?1dq29pl12dgl2t9) / Six mono .wav files for custom testing (http://www.mediafire.com/download.php?roxr2nei5fldkz4)

2) Piping audio


Title: IETF Opus codec now ready for testing
Post by: naturfreak on 2012-05-28 16:25:32
@dr. schanker
The Opus codec does not support multichannel audio, only mono and stereo ist supported.
Title: IETF Opus codec now ready for testing
Post by: zerowalker on 2012-05-28 17:27:16
How can i get a compiled encoder of this codec:)?
Would really like to try it out, as if it´s from the vorbis ppl, i am quite excited of it:)
Title: IETF Opus codec now ready for testing
Post by: dr.schanker on 2012-05-28 21:11:40
@dr. schanker
The Opus codec does not support multichannel audio, only mono and stereo ist supported.

The encoder accepted the linked multichannel .wav just fine. It even checked the channelmask in another testfile (WAVEFORMAT_EXTENSIBLE .wav) and changed channelorder (SL/SR remapped to RL/RR). I understand that mono/stereo has a higher priority and may be more polished codewise, but wanted to point out the multichannel issues anyway.
Title: IETF Opus codec now ready for testing
Post by: NullC on 2012-05-29 07:49:03
@dr. schanker
The Opus codec does not support multichannel audio, only mono and stereo ist supported.


Multichannel absolutely is supported. 

I'll take care of the encoder issues that Dr. schanker found— I'd hoped to avoid issues with wav reading by using the oggenc input code, and stdin does work and has been extensively tested— in the two channel case.    Edit:  Can you get me your test.wav, as well as the output of the ffmpeg pipe redirected to a file?  I'm unable to reproduce the issue piping from ffmpeg here. Works fine for me.

Opusdec's multichannel order absolutely is broken, known limitation at the moment. I was hoping someone to change the output in opusdec to use libao and so I didn't touch it— but that hasn't happened in time, as I really needed to get something in people's hands.  Thank you so much for the feedback.

How can i get a compiled encoder of this codec:)?
Would really like to try it out, as if it´s from the vorbis ppl, i am quite excited of it:)


It's linked above— https://people.xiph.org/~greg/opus-tools.zip (https://people.xiph.org/~greg/opus-tools.zip)
Title: IETF Opus codec now ready for testing
Post by: naturfreak on 2012-05-29 10:38:32
Multichannel absolutely is supported.

Hmm. Ok. (But) I haven't seen a word about multichannel audio in the specification doc of Opus. Only mono and stereo are mentioned there.
Title: IETF Opus codec now ready for testing
Post by: bawjaws on 2012-05-29 10:42:13
If anyone is interested in building a GUI oggdrop style tool for encoding Opus, perhaps just a GUI front end on opusenc, I think it would be very useful to people— if it's portable to *nix I'll help out (at least with review and testing), but I don't have the time free to drive the development myself.


As Firefox can encode Opus (at least I assume it will soon for WebRTC uses), and decode WAV (and Ogg), and supports drag and drop of files,  you might cover a fair bit of ground with a (relatively) simple Firefox extension (or even a webpage?). There's also the example of the Firefogg extension, but I think that includes ffmpeg  for decoding various formats which makes it a bit more ambitious.

Integrating Javascript decoders for FLAC and ALAC would also score extra cool points.
Title: IETF Opus codec now ready for testing
Post by: dr.schanker on 2012-05-29 20:18:04
The inputfile: "test_wav.7z" (5 MB) (http://www.mediafire.com/download.php?cp08k822qw2mq3n)
The piped data: "test_piped_bin.7z" (5 MB) (http://www.mediafire.com/download.php?ihgg25zzogvj4wb)
I used the commandline: ffmpeg.exe -i "test.wav" -f wav - 1>"test_piped.bin"
As suspected, the difference between both is that the piped file has the value 0 for RIFF and Data chunksize.

Bonus content  :  the used ffmpeg binaries "ffmpeg-20120525-git-e02e58f-win32-static.7z" (16 MB) (http://www.mediafire.com/download.php?zg48z5gtd5x1uyt) / a screenshot video "opusenc_crash_ffmpeg_pipe.mp4" (1 MB) (http://www.mediafire.com/download.php?l2j0bleob54et53)
Title: IETF Opus codec now ready for testing
Post by: NullC on 2012-05-30 21:23:42
The inputfile: "test_wav.7z" (5 MB) (http://www.mediafire.com/download.php?cp08k822qw2mq3n)
The piped data: "test_piped_bin.7z" (5 MB) (http://www.mediafire.com/download.php?ihgg25zzogvj4wb)
I used the commandline: ffmpeg.exe -i "test.wav" -f wav - 1>"test_piped.bin"
As suspected, the difference between both is that the piped file has the value 0 for RIFF and Data chunksize.

Bonus content  :  the used ffmpeg binaries "ffmpeg-20120525-git-e02e58f-win32-static.7z" (16 MB) (http://www.mediafire.com/download.php?zg48z5gtd5x1uyt) / a screenshot video "opusenc_crash_ffmpeg_pipe.mp4" (1 MB) (http://www.mediafire.com/download.php?l2j0bleob54et53)


I take it if you type test_piped.bin | ./opueenc.exe - output.opus    that works okay for you?

The closest I can come to reproducing is running with
wine /tmp/bin/ffmpeg.exe -i "test.wav" -f wav -  | wine ./opusenc.exe - /dev/null
which results in opusenc sleeping forever on an fread().

May just be some kind of brokenness with pipes in windows that I'm clueless about.
Title: IETF Opus codec now ready for testing
Post by: zerowalker on 2012-05-30 22:17:29
did som fast tests after finally getting it to work.
I tried using a Mono recording from a microphone, as -2 Q with ogg vorbis Autov, and 30 bitrate comp 10 on CELT.

I am sure this isn´t the way to test it, but anyway, the Autov version of ogg atleast, won pretty nice, and they both are pretty much the same file size:)

Just a quick test by a beginner, so not telling any facts on the codecs here.
Title: IETF Opus codec now ready for testing
Post by: rt87 on 2012-05-31 05:13:14
a rough test is done here:

test file: vocal only song ("20 - P-01s - Tooshi Douka - Vocal Version.flac")
target bitrate: 44100Hz 48kbps 2ch

convert to wav first (like the upper posts, I'm getting APPCRASH when piping from avconv to opusenc)
Code: [Select]
I:\>avconv -i 20.flac -f wav 20.wav
avconv version v0.8-1900-g0fcf301, Copyright (c) 2000-2012 the Libav developers
  built on May 31 2012 09:22:52 with gcc 4.6.2
Input #0, flac, from '20.flac':
  Duration: 00:01:03.42, start: 0.000000, bitrate: 718 kb/s
    Stream #0.0: Audio: flac, 44100 Hz, stereo, s16
Output #0, wav, to '20.wav':
    Stream #0.0: Audio: pcm_s16le, 44100 Hz, stereo, s16, 1411 kb/s
Stream mapping:
  Stream #0:0 -> #0:0 (ape -> pcm_s16le)
Press ctrl-c to stop encoding
packet size is not a multiple of 4. extra bytes at the end will be skipped.
size=   10938kB time=70.08 bitrate=1278.6kbits/s
video:0kB audio:10938kB global headers:0kB muxing overhead 0.000411%


Ogg Vorbis avTuV b6.02 at same bitrate for reference:
Code: [Select]
I:\>oggenc2 -b 48 20.wav
Opening with wav module: WAV file reader
        [ 99.7%] [ 0m00s remaining] \

Done encoding file "20.ogg"

        File length:  1m 03.0s
        Elapsed time: 0m 01.0s
        Rate:         63.4933
        Average bitrate: 38.4 kb/s


Opus (CELT) command line:
Code: [Select]
I:\>opusenc --music --bitrate 48 --framesize 60 20.wav 20.opus
Encoding using libopus 0.9.11-66-g64c2dd7 (audio)
-----------------------------------------------------
   Input: 44.1kHz 2 channels
  Output: 2 channels (2 coupled)
          60ms packets, 48kbit/sec VBR
Preskip: 356

Encoding complete
-----------------------------------------------------
    Encoded: 1 minute and 3.54 seconds
    Runtime: 2.563 seconds
             (24.8x realtime)
      Wrote: 357387 bytes, 1059 packets, 69 pages
    Bitrate: 44.4888kbit/s (without overhead)
Rate range: 1.06667kbit/s to 72.6667kbit/s
             (8 to 545 bytes per packet)
   Overhead: 1.13% (container+metadata)


When I play 20.opus with opusdec, I can hear some spark sound in the output.
And since there is no good equipment here, the vorbis reference is near transplant to me. 
Title: IETF Opus codec now ready for testing
Post by: LithosZA on 2012-05-31 08:15:10
Quote
I:\>opusenc --music --bitrate 48 --framesize 60 20.wav 20.opus


I might be wrong, but isn't the max framesize for CELT mode 20ms?

>20ms will be SILK mode I think.
Title: IETF Opus codec now ready for testing
Post by: rt87 on 2012-05-31 08:29:41
Quote
I:\>opusenc --music --bitrate 48 --framesize 60 20.wav 20.opus


I might be wrong, but isn't the max framesize for CELT mode 20ms?

>20ms will be SILK mode I think.

OK I retry with --framesize 20 then, but same spark sound appears in same position.

Code: [Select]
I:\>opusenc --music --bitrate 48 --framesize 20 20.wav 20.opus
Encoding using libopus 0.9.11-66-g64c2dd7 (audio)
-----------------------------------------------------
   Input: 44.1kHz 2 channels
  Output: 2 channels (2 coupled)
          20ms packets, 48kbit/sec VBR
Preskip: 356

Encoding complete
-----------------------------------------------------
    Encoded: 1 minute and 3.52 seconds
    Runtime: 3.266 seconds
             (19.45x realtime)
      Wrote: 357503 bytes, 3176 packets, 66 pages
    Bitrate: 44.3879kbit/s (without overhead)
Rate range: 1.2kbit/s to 81.2kbit/s
             (3 to 203 bytes per packet)
   Overhead: 1.42% (container+metadata)
Title: IETF Opus codec now ready for testing
Post by: LithosZA on 2012-05-31 08:33:16
Quote
did som fast tests after finally getting it to work.
I tried using a Mono recording from a microphone, as -2 Q with ogg vorbis Autov, and 30 bitrate comp 10 on CELT.

I am sure this isn´t the way to test it, but anyway, the Autov version of ogg atleast, won pretty nice, and they both are pretty much the same file size:)

Just a quick test by a beginner, so not telling any facts on the codecs here.


If it just was speech then you should try using --speech --framesize 60
Title: IETF Opus codec now ready for testing
Post by: zerowalker on 2012-05-31 17:18:43
Quote
did som fast tests after finally getting it to work.
I tried using a Mono recording from a microphone, as -2 Q with ogg vorbis Autov, and 30 bitrate comp 10 on CELT.

I am sure this isn´t the way to test it, but anyway, the Autov version of ogg atleast, won pretty nice, and they both are pretty much the same file size:)

Just a quick test by a beginner, so not telling any facts on the codecs here.


If it just was speech then you should try using --speech --framesize 60



--speech doesn´t exist, and with framesize 60 it doesn´t encode.


Options:
--bitrate n        Encoding bit-rate in kbit/sec
--cbr              Use constant bitrate encoding
--comp n          Encoding complexity (0-10)
--framesize n      Frame size (Default: 960)
--noltp            Do not use long-term prediction
--independent      Encode frames independently (implies noltp)
--skeleton        Outputs ogg skeleton metadata (may cause incompatibilities)
--comment          Add the given string as an extra comment. This may be
                    used multiple times
--author          Author of this track
--title            Title for this track
-h, --help        This help
-v, --version      Version information
-V                Verbose mode (show bit-rate)
Raw input options:
--rate n          Sampling rate for raw input
--mono            Consider raw input as mono
--stereo          Consider raw input as stereo
--le              Raw input is little-endian
--be              Raw input is big-endian
--8bit            Raw input is 8-bit unsigned
--16bit            Raw input is 16-bit signed
Default raw PCM input is 48kHz, 16-bit, little-endian, stereo
Title: IETF Opus codec now ready for testing
Post by: LithosZA on 2012-05-31 19:13:25
Quote
It's linked above— https://people.xiph.org/~greg/opus-tools.zip (https://people.xiph.org/~greg/opus-tools.zip)
Are you using this one?

Code: [Select]
C:\opus-tools>opusenc.exe
Usage: opusenc [options] input_file output_file.opus

Encodes input_file using Opus. It can read the WAV, AIFF, or raw files.

General options:
 -h, --help        This help
 -v, --version      Version information
 --quiet            Quiet mode

input_file can be:
  filename.wav      file
  -                stdin

output_file can be:
  filename.opus    compressed file
  -                stdout

Encoding options:
 --speech          Optimize for speech
 --music            Optimize for music
 --bitrate n.nnn    Encoding bitrate in kbit/sec (6-256 per channel)
 --vbr              Use variable bitrate encoding (default)
 --cvbr            Use constrained variable bitrate encoding
 --hard-cbr        Use hard constant bitrate encoding
 --comp n          Encoding complexity (0-10, default: 10)
 --framesize n      Maximum frame size in milliseconds
                      (2.5, 5, 10, 20, 40, 60, default: 20)
 --expect-loss      Percentage packet loss to expect (default: 0)
 --downmix-mono    Downmix to mono
 --downmix-stereo  Downmix to stereo (if >2 channels)
 --max-delay n      Maximum container delay in milliseconds
                      (0-1000, default: 1000)

Diagnostic options:
 --save-range file  Saves check values for every frame to a file
 --set-ctl-int x=y  Pass the encoder control x with value y (advanced)
                      Preface with s: to direct the ctl to multistream s
                      This may be used multiple times
 --uncoupled        Use one mono stream per channel

Metadata options:
 --comment          Add the given string as an extra comment
                      This may be used multiple times
 --artist          Author of this track
 --title            Title for this track

Input options:
 --raw              Raw input
 --raw-bits n      Set bits/sample for raw input (default: 16)
 --raw-rate n      Set sampling rate for raw input (default: 48000)
 --raw-chan n      Set number of channels for raw input (default: 2)
 --raw-endianness n 1 for bigendian, 0 for little (defaults to 0)
Title: IETF Opus codec now ready for testing
Post by: punkrockdude on 2012-05-31 20:27:08
I can't seem to playback an encoded opus file with Foobar2000. I have changed the extension from opus to ogg and then to celt without it working. I have also download the foo_input_celt.dll but not managed to playback it successfully. What am I missing? Regards.
Title: IETF Opus codec now ready for testing
Post by: LithosZA on 2012-05-31 20:36:17
Quote
I can't seem to playback an encoded opus file with Foobar2000. I have changed the extension from opus to ogg and then to celt without it working. I have also download the foo_input_celt.dll but not managed to playback it successfully. What am I missing? Regards.


foobar2000 Opus support seems to be on the todo list:

OPUS TODO (https://wiki.xiph.org/OPUS_TODO)
Title: IETF Opus codec now ready for testing
Post by: punkrockdude on 2012-05-31 20:41:22
foobar2000 Opus support seems to be on the todo list:

OPUS TODO (https://wiki.xiph.org/OPUS_TODO)

Thank you for the help but do you know any player that can play it in realtime?
Title: IETF Opus codec now ready for testing
Post by: zerowalker on 2012-06-01 00:41:37
Had done something entirely else XD

But got it working with that one now, using cmd etc.

And from my tests,

OPUS Is better than Autov with keeping details on characteristic things, like a singers dark voice etc, while Autov fails here and "blend" everything to make it smooth or something.

The Good thing with this is, you get more detail on these parts, the bad thing is, you get more "cracks etc" in the "surroundings".


Sorry for bad explanation, not the best listener nor explainer on this kind of stuff.
But that´s atleast what i got out of it on my tests.


EDIT:

I may take back my statement on which i prefer.

When i listen once again on them, the OPUS does have a Fuller more Concrete sound, while Autov like i said about, pretty much smooth things out to keep it "transparent".
I think that if i just play awhile i will ignore those crack sounds and it will be pretty pleasent really.

Though it´s not like i am going to sit and listen to 45 kbit music here, but it´s really neat that it´s moving forward on the Transparent/Size scale.

From what i would prefer, i think i would go with Autov as it´s more Transparent with the cracks and overall smoothness in the sound, though i really like the way opus keeps the details on stuff, but sadly the cracks is to much to be pleasent.

Settings where for one example: --framesize 60 --music --bitrate 45, Autov = q-1
Went after the filesize.
Title: IETF Opus codec now ready for testing
Post by: rt87 on 2012-06-01 00:49:18
aoTuV Q -1 is 48kbps.
Title: IETF Opus codec now ready for testing
Post by: kode54 on 2012-06-01 03:55:36
Thank you for the help but do you know any player that can play it in realtime?

opusdec will play it in real time if you don't pass an output path.
Title: IETF Opus codec now ready for testing
Post by: NullC on 2012-06-01 04:28:07
Options:
--bitrate n        Encoding bit-rate in kbit/sec
--cbr              Use constant bitrate encoding


Can you tell me where you got this binary so I can take it down or add a note that it's years old and people shouldn't use it?
Title: IETF Opus codec now ready for testing
Post by: CoRoNe on 2012-06-01 23:09:48
Does Opus have, or will Opus get an option equivalent to Vorbis's --ignorelength for use with Foobar?
Works fine on WinXP!
Title: IETF Opus codec now ready for testing
Post by: Gainless on 2012-06-01 23:31:24
Already found a sort of bug sample with a loud distortion on a kick, even with 128 kbps/framesize 60.

Audio Link (http://www.mediafire.com/download.php?3xr8adcquw4l75s)
Title: IETF Opus codec now ready for testing
Post by: 2012 on 2012-06-01 23:55:35
Already found a sort of bug sample with a loud distortion on a kick, even with 128 kbps/framesize 60.

Audio Link (http://www.mediafire.com/download.php?3xr8adcquw4l75s)


FWIW, If you resample to 48000 with sox before encoding. The problem will go away.

Opus operates with 48000 internally. But the result is resampled back after encoding to the original rate so people don't get confused. Someone disagreed with that reasoning in the IRC channel and I agree with that someone.

P.S. Acording to the devs, 60ms frames are not supposed to help. Not at those bitrates anyway.
Title: IETF Opus codec now ready for testing
Post by: 2012 on 2012-06-02 00:08:28
Opus operates with 48000 internally. But the result is resampled back after encoding to the original rate so people don't get confused. Someone disagreed with that reasoning in the IRC channel and I agree with that someone.


And my hunch was right. If you call opusdec with --rate 48000 so It doesn't downsample, the problem will go away.
Title: IETF Opus codec now ready for testing
Post by: Gainless on 2012-06-02 00:16:29
Already found a sort of bug sample with a loud distortion on a kick, even with 128 kbps/framesize 60.

Audio Link (http://www.mediafire.com/download.php?3xr8adcquw4l75s)


FWIW, If you resample to 48000 with sox before encoding. The problem will go away.

Opus operates with 48000 internally. But the result is resampled back after encoding to the original rate so people don't get confused. Someone disagreed with that reasoning in the IRC channel and I agree with that someone.

P.S. Acording to the devs, 60ms frames are not supposed to help. Not at those bitrates anyway.


Ok, I've set the "raw-rate" to 44100 now, sounds better but there are still pre-echos. I Hope I won't have to resample everything before encoding...
Title: IETF Opus codec now ready for testing
Post by: NullC on 2012-06-02 06:03:15
Ok, I've set the "raw-rate" to 44100 now, sounds better but there are still pre-echos. I Hope I won't have to resample everything before encoding...


All setting raw-rate would do is switch it from interpreting your input as a wav file and instead interpret it as raw PCM, so the wav header becomes a dozen junk samples at the beginning and your audio is all slid down that many samples.

Based on your description I was guessing that you're just clipping, which might come or go if you were right on the edge and you changed the offset— but your sample isn't that loud and I'm actually unable to reproduce your results.

/opusenc --bitrate 128 --framesize 60 Frozen\ Babylon\ \(Sample\).wav - |  ./opusdec - coded.wav

I don't think I can ABX these files, I'm certainly not hearing an obvious artifact.
Title: IETF Opus codec now ready for testing
Post by: 2012 on 2012-06-02 10:17:36
Based on your description I was guessing that you're just clipping, which might come or go if you were right on the edge and you changed the offset— but your sample isn't that loud and I'm actually unable to reproduce your results.

I don't think I can ABX these files, I'm certainly not hearing an obvious artifact.


The clip is definitely audible here when opusdec downsamples.

opusdec
(http://ompldr.org/vZTIycQ/t_p44.png)

opusdec --rate 48000
(http://ompldr.org/vZTIycg/t_p44_force48.png)

Look around 0.9-1.0
Title: IETF Opus codec now ready for testing
Post by: lvqcl on 2012-06-02 10:46:11
(http://img339.imageshack.us/img339/6686/clipboard01rh.png)

upper channel: opusenc --bitrate 128 --framesize 60  +  opusdec (bug between 0.950 and 0.955)
lower channel: opusenc --bitrate 128  +  opusdec (bug between 0.990 and 0.995)
Title: IETF Opus codec now ready for testing
Post by: Gainless on 2012-06-02 12:37:04
Ok, I've set the "raw-rate" to 44100 now, sounds better but there are still pre-echos. I Hope I won't have to resample everything before encoding...


All setting raw-rate would do is switch it from interpreting your input as a wav file and instead interpret it as raw PCM, so the wav header becomes a dozen junk samples at the beginning and your audio is all slid down that many samples.

Based on your description I was guessing that you're just clipping, which might come or go if you were right on the edge and you changed the offset— but your sample isn't that loud and I'm actually unable to reproduce your results.

/opusenc --bitrate 128 --framesize 60 Frozen\ Babylon\ \(Sample\).wav - |  ./opusdec - coded.wav

I don't think I can ABX these files, I'm certainly not hearing an obvious artifact.


Oh, sorry then I got confused with the meaning of the settings. The artifact (as 2012 mentioned) is definately there nonetheless if the decoder is not forced to keep the sample rate at 48 khz. Well, at least the file itself is not the problem but just the decoder.
Title: IETF Opus codec now ready for testing
Post by: zerowalker on 2012-06-03 02:19:19
Maybe a stupid question, but can someone say, what Latency has for relevance on Audio Codec?
I understand, low latency is good for speech, but what i don´t get it, where is the latency coming from, is it the decoding latency or what?

Thanks:)
Title: IETF Opus codec now ready for testing
Post by: NullC on 2012-06-03 02:55:57
Maybe a stupid question, but can someone say, what Latency has for relevance on Audio Codec?
I understand, low latency is good for speech, but what i don´t get it, where is the latency coming from, is it the decoding latency or what?
Thanks:)


In order to get useful compression codecs work with multiple samples at a time. They read in some samples enough to fill a code frame plus potentially some more for psycho-acoustic analysis 'lookahead', then they process it and emit a packet of compressed data.  On the far end the decoder reverses the process.

So even if your computer is infinitely fast a codec must have a least a frame size worth of delay and more if the frames overlap or the encoder needs lookahead for analysis (e.g. for transient switching).  Popular music codec like Vorbis and AAC have delays of hundreds of milliseconds which makes them not very suitable for interactive/communication uses.  Larger frames are generally better for compression because they enable higher coding gain and more precise psycho-acoustic models, though they also tend to have more pre-echo liability.  Opus has basic frame frame sizes from 2.5 to 20ms and and lows as 2.5ms, so 5-22.5ms codec latency (there are larger frame sizes, but they only pack multiple smaller frames to save a few bytes of header space/entropy coder overhead). Through a lot of hard work and a little luck it can get quality competitive with high latency coders at mid to high rates. Though at low bitrates (e.g. <=48 for music) I still expect high latency codecs to do better (except for speech).

Title: IETF Opus codec now ready for testing
Post by: NullC on 2012-06-03 03:02:45
upper channel: opusenc --bitrate 128 --framesize 60  +  opusdec (bug between 0.950 and 0.955)
lower channel: opusenc --bitrate 128  +  opusdec (bug between 0.990 and 0.995)


oh yea, it's super obvious without the --framesize 60.

I'll fix.
Title: IETF Opus codec now ready for testing
Post by: zerowalker on 2012-06-03 03:08:29
Maybe a stupid question, but can someone say, what Latency has for relevance on Audio Codec?
I understand, low latency is good for speech, but what i don´t get it, where is the latency coming from, is it the decoding latency or what?
Thanks:)


In order to get useful compression codecs work with multiple samples at a time. They read in some samples enough to fill a code frame plus potentially some more for psycho-acoustic analysis 'lookahead', then they process it and emit a packet of compressed data.  On the far end the decoder reverses the process.

So even if your computer is infinitely fast a codec must have a least a frame size worth of delay and more if the frames overlap or the encoder needs lookahead for analysis (e.g. for transient switching).  Popular music codec like Vorbis and AAC have delays of hundreds of milliseconds which makes them not very suitable for interactive/communication uses.  Larger frames are generally better for compression because they enable higher coding gain and more precise psycho-acoustic models, though they also tend to have more pre-echo liability.  Opus has basic frame frame sizes from 2.5 to 20ms and and lows as 2.5ms, so 5-22.5ms codec latency (there are larger frame sizes, but they only pack multiple smaller frames to save a few bytes of header space/entropy coder overhead). Through a lot of hard work and a little luck it can get quality competitive with high latency coders at mid to high rates. Though at low bitrates (e.g. <=48 for music) I still expect high latency codecs to do better (except for speech).



Ah so for example Skype, if i speak, it will collect some voice data in a framesieze, then send it, and the lower that framesize is, the faster it goes, but the less Accurate it will be?

But for Vorbis etc, does it even needa frame size, can´t it be unlimited?
If it´s better i mean?

But don´t you think Opus will dominate Vorbis at all?
Cause it would be lovely if Vorbis and AAC got knocked down from the throne letting new codecs and probably pushing the lossy codecs even more.
Title: IETF Opus codec now ready for testing
Post by: NullC on 2012-06-03 04:16:21
Okay, the fix for the click on the opusdec 44.1kHz output is up!

The fix is in opusdec with the version string "opus-tools 0.1.0-9-gac7490c (based on libopus 0.9.11-75-gc64f4a4)"
http://git.xiph.org/?p=opus-tools.git;a=co...c8518af24336091 (http://git.xiph.org/?p=opus-tools.git;a=commit;h=ac7490cbac7b5790a3ea2e9f7c8518af24336091)

Sorry about that, and thanks so much for testing and reporting!

New windows binaries are at:
http://people.xiph.org/~greg/opus-tools.zip (http://people.xiph.org/~greg/opus-tools.zip)
Title: IETF Opus codec now ready for testing
Post by: NullC on 2012-06-03 04:25:18
Ah so for example Skype, if i speak, it will collect some voice data in a framesieze, then send it, and the lower that framesize is, the faster it goes, but the less Accurate it will be?


Basically.

Quote
But for Vorbis etc, does it even needa frame size, can´t it be unlimited?
If it´s better i mean?

But don´t you think Opus will dominate Vorbis at all?
Cause it would be lovely if Vorbis and AAC got knocked down from the throne letting new codecs and probably pushing the lossy codecs even more.


Even if you don't care about delay bigger frames also mean more memory required and usually more computing power, as well as files which are more sensitive to damage and/or aren't good for seeking. For any design beyond a certain point the quality stops going up and you also get more pre-echo problems, so there is diminishing returns.

In listening tests Opus has done substantially better than Vorbis and HE-AAC (e.g. at 64k http://listening-tests.hydrogenaudio.org/igorc/results.html) (http://listening-tests.hydrogenaudio.org/igorc/results.html)), smaller more informal tests have also showed superior performance at 96k (though testing at 96k is harder). At lower rates I expect opus to hold up well for speech, but for music I expect it to be worse than AoTuV vorbis, at least depending on personal artifact preference, and or HE-AAC.
Title: IETF Opus codec now ready for testing
Post by: rt87 on 2012-06-03 09:42:37
Okay, the fix for the click on the opusdec 44.1kHz output is up!

The fix is in opusdec with the version string "opus-tools 0.1.0-9-gac7490c (based on libopus 0.9.11-75-gc64f4a4)"
http://git.xiph.org/?p=opus-tools.git;a=co...c8518af24336091 (http://git.xiph.org/?p=opus-tools.git;a=commit;h=ac7490cbac7b5790a3ea2e9f7c8518af24336091)

Sorry about that, and thanks so much for testing and reporting!

New windows binaries are at:
http://people.xiph.org/~greg/opus-tools.zip (http://people.xiph.org/~greg/opus-tools.zip)

new opusdec can't output to wave device:
Code: [Select]
I:\>opusdec.exe 05.opus
Decoding 44100 Hz audio (2 channels)
Cannot open output: No such file or directory
Title: IETF Opus codec now ready for testing
Post by: lvqcl on 2012-06-03 10:40:49
Code: [Select]
Decoding 44100 Hz audio (1 channel)
Cannot open output: No error


Also: I tried to subtract original 44.1 audio from this audio after encoding+decoding. It turns out that the latter is shifted by ~0.42 sampling intervals...
Title: IETF Opus codec now ready for testing
Post by: NullC on 2012-06-03 14:22:44
Cannot open output: No such file or directory[/code]


I got a little too aggressive with some error handling I added.  In any case, fixed and zip file updated.
Title: IETF Opus codec now ready for testing
Post by: IgorC on 2012-06-03 18:56:37
Opus, AoTuV and Apple AAC at ~ 128 kbps http://d.hatena.ne.jp/kamedo2/20120603 (http://d.hatena.ne.jp/kamedo2/20120603)

Also he has tested Opus 0.9.10 (main branch). Newer exp4 branch should do better.
Title: IETF Opus codec now ready for testing
Post by: bawjaws on 2012-06-03 21:49:00

I notice the previous blog entry was them testing at 80kbps a couple of months ago:

http://d.hatena.ne.jp/kamedo2/20120315/1331839849 (http://d.hatena.ne.jp/kamedo2/20120315/1331839849)


I notice he uses tvbr for that one and cvbr for 128kbps. I originally thought this was hobbling iTunes by forcing it to be closer to the target bitrate. I thought this might be compensating for the lack of tuning for VBR in this version of Opus. But reading the docs it seems to actually put a *lower* limit of 128kbps on the encoder, which could be considered a benefit for iTunes, and perhaps explains why it's average bitrate is the highest of the three in that test (it's the lowest in the 80kbps test).
Title: IETF Opus codec now ready for testing
Post by: darkbyte on 2012-06-05 16:02:39
Is somebody working on a foobar decoder plugin for Opus? I'm aware of a CELT plugin but i'm pretty sure that it will not work with the new bitstream. I like to test it longer with more samples but i don't wan't to decode back to WAV or use the command line decoder for playback.
Title: IETF Opus codec now ready for testing
Post by: greensdrive on 2012-06-06 06:13:34
not sure if this is a bug or if it's meant to be, but the current opus-tools ("current" meaning the latest downloadable from people.xiph.org) does not accept piped input.  at least, not in foobar2000.  I had to use the %s for temporary file input instead.  and I'm referring specifically to opusenc.exe...

also, I second the motion for a foobar2000 decoder, but I'm sure it will be available when opus is stable anyway.
Title: IETF Opus codec now ready for testing
Post by: NullC on 2012-06-11 14:57:33
not sure if this is a bug or if it's meant to be, but the current opus-tools ("current" meaning the latest downloadable from people.xiph.org) does not accept piped input.  at least, not in foobar2000.  I had to use the %s for temporary file input instead.  and I'm referring specifically to opusenc.exe...

also, I second the motion for a foobar2000 decoder, but I'm sure it will be available when opus is stable anyway.


It _should_ accept piped input and does when run in wine. It automatically ignores the wav length.  Is it crashing for you or just giving truncated files?

A foobar2000 decoder won't be available no one creates one.  I'm not aware of anyone working on it. I'd be glad to answer questions / review code to help make that happen. Anyone who works on it should make sure it plays the testvectors at http://people.xiph.org/~greg/opus_testvectors/ (http://people.xiph.org/~greg/opus_testvectors/)  (will be posted on the opus site when the set of tests are complete)
Title: IETF Opus codec now ready for testing
Post by: lvqcl on 2012-06-11 16:32:15
I have a question about setup_resample() function. It has the following code:

Code: [Select]
    opt->skip+=speex_resampler_get_output_latency(rs->resampler);


Maybe it's better to replace it with speex_resampler_skip_zeros(rs->resampler) ?
Title: IETF Opus codec now ready for testing
Post by: NullC on 2012-06-11 16:51:03
I have a question about setup_resample() function. It has the following code:
Maybe it's better to replace it with speex_resampler_skip_zeros(rs->resampler) ?


I'd rather not. Why do you ask?
Title: IETF Opus codec now ready for testing
Post by: lvqcl on 2012-06-11 17:27:59
get_output_latency() returns rounded value...

For example, if filt_len==128, in_rate==44100 and out_rate==48000 (num_rate=147, den_rate=160):

input latency = filt_len / 2 = 64 samples.
output latency = (filt_len/2)*den_rate/num_rate = 64*160/147 = 69,65986... => 70 samples.

Maybe I'm wrong but IMHO this is the reason of this sub-sample shift (upper part: source, lower - after encoding):

(http://i.imgur.com/czB80.png)

not a big problem, but if it can be easily avoided - why not?
Title: IETF Opus codec now ready for testing
Post by: NullC on 2012-06-11 19:06:50
get_output_latency() returns rounded value...
[...]
not a big problem, but if it can be easily avoided - why not?


Well, it can't /generally/ be avoided— because it assumes that the encoder and decoder are using the exact same resampling filter (well, at least one with the matching subsample group delays).  Though indeed, it sounds like making input_latency truncate instead of rounding would make it match in opus-tools.  Have you tried that?  Because it's not possible to avoid a subsample delay in the general case I haven't cared much about it, but I agree if it can be trivially fixed without hurting anything else then why not.

As far as skipping zeros go, I plan on eventually making it so that opusenc can have either reverse extrapolated audio or audio from the prior track in the preskip for improved gapless behavior, and having the preskip differ from file to file is the only way to be sure that people implementing opus playback will bother reading it instead of hard coding some incorrect value.
Title: IETF Opus codec now ready for testing
Post by: greensdrive on 2012-06-11 20:29:05
this first one doesn't work (I put --vbr just to make sure).  gives me a 21 kilobyte file.  it plays back in opusdec.exe, but is truncated.

Code: [Select]
--bitrate 512 --music --vbr - %d


this last one works.  plays back the entire file in opusdec.exe...

Code: [Select]
--bitrate 512 --music --vbr %s %d


I don't think it's a fb2k bug, but just in case you're wondering, it's foobar2000 1.1.13.  also, the original file is wavpack, not wav.
Title: IETF Opus codec now ready for testing
Post by: NullC on 2012-06-11 21:11:53
this first one doesn't work (I put --vbr just to make sure).  gives me a 21 kilobyte file.  it plays back in opusdec.exe, but is truncated.


How long is it?  21kilobytes sounds like it's not being truncated at zero.  If foobar is sending some short but non-zero length that stinks and foobar should be fixed. I will add an option to ignore the length but it really shouldn't be needed.  (I note that oggenc has an ignorelength option which is not actually connected to anything)
Title: IETF Opus codec now ready for testing
Post by: kode54 on 2012-06-11 23:42:26
foobar2000 sends 0xFFFFFFFF for the length fields it cannot predict.
Title: IETF Opus codec now ready for testing
Post by: greensdrive on 2012-06-12 04:01:52
How long is it?


this is the opusinfo.exe output:

Code: [Select]
Processing file "10 love in plaster.opus"...

New logical stream (#1, serial: 000063ed): type opus
Encoded with libopus 0.9.11-75-gc64f4a4
User comments section follows...
        ENCODER=opusenc from opus-tools 0.1.0-9-gac7490c

Opus stream 1:
        Pre-skip: 356
        Playback gain: 0dB
        Channels: 2
        Original sample rate: 44100Hz
        Packet duration:   20.0ms (max),   20.0ms (avg),   20.0ms (min)
        Page duration:    360.0ms (max),  360.0ms (avg),  360.0ms (min)
        Total data length: 21536 bytes (overhead: 1.37%)
        Playback length: 0m:00.348s
        Average bitrate: 494.6 kb/s, w/o overhead: 487.9 kb/s
Logical stream 1 ended


please note that the encoder version string may not have been updated with the recent release, as well as any other version string.  I am pretty sure that the README says something different as far as what git revision it was built from.
Title: IETF Opus codec now ready for testing
Post by: NullC on 2012-06-12 05:38:08
Playback length: 0m:00.348s
please note that the encoder version string may not have been updated with the recent release, as well as any other version string.  I am pretty sure that the README says something different as far as what git revision it was built from.


The only explanation I can come up with for that length is that Windows is returning a length of 16384 on a pipe. Weird.  I added an --ignorelength before it was pointed out what foobar sends, didn't bother mentioning it because since foobar is sending  0xFFFFFFFF it won't do anything. I'll make it also avoid trying to ftell to get the length and we'll see if that fixes it.

As far as the versions— they're automatically generated from the SCM and don't need to be updated, so they're always correct.

Here is an updated opus-tools that might(?!) fix that behavior if you provide the --ignorelength argument:  https://people.xiph.org/~greg/opus-tools.zip (https://people.xiph.org/~greg/opus-tools.zip)
Title: IETF Opus codec now ready for testing
Post by: greensdrive on 2012-06-12 14:47:32
--ignorelength works like a charm.
Title: IETF Opus codec now ready for testing
Post by: NullC on 2012-06-12 16:17:01
--ignorelength works like a charm.


With this information in hand I went and googled a bit harder— apparently fseek() on Windows returns 0 on pipes (it looks successful).  I've added an additional test on Windows to check for pipes and ignorelength shouldn't be needed in these cases anymore.  It's still available for use just in case the wav header is wrong in a way opusenc doesn't detect.

https://people.xiph.org/~greg/opus-tools.zip (https://people.xiph.org/~greg/opus-tools.zip)
Title: IETF Opus codec now ready for testing
Post by: greensdrive on 2012-06-12 17:26:52
wow.  no --ignorelength.  no %s.  opusenc.exe now works with piped input.
Title: IETF Opus codec now ready for testing
Post by: NullC on 2012-06-14 19:43:08
Just a minor update:  The win32 builds of opus-tools are now available at http://opus-codec.org/downloads/ (http://opus-codec.org/downloads/)

Thanks to everyone here in helping it to a maturity level high enough to justify putting it on the site.

I also have some silly live streams running at

http://ec2-50-112-77-171.us-west-2.compute...poralfugue.opus (http://ec2-50-112-77-171.us-west-2.compute.amazonaws.com:8000/temporalfugue.opus)
and
http://ec2-50-112-77-171.us-west-2.compute...8000/clock.opus (http://ec2-50-112-77-171.us-west-2.compute.amazonaws.com:8000/clock.opus)

If you have curl you can play them using curl URL | opusdec -  or with Firefox nightly  (after going to about:config and enabling opus).
Title: IETF Opus codec now ready for testing
Post by: greensdrive on 2012-06-14 20:44:03
NullC:

not directly related to opus, but it seems the links for the man pages are wrong.

encode goes to opusenc.html
inspect goes to opusdec.html
decode goes to opusinfo.html

those links are part of the sentence: "Opus-tools provides command-line utilities to encode, inspect, and decode .opus files."

figured I'd post it here since I've heard no one can create a Trac account for posting bugs on xiph.org.
Title: IETF Opus codec now ready for testing
Post by: NullC on 2012-06-14 21:11:19
NullC:

not directly related to opus, but it seems the links for the man pages are wrong.
figured I'd post it here since I've heard no one can create a Trac account for posting bugs on xiph.org.


Doh. Thanks. Fixed.

We'll have a proper bug-tracker and such up at least in time for the 1.0 release.
Title: IETF Opus codec now ready for testing
Post by: Brazil2 on 2012-06-15 09:55:09
Before I run anything, can you explain me why the encoder and decoder have gained about 1MB between the latest test version (https://people.xiph.org/~greg/opus-tools.zip) and the v0.1.2 (https://ftp.mozilla.org/pub/mozilla.org/opus/win32/opus-tools-0.1.2.zip) within few hours ?


Code: [Select]
File        Date/Time           Size

opusenc     12/06/2012 10:58    329 728
opusdec     12/06/2012 10:58    310 784

opusenc     12/06/2012 14:24    1 348 000
opusdec     12/06/2012 14:24    1 282 881
Title: IETF Opus codec now ready for testing
Post by: NullC on 2012-06-15 21:11:29
Before I run anything, can you explain me why the encoder and decoder have gained about 1MB between the latest test version (https://people.xiph.org/~greg/opus-tools.zip) and the v0.1.2 (https://ftp.mozilla.org/pub/mozilla.org/opus/win32/opus-tools-0.1.2.zip) within few hours ?


The Mozilla folks apparently didn't strip the binaries (and they're big to begin with because they're statically linked), stripping removes debugging information and other not terribly essential stuff.

[gmaxwell@helmholtz tmp]$ wget https://ftp.mozilla.org/pub/mozilla.org/opu...tools-0.1.2.zip (https://ftp.mozilla.org/pub/mozilla.org/opus/win32/opus-tools-0.1.2.zip)
[gmaxwell@helmholtz tmp]$ unzip opus-tools-0.1.2.zip
[gmaxwell@helmholtz tmp]$ cd opus-tools-0.1.2/
[gmaxwell@helmholtz opus-tools-0.1.2]$ mingw-strip *.exe
[gmaxwell@helmholtz opus-tools-0.1.2]$ ls -l *.exe
-rwxr-xr-x. 1 gmaxwell gmaxwell 287744 Jun 15 16:10 opusdec.exe
-rwxr-xr-x. 1 gmaxwell gmaxwell 327680 Jun 15 16:10 opusenc.exe
-rwxr-xr-x. 1 gmaxwell gmaxwell  34304 Jun 15 16:10 opusinfo.exe
Title: IETF Opus codec now ready for testing
Post by: Brazil2 on 2012-06-16 17:31:30
The Mozilla folks apparently didn't strip the binaries (and they're big to begin with because they're statically linked), stripping removes debugging information and other not terribly essential stuff.

[gmaxwell@helmholtz opus-tools-0.1.2]$ mingw-strip *.exe
[gmaxwell@helmholtz opus-tools-0.1.2]$ ls -l *.exe
-rwxr-xr-x. 1 gmaxwell gmaxwell 287744 Jun 15 16:10 opusdec.exe
-rwxr-xr-x. 1 gmaxwell gmaxwell 327680 Jun 15 16:10 opusenc.exe
-rwxr-xr-x. 1 gmaxwell gmaxwell  34304 Jun 15 16:10 opusinfo.exe

Works like a charm, thanks for the tip
Title: IETF Opus codec now ready for testing
Post by: NullC on 2012-07-03 14:21:08
Opus has received the IETF's approval to become a standard.  There will be some weeks of publication / pure-editorial delay and it will receive and RFC number and we'll make the big public announcements.

Now is really the time to get support into applications (well, this was also true for some time, but doubly so now).  If there is an application you think should have Opus support that doesn't, especially open source ones, please post about it here and I'll do what I can to coordinate with their authors.
Title: IETF Opus codec now ready for testing
Post by: Kohlrabi on 2012-07-03 14:37:23
Now is really the time to get support into applications (well, this was also true for some time, but doubly so now).  If there is an application you think should have Opus support that doesn't, especially open source ones, please post about it here and I'll do what I can to coordinate with their authors.

Probably the most important ones are the major browser vendors, Winamp, foobar2000, gstreamer and ffmpeg. Scouring the web I saw that at least the latter two have some implementations of CELT decoders in their trees.
Title: IETF Opus codec now ready for testing
Post by: NullC on 2012-07-03 14:49:49
Probably the most important ones are the major browser vendors, Winamp, foobar2000, gstreamer and ffmpeg. Scouring the web I saw that at least the latter two have some implementations of CELT decoders in their trees.

Opus support in the audio tag is complete (well multichannel is following behind) in Firefox, and you can use it in Aurora (FF15) and Nightly, though you have to activate it through a preference: some quick instructions (http://opus-codec.org/examples/firefox.shtml.en).

Support in Gstreamer is complete and reasonably well tested— at least for file based usage, not so much for RTP—, I'm not sure where in their release pipeline  gstreamer is right now.

There are patches for Ffmpeg, though last I checked were incomplete and so they handled files incorrectly (e.g. got the duration wrong, did not apply the header gain, couldn't accurately seek) but this should be fairly straight forward to complete.

I understand that foobar2000 is being worked on, but I'm not sure where it stands. I understand that the relevant people have been prodded.  People still use Winamp? Okay. I'll see what I need to do there.
Title: IETF Opus codec now ready for testing
Post by: lvqcl on 2012-07-03 14:55:42
Probably the most important ones are the major browser vendors, Winamp, foobar2000, gstreamer and ffmpeg. Scouring the web I saw that at least the latter two have some implementations of CELT decoders in their trees.

foo_input_celt (http://www.hydrogenaudio.org/forums/index.php?showtopic=88656)
Title: IETF Opus codec now ready for testing
Post by: LithosZA on 2012-07-03 15:07:43
Quote
foo_input_celt


Will that work with Opus encoded files or only CELT?
Title: IETF Opus codec now ready for testing
Post by: Garf on 2012-07-03 15:09:58
Quote
foo_input_celt


Will that work with Opus encoded files or only CELT?


Given the age, likely only CELT. Here's hoping Peter adds full Opus by default in foobar2000.
Title: IETF Opus codec now ready for testing
Post by: lvqcl on 2012-07-03 15:18:02
This plugin is old and incompatible even with CELT 0.11.4: http://www.hydrogenaudio.org/forums/index....st&p=758102 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=85000&view=findpost&p=758102)
Title: IETF Opus codec now ready for testing
Post by: yourlord on 2012-07-03 16:07:15
Opus has received the IETF's approval to become a standard.



Congrats! Another great day in the open audio world!
Title: IETF Opus codec now ready for testing
Post by: greensdrive on 2012-07-03 17:09:05
this is wonderful.  I silently predicted this, though.

as far as applications, DeaDBeeF.  open source, and I'm fairly certain it doesn't use gstreamer.  I use it a lot, so Opus support would be awesome.  I also use foobar2000, but Peter may have something going on behind the scenes for Opus... I hope.

question: do the "exp_wip" branches have some kind of extra tuning?  I mean, what's their purpose?
Title: IETF Opus codec now ready for testing
Post by: CoRoNe on 2012-07-03 19:37:03
If there is an application you think should have Opus support that doesn't, especially open source ones, please post about it here and I'll do what I can to coordinate with their authors.
BASS Audio Library (http://www.un4seen.com/)
Title: IETF Opus codec now ready for testing
Post by: IgorC on 2012-07-03 21:00:34
question: do the "exp_wip" branches have some kind of extra tuning?  I mean, what's their purpose?

Reading the changelog can be informative.

And since it's an open source You can look as close as You wish ... if You wish.
Title: IETF Opus codec now ready for testing
Post by: skamp on 2012-07-03 21:43:30
If there is an application you think should have Opus support that doesn't, especially open source ones, please post about it here and I'll do what I can to coordinate with their authors.


caudec 1.4.2 (http://code.google.com/p/caudec/downloads/list) supports encoding with Opus

I asked DeaDBeeF's author about it, but that was the first he heard of it. He has thus no current plans to support it, and he said ALAC support will likely come first.
Title: IETF Opus codec now ready for testing
Post by: greensdrive on 2012-07-03 22:13:11
Reading the changelog can be informative.

I'm familiar with git, but never was interested enough to investigate those branches until earlier today.  dunno why I asked, really...

side note: I was unable to compile a working opusenc on Linux Mint.  it got through ./configure, make, sudo make install with no errors, but complains about the missing libopus.so.0, which is actually installed in /usr/local/lib, and also got through ./configure, make, sudo make install with no errors.  very odd.
Title: IETF Opus codec now ready for testing
Post by: NullC on 2012-07-04 00:20:59
Reading the changelog can be informative.

I'm familiar with git, but never was interested enough to investigate those branches until earlier today.  dunno why I asked, really...

side note: I was unable to compile a working opusenc on Linux Mint.  it got through ./configure, make, sudo make install with no errors, but complains about the missing libopus.so.0, which is actually installed in /usr/local/lib, and also got through ./configure, make, sudo make install with no errors.  very odd.


It's the expected behavior when /usr/local/ isn't in your PKG_CONFIG path. Run:

PKG_CONFIG_PATH=/usr/local/lib/pkgconfig/ ./configure

And you'll be all set.

You can see the revision history (http://git.xiph.org/?p=opus.git;a=shortlog;h=refs/heads/exp_wip6) without running git yourself.  (it's now called exp_wip6 as it was rebased on the current master work today)

The EXP work adds a psymodel to Opus. It's used to dynamically control some of the tuning and the bitrate.  The improvement for VBR is fairly substantial.  I'll put up an opus-tools win32 build with it soon for people here to try out.
Title: IETF Opus codec now ready for testing
Post by: NullC on 2012-07-04 07:07:04
This is a win32 build of opus-tools using the "exp_analysis" encoder (http://people.xiph.org/~greg/opus-tools_exp_77d043aa.zip).

Please give it a whirl. Most interesting is VBR at moderately low bitrates (e.g. 64kbit/sec for stereo).

This is an improved Opus encoder which uses an explicit psymodel to inform various encoding decisions. It should improve the perceived quality overall and greatly improve it on some samples (and this belief has been supported in small blind informal listening tests).

A couple quick notes:
* This encoder is much slower, this is expected. It should get somewhat faster before release.
* This encoder is much more VBR in VBR mode than prior opus encoders, on single tracks you may get significantly more or less than you asked for (as is true for libvorbis and other true VBR encoders)
* This encoder's VBR is not yet calibrated.  If you ask for 64k you may find that the average on a large representative collection comes out to be 75k (random numbers).  If so, you ought to be comparing this to the old encoder running at a similar rate overall rate.  Obviously it will be calibrated before the release so that when you ask for 64 you get 64 on average for large diverse collections.

We'd very much like to hear if you find any samples where (after fairly calibrating rates on some bigger collection) this encoder does obviously (or at least ABXably) worse than the normal encoder.

Thanks and happy listening!
Title: IETF Opus codec now ready for testing
Post by: Dynamic on 2012-07-04 11:03:34
I think Android should add OPUS support. They've incorporated Vorbis from the start and any app can use that infrastructure to play Vorbis natively.
Very plausible that OPUS support could get into other Google products such as GoogleTalk and GooglePlus Hangouts, some of which might get native Android support.
I presume that fixed-point support implies compatibility with embedded or ARM-type architectures (I didn't spot implicit mention of integer decoding support, but fixed-point can usually be implemented using integer architecture with appropriate bit-shifting).

It may be worth bringing up OPUS as a new standard with such a lot of strong selling points, all converging in one codec, giving the potential for new use-cases and improvements to existing use-cases:

What really excites me about OPUS is (I think my understanding is correct on all these points):

ONE CODEC SIMULTANEOUSLY CAPABLE OF CLASS-LEADING PERFORMANCE IN A WIDE VARIETY OF USES:
• live or delayed listening;
• speech & music;
• mono, stereo or multichannel;
• streaming or stored files;
• bit-perfect or degraded transmission

Specific features:
- at ultra-low bitrates from 6kbps: good speech codec with low latency
- at low bitrates: test-topping stereo music performance at low constrained bitrates, with low latency and packet loss concealment all at the same time
- at higher-bitrates: transparent quality, low latency and packet loss concealment at same time
- scalable anywhere between these extremes
- seamlessly switchable between modes during live stream
- floating/fixed-point compatible


- topping low bitrate stereo music blind listening test (as CELT, despite competing in 25ms latency against the best high-latency codecs)
- also capable of ultra-low bitrates as a speech codec
- all the same advantages as Vorbis (open patent-free design philosophy - suitable for Wikipedia, for example), scalable from low bitrates up to perceptual transparency yet more data-efficient than Vorbis despite lower latency
- very low or low latency
- web embedding support
- two-way/multi-way comms suitable including music-compatible at mobile-suitable bitrates with packet loss concealment
- suitable for live-casting (e.g. potentially useful for personal playback for the hearing-impaired (or anyone) at live events with low latency - still lip synced with a live speaker - with modest bandwidth requirements)
- potential for wireless headphone implementations given low latency
- suitable for live jam sessions over hundreds of kilometres
- many more uses can be developed given the convergence of these features in one codec for the first time

And also, it's already got support coming or implemented in beta from some important players in the field.
Title: IETF Opus codec now ready for testing
Post by: greensdrive on 2012-07-04 13:32:03
I agree that Android should support playback (among other things).  however, I kinda think Google supporting Opus upon or near 1.0 release is pretty unrealistic.

NullC:

what I meant earlier was that I compiled and installed opus (exp_wip5 from git).  then I compiled and installed opus-tools (from git).  but after that, running `opusenc --help` from the command line gave me a "cannot find shared object libopus.so.0" type of error.  just wanted to clarify.  it's probably just a problem on my end.
Title: IETF Opus codec now ready for testing
Post by: jmvalin on 2012-07-04 14:28:26
what I meant earlier was that I compiled and installed opus (exp_wip5 from git).  then I compiled and installed opus-tools (from git).  but after that, running `opusenc --help` from the command line gave me a "cannot find shared object libopus.so.0" type of error.  just wanted to clarify.  it's probably just a problem on my end.


Try:
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib/

Title: IETF Opus codec now ready for testing
Post by: Garf on 2012-07-04 17:45:36
This is a win32 build of opus-tools using the "exp_analysis" encoder (http://people.xiph.org/~greg/opus-tools_exp_77d043aa.zip).

Please give it a whirl.


Might be worthy of a new top-level topic? This kind of thing should very interesting to our audience.
Title: IETF Opus codec now ready for testing
Post by: NullC on 2012-07-04 20:57:53
what I meant earlier was that I compiled and installed opus (exp_wip5 from git).  then I compiled and installed opus-tools (from git).  but after that, running `opusenc --help` from the command line gave me a "cannot find shared object libopus.so.0" type of error.  just wanted to clarify.  it's probably just a problem on my end.


Try:
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib/


^ That.  Or add a line with "/usr/local/lib/" to your /etc/ld.so.conf  ... Most GNU/Linux systems don't look in /usr/local/lib/  by default
Title: IETF Opus codec now ready for testing
Post by: IgorC on 2012-07-05 05:46:54
This is a win32 build of opus-tools using the "exp_analysis" encoder (http://people.xiph.org/~greg/opus-tools_exp_77d043aa.zip).

Please give it a whirl.


Might be worthy of a new top-level topic? This kind of thing should very interesting to our audience.

Have tried the experimental branch here http://www.hydrogenaudio.org/forums/index....st&p=796102 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=86580&view=findpost&p=796102)
My guess is that  people will want to get their hands to it when some support will be here. 



Title: IETF Opus codec now ready for testing
Post by: NullC on 2012-07-05 05:53:23
I've posted an updated win32 build of the experimental encoder branch:

opus-tools_exp_1a50ad0b.zip (https://people.xiph.org/~greg/opus-tools_exp_1a50ad0b.zip)

This update includes encoder fixes for 2.5ms frame VBR (a bug in the prior version made it always produce very low rates) and an updated version of opusenc with improved gapless handling contributed by kode54.
Title: IETF Opus codec now ready for testing
Post by: Gainless on 2012-07-06 15:15:36
I've posted an updated win32 build of the experimental encoder branch:

opus-tools_exp_1a50ad0b.zip (https://people.xiph.org/~greg/opus-tools_exp_1a50ad0b.zip)

This update includes encoder fixes for 2.5ms frame VBR (a bug in the prior version made it always produce very low rates) and an updated version of opusenc with improved gapless handling contributed by kode54.


Thanks
I've just tested it with a few tunes at 64 kbps and found one that may could benefit of some improvements.

Audio Link (http://www.mediafire.com/?5c02z2k67l0cze7)

Just listen to the distorted kinda vocal that's coming in after a few seconds.
Title: IETF Opus codec now ready for testing
Post by: greensdrive on 2012-07-06 20:30:48
Gainless, I listened to the entire sample, no vocals.  maybe you uploaded the wrong clip?  also, was that the original lossless or the encoded version?  I would think the original lossless would be more important to test with...
Title: IETF Opus codec now ready for testing
Post by: punkrockdude on 2012-07-07 03:02:04
C'mon coders. Please make a Foobar2000 decoder so we can use this format. Regards.
Title: IETF Opus codec now ready for testing
Post by: Gainless on 2012-07-07 10:38:49
Gainless, I listened to the entire sample, no vocals.  maybe you uploaded the wrong clip?  also, was that the original lossless or the encoded version?  I would think the original lossless would be more important to test with...


Ok, "vocal" isn't a great description, it's more like a distorted voice saying "e-ah!". And the sample is of course from the original lossless file.
Title: IETF Opus codec now ready for testing
Post by: IgorC on 2012-07-07 18:44:25
opus-tools_exp_1a50ad0b.zip (https://people.xiph.org/~greg/opus-tools_exp_1a50ad0b.zip)

This update includes encoder fixes for 2.5ms frame VBR (a bug in the prior version made it always produce very low rates) and an updated version of opusenc with improved gapless handling contributed by kode54.
I've tried velvet sample http://www.rarewares.org/test_samples/velvet.wv (http://www.rarewares.org/test_samples/velvet.wv) and compared it to CELT 0.11.2 because the  last one was very aggressive to preserve transients (though at cost of not great quality for tonal samples).

This build (exp6) produces ~64 kbps with --bitrate 61 and the same as CELT 0.11.2 --bitrate 67.5 kbps on large number of files.

While exp6 is a bit inferior to handle transients it has more balanced overall quality, better trade-off for transients/tonality (short/long blocks).

Code: [Select]
ABC/HR for Java, Version 0.53a, 07 July 2012
Testname:

Tester: IgorC

1L = velvet_CELT_0.11.2_67kbps.wav
2R = velvet_61k_exp6.wav

Ratings on a scale from 1.0 to 5.0

---------------------------------------
General Comments:
---------------------------------------
1L File: velvet_CELT_0.11.2_67kbps.wav
1L Rating: 3.5
1L Comment:
---------------------------------------
2R File: velvet_61k_exp6.wav
2R Rating: 3.1
2R Comment:
---------------------------------------

ABX Results:
velvet_CELT_0.11.2_67kbps.wav vs velvet_61k_exp6.wav
    5 out of 5, pval = 0.031


---- Detailed ABX results ----
velvet_CELT_0.11.2_67kbps.wav vs velvet_61k_exp6.wav
Playback Range: 00.000 to 11.812
    2:04:41 PM p 1/1 pval = 0.5
    2:04:45 PM p 2/2 pval = 0.25
    2:04:50 PM p 3/3 pval = 0.125
    2:05:14 PM p 4/4 pval = 0.062
    2:05:22 PM p 5/5 pval = 0.031
I wish I had a bit of time to get look into some parameters in code and try some variants but it's not the case. 
Title: IETF Opus codec now ready for testing
Post by: kennedyb4 on 2012-07-07 22:33:25
A listening test sounds like a great idea. Could I suggest 64kbps as the encoders are so good now that 96kbps is very painstaking, at least for me.
Title: IETF Opus codec now ready for testing
Post by: NullC on 2012-07-07 23:59:52
A listening test sounds like a great idea. Could I suggest 64kbps as the encoders are so good now that 96kbps is very painstaking, at least for me.


Conducting a large listening test of a moving target encoder— which won't exist except in the source code history in the current form anymore by the time the test is done— doesn't sound like a grand idea to me.

... Unless people really can't find any problem areas in the exp encoder and it's perfect, in which case we better stop changing it.
Title: IETF Opus codec now ready for testing
Post by: IgorC on 2012-07-08 21:12:08
A listening test sounds like a great idea. Could I suggest 64kbps as the encoders are so good now that 96kbps is very painstaking, at least for me.

I beleive we will see a lot of public tests ( at 64 kbps too) in future.  There is still a long way for audio compression (USAC/Extended HE-AAC, Opus, new versions of LC/HE-AAC encoders, Ghost).
Title: IETF Opus codec now ready for testing
Post by: rt87 on 2012-07-09 09:03:01
A listening test sounds like a great idea. Could I suggest 64kbps as the encoders are so good now that 96kbps is very painstaking, at least for me.

I beleive we will see a lot of public tests ( at 64 kbps too) in future.  There is still a long way for audio compression (USAC/Extended HE-AAC, Opus, new versions of LC/HE-AAC encoders, Ghost).

I look forward to see a lower-than-64kbps (for example 48kbps) test against Vorbis and HE-AAC.
Title: IETF Opus codec now ready for testing
Post by: IgorC on 2012-07-09 17:05:30
Post your suggestions here General discussion of future public test (http://www.hydrogenaudio.org/forums/index.php?showtopic=92490&hl=)
Title: IETF Opus codec now ready for testing
Post by: NullC on 2012-07-09 20:02:12
I look forward to see a lower-than-64kbps (for example 48kbps) test against Vorbis and HE-AAC.


I'd be interested in seeing a test with just one or two people... to see if a bigger one s even worth doing. Opus is great... but for music (as opposed to speech) I would expect that at low enough rates Vorbis and especially HE-AAC will end up ahead again.

Perhaps I spent too much time on killer samples so my expectations are a bit low, and its possible that after collection rate correction the exp encoder will do better than I'm expecting. I'm not sure where that boundary lies exactly,  but I don't see much purpose in having a big multiformat test with forgone conclusions if 48kbit is on the wrong side of it.

Title: IETF Opus codec now ready for testing
Post by: NullC on 2012-07-11 05:35:28
I've tagged opus-tools 0.1.3, and there are now binaries on the downloads page (http://www.opus-codec.org/downloads/).

This version includes the gapless improvements that were in the last development-test build I cut as well as correct multichannel channel ordering for wav output (finally! sorry for the delay).

All feedback welcome.
Title: IETF Opus codec now ready for testing
Post by: 2304p on 2012-07-11 06:52:57
I've tagged opus-tools 0.1.3, and there are now binaries on the downloads page (http://www.opus-codec.org/downloads/).

This version includes the gapless improvements that were in the last development-test build I cut as well as correct multichannel channel ordering for wav output (finally! sorry for the delay).

All feedback welcome.



link doesn't work
Code: [Select]
Forbidden

You don't have permission to access /pub/mozilla.org/opus/win32/opus-tools-0.1.3-win32.zip on this server.
Title: IETF Opus codec now ready for testing
Post by: NullC on 2012-07-11 17:46:51
link doesn't work


I prodded the relevant people and its fixed now. Doh.  Read access on a file server?? But someone might read something!
Title: IETF Opus codec now ready for testing
Post by: yourlord on 2012-07-11 19:01:04
Just for grins I downloaded and compiled libopus and opustools..

I then encoded the Dream Theater song Bridges In the Sky from FLAC to opus at 48Kbps.

flac -d --totally-silent -c Dream\ Theater/A\ Dramatic\ Turn\ Of\ Events/05\ -\ Bridges\ In\ The\ Sky.flac | opusenc --music --bitrate 48 - DT_Bridges.opus

(BTW, please try to add FLAC input file support to openenc when you get a chance!)

This was on Xubuntu Oneiric 11.10, 64-bit.

I then decoded the opus file back to wav, compressed it with FLAC and transferred it to my machine at work (did this on a machine at home while I was supposed to be working.. oops).

I'm listening on a Thinkpad T420 using VLC 2.0.2 and a craptastic pair of ear-buds.

I have a local 1st generation Ogg Vorbis -q5 version of the song to compare it to.


With all that said, and the obvious admission this is not ABX, I was definitely able to hear a marked difference between the 2. I was VERY impressed with how well opus did with such a small bitrate budget. While I was able to easily tell the difference between the 2, the quality of the opus encode was surprisingly good, and in some parts of the song it was actually difficult to hear the differences. I'm pretty sure if I bumped opus to 64Kbps I'd be hard pressed to ABX them on this gear. I'll try it with decent headphones when I get home tonight.

As a big fan of Vorbis, I've been watching the progress of this codec with great anticipation and hope it garners significant market share.
I really can't wait till my phone conversations sound crystal clear.

Code: [Select]
~/development$ opusinfo DT_Bridges.opus
Processing file "DT_Bridges.opus"...

New logical stream (#1, serial: 748363d4): type opus
Encoded with libopus 0.9.14
User comments section follows...
        ENCODER=opusenc from opus-tools 0.1.3

Opus stream 1:
        Pre-skip: 356
        Playback gain: 0dB
        Channels: 2
        Original sample rate: 44100Hz
        Packet duration:   20.0ms (max),   20.0ms (avg),   20.0ms (min)
        Page duration:   1000.0ms (max),  999.2ms (avg),  440.0ms (min)
        Total data length: 3797120 bytes (overhead: 1.35%)
        Playback length: 11m:01.426s
        Average bitrate: 45.93 kb/s, w/o overhead: 45.31 kb/s
Logical stream 1 ended

Title: IETF Opus codec now ready for testing
Post by: Speckmade on 2012-07-12 03:16:39
Now is really the time to get support into applications. If there is an application you think should have Opus support that doesn't, especially open source ones, please post about it here and I'll do what I can to coordinate with their authors.

Maybe not an application in the sense you had in mind, but...
Wikipedia and the other Wikimedia projects should support .opus files sooner or later, it seems to me. (With browser support emerging now it's even foreseeable to have them used for inline playback...)
- Wikimedia has a Bugzilla (https://bugzilla.wikimedia.org/) running that seems to be the right place for such requests. Maybe I'll try to file one myself soon if nobody else has felt more qualified or something by then...
Title: IETF Opus codec now ready for testing
Post by: NullC on 2012-07-12 04:42:26
Maybe not an application in the sense you had in mind, but...
Wikipedia and the other Wikimedia projects should support .opus files sooner or later, it seems to me. (With browser support emerging now it's even foreseeable to have them used for inline playback...)
- Wikimedia has a Bugzilla (https://bugzilla.wikimedia.org/) running that seems to be the right place for such requests. Maybe I'll try to file one myself soon if nobody else has felt more qualified or something by then...


It should be a one line configuration change to allow the extension.  But it's probably worth waiting until Firefox ships a version with Opus on by default. In any case I'm pretty qualified to do so.
Title: IETF Opus codec now ready for testing
Post by: punkrockdude on 2012-07-12 11:47:20
Does anyone know and if someone is making an "in_opus.dll" for Foobar2000and if so how it is going? Regards.
Title: IETF Opus codec now ready for testing
Post by: marc2003 on 2012-07-12 14:23:54
http://www.hydrogenaudio.org/forums/index....showtopic=88656 (http://www.hydrogenaudio.org/forums/index.php?showtopic=88656)
Title: IETF Opus codec now ready for testing
Post by: IgorC on 2012-07-12 14:46:39
http://www.hydrogenaudio.org/forums/index....showtopic=88656 (http://www.hydrogenaudio.org/forums/index.php?showtopic=88656)

obsolete, incompatible.
Title: IETF Opus codec now ready for testing
Post by: marc2003 on 2012-07-12 14:52:26
ah sorry, i didn't realise that. but it could still be the place to ask for an update.
Title: IETF Opus codec now ready for testing
Post by: Speckmade on 2012-07-12 15:41:18
It should be a one line configuration change to allow the extension.  But it's probably worth waiting until Firefox ships a version with Opus on by default.

So far they seem to be completely unaware of the new codec.
I guess in the end we definitely want inline playback support, which naturally depends on "player"/browser support, but it may not be essential for support to have inline playback support just yet. Wikimedia Commons is already useful as just a file repository; being able to embed the files directly into wiki pages is a feature on top.
Maybe it is reasonable to wait for player support nevertheless since it is bound to happen soon and we can then have it all at once.
But I was also more thinking in the direction of being ready at official prime time and at least giving them a first hint or so...
(For just that I should maybe rather drop a line on the discussion page of the help page about file format support first.)
Title: IETF Opus codec now ready for testing
Post by: Garf on 2012-07-12 22:04:18
ah sorry, i didn't realise that. but it could still be the place to ask for an update.


Peter is working on it, so foobar2000 will likely have support "soon".
Title: IETF Opus codec now ready for testing
Post by: Clifoo on 2012-07-14 15:08:01
Quote
Now is really the time to get support into applications (well, this was also true for some time, but doubly so now). If there is an application you think should have Opus support that doesn't, especially open source ones, please post about it here and I'll do what I can to coordinate with their authors.

I really hope to see Opus decoder in the following version of Rockbox.
Title: IETF Opus codec now ready for testing
Post by: saratoga on 2012-07-14 21:23:52
Quote
Now is really the time to get support into applications (well, this was also true for some time, but doubly so now). If there is an application you think should have Opus support that doesn't, especially open source ones, please post about it here and I'll do what I can to coordinate with their authors.

I really hope to see Opus decoder in the following version of Rockbox.


Getting a usable decoder in rockbox will probably be a fair amount of work, and right now no one is working on it, so I think it'll be a little longer then that.  But hopefully we'll have it eventually.
Title: IETF Opus codec now ready for testing
Post by: Peter on 2012-07-16 17:24:02
Out-of-the-box Opus support now added to foobar2000 [ download beta version (http://www.foobar2000.org/download) ].
Enjoy.
Title: IETF Opus codec now ready for testing
Post by: LithosZA on 2012-07-16 17:38:14
Quote
Out-of-the-box Opus support now added to foobar2000 [ download beta version ].
Enjoy.
 

AWESOME!
Title: IETF Opus codec now ready for testing
Post by: IgorC on 2012-07-16 17:40:22
Out-of-the-box Opus support now added to foobar2000 [ download beta version (http://www.foobar2000.org/download) ].
Enjoy.

Thank You Very Much!
Title: IETF Opus codec now ready for testing
Post by: eahm on 2012-07-16 21:32:56
So, I didn't follow the development of this codec but I see everyone excited and I have to ask. Why? Is Opus supposed to be the "patent free AAC LC/HE/HEv2" quality as OGG Vorbis was supposed to be the "patent free MP3"?
Title: IETF Opus codec now ready for testing
Post by: mdefranc on 2012-07-16 21:42:49
Why is "everyone excited"?  Because http://listening-tests.hydrogenaudio.org/igorc/results.html (http://listening-tests.hydrogenaudio.org/igorc/results.html)
Title: IETF Opus codec now ready for testing
Post by: NullC on 2012-07-16 21:54:24
So, I didn't follow the development of this codec but I see everyone excited and I have to ask. Why? Is Opus supposed to be the "patent free AAC LC/HE/HEv2" quality as OGG Vorbis was supposed to be the "patent free MP3"?


Opus does that— which is probably most of the excitement here on HA, see also: http://listening-tests.hydrogenaudio.org/igorc/results.html (http://listening-tests.hydrogenaudio.org/igorc/results.html) (and also see my spin on those results (http://people.xiph.org/~greg/opus/ha2011/))— and Opus also has low to very low latency, so it's useful for a whole variety of realtime applications where HE AAC is totally inapplicable, including completely replacing speex.
Title: IETF Opus codec now ready for testing
Post by: eahm on 2012-07-16 22:09:16
So, I didn't follow the development of this codec but I see everyone excited and I have to ask. Why? Is Opus supposed to be the "patent free AAC LC/HE/HEv2" quality as OGG Vorbis was supposed to be the "patent free MP3"?


Opus does that— which is probably most of the excitement here on HA, see also: http://listening-tests.hydrogenaudio.org/igorc/results.html (http://listening-tests.hydrogenaudio.org/igorc/results.html) (and also see my spin on those results (http://people.xiph.org/~greg/opus/ha2011/))— and Opus also has low to very low latency, so it's useful for a whole variety of realtime applications where HE AAC is totally inapplicable, including completely replacing speex.

Awesome, I've read everything and this is going to be amazing. Thank you.
Title: IETF Opus codec now ready for testing
Post by: lvqcl on 2012-07-17 00:00:40
From http://tools.ietf.org/html/draft-terriberry-oggopus-01 (http://tools.ietf.org/html/draft-terriberry-oggopus-01) :

Quote
3.  Else if the hardware's highest available sample rate is less
          than 48 kHz, decode at the highest supported rate above this
          and resample.

I thought it should be "decode at the higher supported rate above this"..?
Title: IETF Opus codec now ready for testing
Post by: IgorC on 2012-07-17 04:36:56
Opus does that— which is probably most of the excitement here on HA, see also: http://listening-tests.hydrogenaudio.org/igorc/results.html (http://listening-tests.hydrogenaudio.org/igorc/results.html) (and also see my spin on those results (http://people.xiph.org/~greg/opus/ha2011/))— and Opus also has low to very low latency, so it's useful for a whole variety of realtime applications where HE AAC is totally inapplicable, including completely replacing speex.

While I'm really happy to see my name in link to that test I'm in favour of that next public tests will be descentralized and transparent as much as possible and won't contain a name of responsable person. This is why it should be  another person next time. Last time the members Steve Forte Rio and /mnt have helped to prepare random process of sample selection (doh, don't mention what Garf has lived to teach me to conduct and helped with the test.) I can organize discussion, prepare packages etc.  The organizator(s) should only work with listeners.
Title: IETF Opus codec now ready for testing
Post by: Steve Forte Rio on 2012-07-17 07:20:52
Where could I get a win32 (or win64) build of the last Opus version?
Title: IETF Opus codec now ready for testing
Post by: Dynamic on 2012-07-17 09:43:50
Post #121 (http://www.hydrogenaudio.org/forums/index.php?showtopic=86580&view=findpost&p=801218) of this thread, is where I got mine.
Title: IETF Opus codec now ready for testing
Post by: adamjk on 2012-07-17 11:18:41
Or even newer from http://opus-codec.org/downloads/ (http://opus-codec.org/downloads/)
Title: IETF Opus codec now ready for testing
Post by: NullC on 2012-07-17 13:15:21
Or even newer from http://opus-codec.org/downloads/ (http://opus-codec.org/downloads/)


The file in post #121 is the experimental encoder. It should deliver much higher quality, on average, though it's less well tested. Feedback is still very much appreciated.
Title: IETF Opus codec now ready for testing
Post by: Dynamic on 2012-07-17 14:32:31
I noticed a few things about the behaviour in playing with opustools (exclusively in --music mode, i.e CELT-derived operation, using Win32 binaries from opus-tools_exp_1a50ad0b.zip, an experimental encoder).

These are not critical listening tests yet. I used the stereo CD format sample provided by Gainless in post #122 (http://www.hydrogenaudio.org/forums/index.php?showtopic=86580&view=findpost&p=801409)

I used a commandline with most things left to default (i.e. 20ms frames, vbr on, no expected packet loss), such as:
opusenc.exe --music --bitrate 48 afterburn.wav test_m048.opus

First, I observed that pushing it to extremes, setting --bitrate 4 and --bitrate 5 produced bit-identical output at about 5.7 kbps actual bitrate. This accords with the low limit being 6 kbps but is nice behaviour for an encoder to do its best when given a non-permitted bitrate.

Effective bandwidth
An apparent lowpass effect seemed to jump in steps with different target bitrate settings. I didn't test to every transition point. This might be to do with the modified bark bands used to transmit coarse band energy information, and where it's worthwhile activating a new band, so may not be a true lowpass. I played back on fb2k v1.1.14 beta 1 with OPUS support built in - thanks Peter - and lowered my preamp for non-ReplayGained material to ensure no clipping or limiting (I could have used the volume control, but already had RG pre-amp set). I resample to 48000 Hz to compare the 44.1kHz source with the 48 kHz OPUS decode on a level playing-field.

for --bitrate settings 5, 6, 8, 10, 12 effective lowpass was about 4kHz (typical AM radio audio bandwidth)

for --bitrate setting 16 it lifted to about 6 kHz (hi-hats really became distinct from the noise)

for --bitrate settings 24, 28, 32, 38, 40, 44, 46, 47, and 47.999 it was about 12 kHz (quite reasonable brightness, fairly crisp hi-hats - similar to standard audio cassette bandwidth - would sound good enough for musical intros and 'stings' in many talk-oriented podcasts, though the beauty of OPUS is seamless switching, so podcasters & radio producers could insert interstitials at higher settings and even use speech mode when it suits them)

for --bitrate setting 48 and on up to 512 kbps there was content to around 20 kHz - i.e. well above the lowpass I can detect in music. The source WAV had minuscule content at 21kHz too, which OPUS didn't output.

Packet loss simulation
The decoder can simulate packet loss.

I took the file test_m048.opus which I'd created using this commandline:

opusenc.exe --music --bitrate 48 afterburn.wav test_m048.opus

i.e. without indicating an expected packet loss to the encoder - the normal setting for local playback on a PC or player.

The decoder with simulated packet loss reported an error at 0.2% packet loss and above but still produced a WAV (with a beep/blip in it at 0.2% and 146 samples@44.1kHz shorter in duration).

But at 0.1% simulated packet loss, it produced no error message and produced a pretty nice sounding output WAV. Presumably if the encoder is told to expect n% packet loss (--expect-loss n), it will be more resilient at the expense of quality of perfect playback compared to the default setting at the same bitrate. I may need to test that, but I'll probably get the latest build first.

It may be that I was lucky with 0.1% packet loss, but given 1501 packets used for this sample, there should be about 15 packets dropped at random on average, so I suspect there must be a little resilience built in even when no extra is requested from the encoder.

I might try various expected loss scenarios later and see how they compare. Could be useful to try out marginal radio links to see how gracefully quality would tail off. In many applications, I'd imagine that a warning indicator or tone could indicate packet loss has started, yet OPUS wouldn't suddenly drop out, which could be useful for real-time applications, such as radio microphones and digital radio broadcast receivers.

For future digital radio, it might be rather useful to have packet-loss or packet-corruption resilience of this sort. I guess ideally it could be coupled with the physical layer, to broadcast a basic low-bitrate stream over a highly-error-corrected longer-range multiplex for areas of weak reception, with a more bandwidth-efficient but less resilient scheme packing in either a higher-bitrate alternative stream (or if bitrate peeling is possible, a difference stream) to provide high quality for those near the transmitter or with high-grade rooftop aerials further afield.

Simulated packet loss Command Prompt window:
Code: [Select]
C:\Users\Public\Music\Test>"C:\Program Files\opus\opusdec.exe" --packet-loss 0.1
test_m048.opus test_m048_pl00_1.wav
Decoding 44100 Hz audio (2 channels)
Encoded with libopus 0.9.11-119-g1a50ad0-exp_analysis
ENCODER=opusenc from opus-tools 0.1.2-7-g1f30973


C:\Users\Public\Music\Test>"C:\Program Files\opus\opusdec.exe" --packet-loss 0.5
test_m048.opus test_m048_pl00_5.wav
Decoding 44100 Hz audio (2 channels)
Encoded with libopus 0.9.11-119-g1a50ad0-exp_analysis
ENCODER=opusenc from opus-tools 0.1.2-7-g1f30973

Error playing audio.

C:\Users\Public\Music\Test>"C:\Program Files\opus\opusdec.exe" --packet-loss 0.2
test_m048.opus test_m048_pl00_2.wav
Decoding 44100 Hz audio (2 channels)
Encoded with libopus 0.9.11-119-g1a50ad0-exp_analysis
ENCODER=opusenc from opus-tools 0.1.2-7-g1f30973

Error playing audio.

C:\Users\Public\Music\Test>
Title: IETF Opus codec now ready for testing
Post by: Steve Forte Rio on 2012-07-17 15:40:21
Why don't it push down bitrate to zero for silenced moments? Actually VBR mode is absolutely not flexible (+/- 10 kbps). Seems like this vbr is not true vbr :\

Also: why does it encode all files with  48000 Hz samplerate?
Title: IETF Opus codec now ready for testing
Post by: IgorC on 2012-07-17 16:03:45
I have tried this https://people.xiph.org/~greg/opus-tools_exp.zip (https://people.xiph.org/~greg/opus-tools_exp.zip) and it goes down to 1 kbps on silence.
Title: IETF Opus codec now ready for testing
Post by: Gainless on 2012-07-17 16:27:21
Opus does that— which is probably most of the excitement here on HA, see also: http://listening-tests.hydrogenaudio.org/igorc/results.html (http://listening-tests.hydrogenaudio.org/igorc/results.html) (and also see my spin on those results (http://people.xiph.org/~greg/opus/ha2011/))— and Opus also has low to very low latency, so it's useful for a whole variety of realtime applications where HE AAC is totally inapplicable, including completely replacing speex.

While I'm really happy to see my name in link to that test I'm in favour of that next public tests will be descentralized and transparent as much as possible and won't contain a name of responsable person. This is why it should be  another person next time. Last time the members Steve Forte Rio and /mnt have helped to prepare random process of sample selection (doh, don't mention what Garf has lived to teach me to conduct and helped with the test.) I can organize discussion, prepare packages etc.  The organizator(s) should only work with listeners.


It would be interesting to know what the requirements for the inclusion of a specific sample into a listening test are. Does it have to be some kind of "killer" sample or representative for a certain music genre?
Title: IETF Opus codec now ready for testing
Post by: lvqcl on 2012-07-17 16:29:15
The file in post #121 is the experimental encoder. It should deliver much higher quality, on average, though it's less well tested. Feedback is still very much appreciated.

Here is the sample where experimental encoder fails at --bitrate 64: [attachment=7058:test01.mp3]
Title: IETF Opus codec now ready for testing
Post by: db1989 on 2012-07-17 16:43:55
Dynamic:
0.1% of 1501 is 1.501, not 15.01 as you said, so your “luck” is not as good as you might have thought.
Interesting write-up, though!
Title: IETF Opus codec now ready for testing
Post by: zima on 2012-07-17 17:00:11
Quote
Now is really the time to get support into applications (well, this was also true for some time, but doubly so now). If there is an application you think should have Opus support that doesn't, especially open source ones, please post about it here and I'll do what I can to coordinate with their authors.

I really hope to see Opus decoder in the following version of Rockbox.

Getting a usable decoder in rockbox will probably be a fair amount of work, and right now no one is working on it, so I think it'll be a little longer then that.  But hopefully we'll have it eventually.

I hope for that too, considering the listening tests. And, searching for "Opus" on Rockbox website, it seems the project is at least more or less aware of the new codec...

BTW, promising quality is clear enough, but how to interpret its performance goals in the context of offline playback on a portable audio player? (http://www.rockbox.org/wiki/CodecPerformanceComparison) What can be roughly expected, relative to other low-bitrate codecs supported by Rockbox?
Title: IETF Opus codec now ready for testing
Post by: NullC on 2012-07-17 19:28:07
Why don't it push down bitrate to zero for silenced moments?


It does, on digital silence. On non-digital "silence" (very quiet but not all zeros) it doesn't know if perhaps the decoder side will be turning the volume up to compensate for the low gain. Outputting silence frames in that case would destroy the quality.

Quote
Actually VBR mode is absolutely not flexible (+/- 10 kbps). Seems like this vbr is not true vbr :\


You're looking at overall files. VBR uses significantly more bits on transient frames, but on the span of a whole file it doesn't matter much.

The EXP encoder significantly increases the VBRness of VBR, with rate modifications depending on more than just transients.

Quote
Also: why does it encode all files with  48000 Hz samplerate?


Opus doesn't really have a "sampling rate" (unless you want to count the 16Hz,25,50,100,200,400Hz frame rates ) there are several rates which can be most efficiently encoded or decoded from which are all integer relative to 48000— 8000,12000,16000,24000, and 48000, so those are what the libopus library exposes. The rates of the encoder and decoder are independent and don't change the bitstream (except presumably a 8kHz encoder wouldn't be encoding sound at 20kHz)— this eliminates rate incompatibilities, rate negotiation, makes smaller decoder (lower memory footprint) implementations possible, etc.  But it does mean that rates like 44.1kHz need to be reached by resampling. Considering how much audio hw out there sounds like crud at 44.1kHz this is probably just as well.

.Opus files store the original rate, so that file tools can avoid surprising users with decoded files that change rate. The _exact_ file durations are also preserved for all rates 48k and below including 44.1k.
Title: IETF Opus codec now ready for testing
Post by: saratoga on 2012-07-17 19:34:54
BTW, promising quality is clear enough, but how to interpret its performance goals in the context of offline playback on a portable audio player? (http://www.rockbox.org/wiki/CodecPerformanceComparison) What can be roughly expected, relative to other low-bitrate codecs supported by Rockbox?


I'm not sure.  From what I've seen its a fairly unique codec, so I'm not sure what to compare it to. My guess is that initially it will be fairly slow since I don't see much ARM optimization in the source, but people will work on it and speed things up.  FLAC was the same way, it used to be very slow.  Now we can decode it in about 10 Mhz worth of CPU on lots of targets.
Title: IETF Opus codec now ready for testing
Post by: NullC on 2012-07-17 19:43:44
I noticed a few things about the behaviour in playing with opustools (exclusively in --music mode, i.e CELT-derived operation, using Win32 binaries from opus-tools_exp_1a50ad0b.zip, an experimental encoder).

Great.

FWIW  --music does _not_ mean "use CELT". It shifts the bitrates at which it will use CELT a bit lower... but at low enough rates you're better off with the LP modes even for music.
Quote
First, I observed that pushing it to extremes, setting --bitrate 4 and --bitrate 5 produced bit-identical output at about 5.7 kbps actual bitrate. This accords with the low limit being 6 kbps but is nice behaviour for an encoder to do its best when given a non-permitted bitrate.

CBR will actually obey your requests, though you'll end up getting silence if you go too low.
Quote
But at 0.1% simulated packet loss, it produced no error message and produced a pretty nice sounding output WAV. Presumably if the encoder is told to expect n% packet loss (--expect-loss n), it will be more resilient at the expense of quality of perfect playback compared to the default setting at the same bitrate. I may need to test that, but I'll probably get the latest build first.

The decoder has loss concealment, and it works pretty well. You an get pretty intelligible audio with fairly high random loss rates. A main application for Opus is realtime e.g. RTP usage, so the loss concealment is pretty important there. Though the simulation of it is a bit odd in opusdec and I probably ought to improve that.

You actually triggered a bug in opus-tools causing the "Error playing audio." on Win32, on files with certain durations when decoding to a file (rather than audio output), which I just fixed. Thanks for the testing.
Title: IETF Opus codec now ready for testing
Post by: Garf on 2012-07-17 20:21:09
The file in post #121 is the experimental encoder. It should deliver much higher quality, on average, though it's less well tested. Feedback is still very much appreciated.

Here is the sample where experimental encoder fails at --bitrate 64: [attachment=7058:test01.mp3]


Good find, thanks.
Title: IETF Opus codec now ready for testing
Post by: Gainless on 2012-07-17 20:40:21
Opus seems to have problems at certain points of time when encoding with 64 kbit/s + framesize 60. I've had 2 samples with obvious bugs at 2:00 that disappeared when I cut these moments out in Audacity and encoded it again. Is that behaviour normal/expected?
Title: IETF Opus codec now ready for testing
Post by: NullC on 2012-07-17 20:59:16
Opus seems to have problems at certain points of time when encoding with 64 kbit/s + framesize 60. I've had 2 samples with obvious bugs at 2:00 that disappeared when I cut these moments out in Audacity and encoded it again. Is that behaviour normal/expected?


Details please.  What version of the software are you using? Can you post test inputs and command-lines (and the .opus output would be nice too).  There was a bug in old opus-tools that would cause something like that, but I'm not aware of anything currently.
Title: IETF Opus codec now ready for testing
Post by: IgorC on 2012-07-18 01:24:57
Actually VBR mode is absolutely not flexible (+/- 10 kbps). Seems like this vbr is not true vbr :\

Opus experimental build  VBR 96 kbps, 243 files:
min 61 kbps
max 157 kbps
average 92 kbps.




Title: IETF Opus codec now ready for testing
Post by: Caroliano on 2012-07-18 06:22:43
I'm finally testing it!

If I try encoding at 2kbps, VBR or CBR, at anything other than 20ms packets (I tested 10ms and 60ms), the encoder fails. And more than that, it reports a successful encode, with crazy speed like that:

Code: [Select]
F:\Test\Opus\opus-tools_exp_1a50ad0b\opus-tools>opusenc --hard-cbr --bitrate 2
--framesize 60 t1.wav t1-cbr-2kbps-60ms.opus
Encoding using libopus 0.9.11-119-g1a50ad0-exp_analysis (audio)
-----------------------------------------------------
   Input: 48kHz 2 channels
  Output: 2 channels (2 coupled)
          60ms packets, 2kbit/sec CBR
Preskip: 312

Encoding complete
-----------------------------------------------------
    Encoded: 29 minutes and 4.8 seconds
    Runtime: 0.6471 seconds
             (2696x real-time)
      Wrote: 107430 bytes, 29080 packets, 1820 pages
    Bitrate: 0.133333kbit/s (without overhead)
Rate range: 0.133333kbit/s to 0.133333kbit/s
             (1 to 1 bytes per packet)
   Overhead: 72.9% (container+metadata)

At 3kbps things already run fine with with all modes that I tested.

BTW, how do I know if Opus is using the Silk or Celt mode for encoding? I don't see this info in the opusenc or opusinfo. It would be good to know, especially if it overrides your choice. I don't want to memorize a table with the heuristics/allowed combinations (even thought I may end up memorizing it).

It seems that the minimum bitrate supported is indeed 6~7kbps. Even at this bitrate the voices are still very clear, and the music gets interesting analog-like noise/artifacts (better than metallic sound of most codecs close to their limits). 60ms packets are better overall at those bitrates.  But if I try to force it under that with --hard-cbr it falls completely apart... That means I can't put 50 minutes of audio in a floppy, like AAC and speex could (well, AAC was also a train-wreck at 2~3kbps, but still better than opus)...

One less way I can show off opus, but don't really impact in practical uses.   
Title: IETF Opus codec now ready for testing
Post by: LigH on 2012-07-18 07:45:59
Now that Opus was approved by the IETF, will it also appear on RareWares? -- poking john33
Title: IETF Opus codec now ready for testing
Post by: LigH on 2012-07-18 10:09:24
Editing own messages is time-limited?

Well, so – P.S.:

john33 is currently away, but certainly interested.
Title: IETF Opus codec now ready for testing
Post by: db1989 on 2012-07-18 10:31:27
Editing own messages is time-limited?
Yes, to one hour. For information refer to the uppermost pinned thread in Site Related Discussion.

You can request later edits from staff (within reason!) via the report button, assuming you’re not worried that readers might not go back and notice the updates; due to that risk, including new information in a new post rather than editing might be preferable, and sequential posts can be justified in such cases.
Title: IETF Opus codec now ready for testing
Post by: LigH on 2012-07-18 10:39:10
Okay. Some boards optimize for size, some for speed. 
__

P.S.:

If you are looking for very nasty test samples to optimize encoder quality:

From my experience, "Peter Heppner: Twelve" from the EP "Witt, Heppner: Die Flut" has everything psychoacoustic audio codecs hate.
Title: IETF Opus codec now ready for testing
Post by: Garf on 2012-07-18 13:24:48
BTW, how do I know if Opus is using the Silk or Celt mode for encoding? I don't see this info in the opusenc or opusinfo. It would be good to know, especially if it overrides your choice. I don't want to memorize a table with the heuristics/allowed combinations (even thought I may end up memorizing it).


You should presume this to be variable per frame and signal dependent. (The reference encoder uses some formulas based on bitrate and the passed switches, but that is likely to change soon)

Quote
But if I try to force it under that with --hard-cbr it falls completely apart... That means I can't put 50 minutes of audio in a floppy, like AAC and speex could (well, AAC was also a train-wreck at 2~3kbps, but still better than opus)...

One less way I can show off opus, but don't really impact in practical uses.   


You can generate Opus files at 1.5kbps. The problem seem to be with overriding framesize = 60, will investigate.
Title: IETF Opus codec now ready for testing
Post by: Garf on 2012-07-18 13:26:08
If you are looking for very nasty test samples to optimize encoder quality:

From my experience, "Peter Heppner: Twelve" from the EP "Witt, Heppner: Die Flut" has everything psychoacoustic audio codecs hate.


Are there actual issues when Opus encodes this sample or did you just throw this randomly out there?
Title: IETF Opus codec now ready for testing
Post by: LigH on 2012-07-18 13:50:13
All codecs have issues with this song when the bitrate drops, more or less in different parts. I tried to get as low as 48 kbps, and for a specific sound, Opus sounds worse than Vorbis and QAAC — but only with bitrates as low as 48 kbps; Ogg Vorbis aoTuV b6.03 had do be pressed down to a quality below 0 to reach this average rate. At ~64 kbps (VBR), they all sound already surprisingly satisfying.

BTW: Is it intentional that foobar2000 plays Opus audio files at 48.0 kHz, although the original WAV had 44.1 kHz? opusinfo reports "Original sample rate: 44100Hz".
Title: IETF Opus codec now ready for testing
Post by: NullC on 2012-07-18 14:00:48
You should presume this to be variable per frame and signal dependent. (The reference encoder uses some formulas based on bitrate and the passed switches, but that is likely to change soon)

It also isn't either-or, it can and does use both at once. Opus isn't two codecs behind one executable, it's one codec with multiple parts.

The --save-range diagnostic knobs in opusdec/opusenc will tell you what its using.
Title: IETF Opus codec now ready for testing
Post by: Garf on 2012-07-18 14:07:54
BTW: Is it intentional that foobar2000 plays Opus audio files at 48.0 kHz, although the original WAV had 44.1 kHz? opusinfo reports "Original sample rate: 44100Hz".


Yes, that's by design. Opus is always internally encoded at 48kHz, and there's no reason for the decoder to resample back if it can output that rate. (Might be handy if fb2k could report the original rate somewhere in the properties)
Title: IETF Opus codec now ready for testing
Post by: db1989 on 2012-07-18 14:29:34
Quote
Okay. Some boards optimise for size, some for speed. 
I don't follow. Is this meant to imply that the staff at that time sacrificed one for the other, and chose wrongly to boot? I think not. Neither factor appears to be relevant to Hydrogenaudio's time limit, the reasons for which are clearly explained in the thread that I cited. If you still have opinions on this, please direct them there.
Title: IETF Opus codec now ready for testing
Post by: LigH on 2012-07-18 14:40:04
@ db1989:

Just a joke. There are boards with rules like "Do not post just to raise your post count", and that kind of "size optimization" made me smirk about similar compiler options. Nothing serious, just my way of skipping a few steps while thinking. I love thought-leaps.

The loss of "bulk erase" actions by unhappy members is sadly known to me.
__

@ all:

The experimental build (https://people.xiph.org/~greg/opus-tools_exp.zip) created a slightly bigger output on that mentioned test song "Twelve" at a 48 kbps target. But it sounded better for the mentioned part of the song (background cymbals at ~0:55 to ~1:05), on par again with the competitors.
Title: IETF Opus codec now ready for testing
Post by: IgorC on 2012-07-18 14:50:24
BTW, I was playing with intensity stereo (IS) and have found Opus's IS is considerably less lossy (better) than MP3's or Vorbis'es IS. The IS is set to 16 at 64 kbps by default (16th higher band). More agressive IS 14 was considerably better for my ears (less artifacts at cost of a bit more lossy stereo).
Also default IS'es setting at 96 kbps is optimal to my taste while it's really hard to judge a final effect at >96 kbps (have tested it at 128 kbps). IS should be useful up to ~128 kbps.
Title: IETF Opus codec now ready for testing
Post by: LithosZA on 2012-07-18 15:48:45
Quote
BTW, I was playing with intensity stereo (IS) and have found Opus's IS is considerably less lossy (better) than MP3's or Vorbis'es IS. The IS is set to 16 at 64 kbps by default (16th higher band). More agressive IS 14 was considerably better for my ears (less artifacts at cost of a bit more lossy stereo).
Also default IS'es setting at 96 kbps is optimal to my taste while it's really hard to judge a final effect at >96 kbps (have tested it at 128 kbps). IS should be useful up to ~128 kbps.

Is it possible to set the IS setting with opusenc?
Title: IETF Opus codec now ready for testing
Post by: Caroliano on 2012-07-18 16:17:17
BTW, how do I know if Opus is using the Silk or Celt mode for encoding? I don't see this info in the opusenc or opusinfo. It would be good to know, especially if it overrides your choice. I don't want to memorize a table with the heuristics/allowed combinations (even thought I may end up memorizing it).


You should presume this to be variable per frame and signal dependent. (The reference encoder uses some formulas based on bitrate and the passed switches, but that is likely to change soon)

Right. Still, it would be interesting to show "xx% Celt, xx% Silk" in the final encode status, and in the info (where it already shows max, avg and min framesize, for example).
You can generate Opus files at 1.5kbps. The problem seem to be with overriding framesize = 60, will investigate.

Yep, with framesize = 20 I could generate those 2kbps Opus files, but not 10ms or 60ms frame sizes. But by "falls apart" I meant that the quality suffered A LOT by going under 6kbps. At 6kbps, it was clearly superior to AAC, for voice, but at 3kbps it was clearly inferior, even with 60ms frame size.

Well, now I'm going to test at saner bitrates, and with music.
Title: IETF Opus codec now ready for testing
Post by: Garf on 2012-07-18 18:04:39
Quote
BTW, I was playing with intensity stereo (IS) and have found Opus's IS is considerably less lossy (better) than MP3's or Vorbis'es IS. The IS is set to 16 at 64 kbps by default (16th higher band). More agressive IS 14 was considerably better for my ears (less artifacts at cost of a bit more lossy stereo).
Also default IS'es setting at 96 kbps is optimal to my taste while it's really hard to judge a final effect at >96 kbps (have tested it at 128 kbps). IS should be useful up to ~128 kbps.

Is it possible to set the IS setting with opusenc?


No. I'm working on making this and some other important parameters available via opusenc settings, check this thread in a few days.
Title: IETF Opus codec now ready for testing
Post by: Garf on 2012-07-18 18:10:12
Yep, with framesize = 20 I could generate those 2kbps Opus files, but not 10ms or 60ms frame sizes. But by "falls apart" I meant that the quality suffered A LOT by going under 6kbps. At 6kbps, it was clearly superior to AAC, for voice, but at 3kbps it was clearly inferior, even with 60ms frame size.


Note that "officially" 6kbps is the lowest supported rate. At lower rates it's just not encoding frames of the audio at all and requesting the decoder to interpolate/predict between the ones it did.
Title: IETF Opus codec now ready for testing
Post by: NullC on 2012-07-18 18:59:15
Note that "officially" 6kbps is the lowest supported rate. At lower rates it's just not encoding frames of the audio at all and requesting the decoder to interpolate/predict between the ones it did.


Technically MDCT mode CBR can go down to 1 byte of codec payload (two bytes total) per packet while encoding "something". But that something is not very useful and at very low rates Opus will have already switched to the LP mode and the current LP mode encoder cant really produce under 6 kbit/sec or so, and would take a pretty substantial rewrite to do so (much less do so usefully).

At 20ms frames 2kbit/sec is 5 bytes. We're losing one byte to signal the mode.  There isn't a lot you can say about the audio with only 4 bytes, even codec2 uses frames of twice that size (though at a lower framerate), especially with encoding designed for higher rates.  And— of course as soon as you transmit it across any packet network you end up with several times that size in overhead.

Terribly quality at silly low bitrates?  This is not the codec you are looking for.
Title: IETF Opus codec now ready for testing
Post by: darkbyte on 2012-07-18 23:56:55
Thank you for the Foobar plugin! I can finally test the codec in the long run
I've also created a codec support request topic in PowerAMP's forum: http://forum.powerampapp.com/index.php?/to...469-opus-codec/ (http://forum.powerampapp.com/index.php?/topic/3469-opus-codec/) Maybe some of you are interested in that aswell.
Title: IETF Opus codec now ready for testing
Post by: Gainless on 2012-07-19 11:31:47
Opus seems to have problems at certain points of time when encoding with 64 kbit/s + framesize 60. I've had 2 samples with obvious bugs at 2:00 that disappeared when I cut these moments out in Audacity and encoded it again. Is that behaviour normal/expected?


Details please.  What version of the software are you using? Can you post test inputs and command-lines (and the .opus output would be nice too).  There was a bug in old opus-tools that would cause something like that, but I'm not aware of anything currently.


Metadata says it's version "0.1.3-12-g07d15f6". Command lines were "--bitrate 64 --framesize 60" at encoding and "--rate 48000" at decoding. Not sure what you mean with "test input" and "opus output". Shall I post samples or frequency graphs?
Title: IETF Opus codec now ready for testing
Post by: lvqcl on 2012-07-19 13:05:08
From my experience, "Peter Heppner: Twelve" from the EP "Witt, Heppner: Die Flut" has everything psychoacoustic audio codecs hate.

Is it this sample (http://www.rarewares.org/test_samples/Twelve.wv)?
Title: IETF Opus codec now ready for testing
Post by: NullC on 2012-07-19 13:24:35
Metadata says it's version "0.1.3-12-g07d15f6". Command lines were "--bitrate 64 --framesize 60" at encoding and "--rate 48000" at decoding. Not sure what you mean with "test input" and "opus output". Shall I post samples or frequency graphs?


Post a link to some input audio, please. I don't need graphs, just a way to easily reproduce what you're seeing without guessing if I'm seeing the same thing or not. I'll fix it as soon as I can reproduce it.
Title: IETF Opus codec now ready for testing
Post by: LigH on 2012-07-19 13:43:20
From my experience, "Peter Heppner: Twelve" from the EP "Witt, Heppner: Die Flut" has everything psychoacoustic audio codecs hate.

Is it this sample (http://www.rarewares.org/test_samples/Twelve.wv)?

Yes, I sent Roberto Amorim the song a few years ago.
Title: IETF Opus codec now ready for testing
Post by: Gainless on 2012-07-19 14:14:46
Metadata says it's version "0.1.3-12-g07d15f6". Command lines were "--bitrate 64 --framesize 60" at encoding and "--rate 48000" at decoding. Not sure what you mean with "test input" and "opus output". Shall I post samples or frequency graphs?


Post a link to some input audio, please. I don't need graphs, just a way to easily reproduce what you're seeing without guessing if I'm seeing the same thing or not. I'll fix it as soon as I can reproduce it.


I could post the whole track where the bug appears or a 2 - 3 minute sample of it, but that's not allowed here and a shorter one wouldn't be useful as the bug only appears if you encode the track from the beginning to at least the second minute (at 2:00 like I've mentioned before).
Title: IETF Opus codec now ready for testing
Post by: Gainless on 2012-07-19 19:24:18
Btw, is it intentioned that encodes with the framesizes 20 and 60 are bit-identical? It's pretty weird, the bitrate range differs but the output is the same.
Title: IETF Opus codec now ready for testing
Post by: IgorC on 2012-07-19 19:39:36
Overhead changes while audio data is the same.
Title: IETF Opus codec now ready for testing
Post by: 2012 on 2012-07-19 19:44:21
Btw, is it intentioned that encodes with the framesizes 20 and 60 are bit-identical? It's pretty weird, the bitrate range differs but the output is the same.


It's not weird.

A 60ms frame is just 3 20ms frames bundled together. This is only useful in low rates where overhead becomes more significant.

Ranges differ (usually less varying) because the info is derived from dividing over 60ms not 20ms. So It's like an average for the 3 bundled frames.
Title: IETF Opus codec now ready for testing
Post by: softrunner on 2012-07-19 21:20:48
When I convert audio sample from here (http://www.hydrogenaudio.org/forums/index.php?showtopic=96108) into 32 kbps using opusenc.exe from opus-tools_exp_1a50ad0b.zip via command line "opusenc.exe --bitrate 32 Fighter_Beat_Loop.wav Fighter_Beat_Loop_32.opus", it gives a file, which sounds wrong. When adding "--music" to the command line, it is ok. I think there must be some bug in hybrid mode.
Title: IETF Opus codec now ready for testing
Post by: rt87 on 2012-07-20 01:48:11
I'm thinking about writing/make it working as decoder plugin for ancient ARM WinCE devices (as GSPlayer plugin), and I have some qurstions:
- Does Opus works integer-only? (soft-float is slow in such devices)
- Does Opus compiles with eVC 4.0? (I haven't tried yet, just want to confirm if no new compiler-specified features are used)
- Any simple example for play/stop/seek/etc., when comparing with Vorbis Tremor? (GSPlayer uses Tremor for Vorbis decoding, so it can be used as reference)
Title: IETF Opus codec now ready for testing
Post by: NullC on 2012-07-20 04:22:32
- Does Opus works integer-only? (soft-float is slow in such devices)

Yes.
Quote
- Does Opus compiles with eVC 4.0? (I haven't tried yet, just want to confirm if no new compiler-specified features are used)

It should work with any C89 compliant toolchain that also provides a 64-bit type.  You may have to twiddle around with the build system, and setup the relevant system specific defines/project files.
Quote
- Any simple example for play/stop/seek/etc., when comparing with Vorbis Tremor? (GSPlayer uses Tremor for Vorbis decoding, so it can be used as reference)

Libopus doesn't have a vorbisfile level interface, and no such high level interface exists currently. Libopus takes packets of opus data and returns PCM, the rest is up to the application.
Title: IETF Opus codec now ready for testing
Post by: Speckmade on 2012-07-21 08:11:43
Now is really the time to get support into applications (well, this was also true for some time, but doubly so now).  If there is an application you think should have Opus support that doesn't, especially open source ones, please post about it here and I'll do what I can to coordinate with their authors.

Quod Libet (http://quodlibet.googlecode.com/)
I don't have an idea how relevant this one is - but support seems around the corner given that it uses GStreamer as backend.
Title: IETF Opus codec now ready for testing
Post by: lazka on 2012-07-21 12:30:28
Quod Libet (http://quodlibet.googlecode.com/)
I don't have an idea how relevant this one is - but support seems around the corner given that it uses GStreamer as backend.


GStreamer is in a transition to a new (ABI incompatible) release and we have to move to GTK+ 3/PyGObject before we can support that. So, if they don't backport it to the old version, don't expect support soon.

For tagging:
http://code.google.com/p/quodlibet/issues/detail?id=1012 (http://code.google.com/p/quodlibet/issues/detail?id=1012)
http://code.google.com/p/mutagen/issues/detail?id=115 (http://code.google.com/p/mutagen/issues/detail?id=115)
Title: IETF Opus codec now ready for testing
Post by: 2012 on 2012-07-21 13:49:16
Opus is already supported in released gstreamer0.10 (part of gst-plugins-bad). Packages shipped by distros today probably won't have it though.

I might bug Archlinux maintainers to package Opus and rebuild the relevant gstreamer package (If Opus developers think that's a good idea). This is simple for Arch because they already ship latest stable versions of everything. But it's not that simple for other distros.

I tested with audition, a console player that uses gstreamer as a backend, and OggOpus files are played without any issues.

EDIT: Forgot to mention that Opus works with webkit-gtk browsers already if Opus is enabled in gstreamer. And Firefox of course (FF will use gstreamer for Opus support when built with gst).
Title: IETF Opus codec now ready for testing
Post by: lazka on 2012-07-21 15:05:17
Opus is already supported in released gstreamer0.10 (part of gst-plugins-bad). Packages shipped by distros today probably won't have it though.


Ah, I should have checked first. It's also in debian testing. Thanks for the info.
Title: IETF Opus codec now ready for testing
Post by: Speckmade on 2012-07-21 23:44:34
Now is really the time to get support into applications. If there is an application you think should have Opus support that doesn't, especially open source ones, please post about it here and I'll do what I can to coordinate with their authors.

SFLphone (http://sflphone.org/) may well be the most promising SIP(/IAX2) softphone I've seen so far. They already had CELT supported - now I don't know what to think. They kicked it out in order to replace it with Opus - but the feature request for Opus support (https://projects.savoirfairelinux.com/issues/11884) was closed 15 days ago as "rejected" and on the mailing list the most recent message (http://lists.savoirfairelinux.net/pipermail/sflphone/2012-July/001142.html) asks for G.729 because of increased efficiency. There's another, older ticket (https://projects.savoirfairelinux.com/issues/9817) from April though that is still open but no other sign of activity regarding Opus integration since then. (Maybe the feature request was rejected because of being a duplicate of the older ticket? Anyways...)
Maybe they at least need some updates..?
Title: IETF Opus codec now ready for testing
Post by: LigH on 2012-07-22 01:05:06
LameXP (http://lamexp.sourceforge.net/) supports Opus. LameXP v4.05 Alpha-9 even adds Unicode support (https://raw.github.com/lordmulder/LameXP/master/etc/Patches/OpusTools-Git20120721-UTF8+Flush.diff).
Title: IETF Opus codec now ready for testing
Post by: NullC on 2012-07-22 23:52:17
LameXP (http://lamexp.sourceforge.net/) supports Opus. LameXP v4.05 Alpha-9 even adds Unicode support (https://raw.github.com/lordmulder/LameXP/master/etc/Patches/OpusTools-Git20120721-UTF8+Flush.diff).


Thanks for the link!  I've now taken those unicode patches upstream, and prodded the author to also write unicode output support.  I was dimly aware that windows hadn't gone the route of UTF-8 like sane operating systems, but I hadn't even realized that it had implications for simple command-line apps.
Title: IETF Opus codec now ready for testing
Post by: bawjaws on 2012-07-23 09:46:20
CyanogenMod is analagous to rockbox for android smartphones, and I seem to recall they were early with FLAC support, perhaps they'd be interested in getting Opus in CM10? The low-bitrate quality for music and audiobooks seems highly suited to portable devices.
Title: IETF Opus codec now ready for testing
Post by: lazka on 2012-07-23 13:55:48
Quod Libet (http://quodlibet.googlecode.com/)
I don't have an idea how relevant this one is - but support seems around the corner given that it uses GStreamer as backend.


EF/QL unstable Ubuntu/Debian packages [1] now support Ogg Opus.

[1] http://code.google.com/p/quodlibet/wiki/Do...velopment_build (http://code.google.com/p/quodlibet/wiki/Downloads#Current_development_build)
Title: IETF Opus codec now ready for testing
Post by: NullC on 2012-07-24 14:05:44
I've put up  a new build of the experimental encoder (https://people.xiph.org/~greg/opus-tools_exp_bfabfd38.zip).

The new encoder fixes some regressions like the test01.mp3 linked earlier in this thread. We could use some more examples of files where it does a worse job than the normal releases in order to continue improving it. This build also has a number of improvements in the command-line utilities including win32 unicode support and the use of SSE in the resampler.
Title: IETF Opus codec now ready for testing
Post by: Shinigami on 2012-07-24 17:17:44
I have a question for NullC regarding an Opus files' bitrate relative to its bitrate setting -- I have noticed that the average bitrate for many opus files is significantly (in my opinion) lower than its bitrate setting.

For example, I've been testing the setting "--music --bitrate 128 %s %d" in foobar2000, using the experimental build posted in NullC's latest post and have found that many files have an average bitrate of between 110 and 118 and very few files getting closer than that to its target bitrate. I've also tried using the non-experimental build and the bitrates tend to be much closer to the target of 128. I've also tried changing the bitrate to 160 to see what the results were, and I noticed the average on most files likes to hover around ~146-147 or so. In comparison the latest version of AoTuV is very close, if not slightly higher, than its target in most cases. I'm mostly looking at rock/metal as a genre.

Is it intended for bitrates to be this low relative to the target? Will bitrates be further tuned to be closer to its target bitrate?
Title: IETF Opus codec now ready for testing
Post by: NullC on 2012-07-24 19:16:21
if not slightly higher, than its target in most cases. I'm mostly looking at rock/metal as a genre.
Is it intended for bitrates to be this low relative to the target? Will bitrates be further tuned to be closer to its target bitrate?

The current exp code is roughly calibrated to give the requested bitrate on a fairly broad set of samples.
Rock/metal are usually fairly easy to code and come out a bit lower.  We'll probably increase the transient boost back a bit closer to the levels in master which will increase rock/metal a bit but I'd expect you to continue get somewhat lower rate if thats all you're coding.
Title: IETF Opus codec now ready for testing
Post by: Shinigami on 2012-07-24 19:30:53
Thanks for the the response! I have taken a look at a few other genres of music that I own, namely electronic and neoclassical, and have notice much more variability in the bitrates of those samples. In most cases those appear to average out higher (130-135) bitrates.
Title: IETF Opus codec now ready for testing
Post by: kode54 on 2012-07-24 20:05:39
I've been testing the setting "--music --bitrate 128 %s %d" in foobar2000

Please use "--music --bitrate 128 - %d" instead, as it should result in faster conversion. It won't affect the quality in any way, though.
Title: IETF Opus codec now ready for testing
Post by: lvqcl on 2012-07-24 20:26:37
opusenc writes '\n' in the end of the ENCODER tag: "opusenc from opus-tools 0.1.3-30-gd1354fe\n". IMHO there's no point in it.
Title: IETF Opus codec now ready for testing
Post by: NullC on 2012-07-24 20:31:07
opusenc writes '\n' in the end of the ENCODER tag: "opusenc from opus-tools 0.1.3-30-gd1354fe\n". IMHO there's no point in it.

Thanks, fixed.
Title: IETF Opus codec now ready for testing
Post by: NullC on 2012-07-25 06:54:14

I'm happy to be posting a new update to the experimental encoder:  opus-tools_exp_32024cb5.zip (https://people.xiph.org/~greg/opus-tools_exp_32024cb5.zip).
This update has two important tuning improvements:
(1) It makes the decision to drop the rate on frames with high left/right correlation less trigger happy which fixes the glitch reported up-thread by Gainless.
(2) It increases the rate boost on frames with transients somewhat (Exp had substantially reduced this boost compared to master).  This greatly improves some regressions which IgorC discovered that exp had on transient torture samples.
Title: IETF Opus codec now ready for testing
Post by: LigH on 2012-07-25 07:25:27
Rock/metal are usually fairly easy to code and come out a bit lower.


That's a funny result, quite opposite to the experiences I had. Especially electric guitars used to be a pain for many encoders, having a lot of harmonics, being more "a noise" than "a tone".

But if it has a rather straight phase profile (more Mid than Side, only little surround effects), it is still possible. And after all, "practice is the criterion of truth".
Title: IETF Opus codec now ready for testing
Post by: NullC on 2012-07-25 07:42:36
That's a funny result, quite opposite to the experiences I had. Especially electric guitars used to be a pain for many encoders, having a lot of harmonics, being more "a noise" than "a tone".

Not for Opus. Short blocks combined with tools that make generating noisy signals and preserving the spectral envelope cheap, avoiding birdies, and lots of tools for preserving time domain behavior generally make noisy signals easy, and there is usually more overall masking in the listener too. Opus has a hard time on signals with lots of exposed complex (not strictly harmonic) tonal components, but just noisy doesn't seem to be so bad.

If you've got samples that contradict this experience/expectation for Opus they might make for some useful new tuning insights.
Title: IETF Opus codec now ready for testing
Post by: rt87 on 2012-07-25 07:43:57
- Does Opus works integer-only? (soft-float is slow in such devices)

Yes.
Quote
- Does Opus compiles with eVC 4.0? (I haven't tried yet, just want to confirm if no new compiler-specified features are used)

It should work with any C89 compliant toolchain that also provides a 64-bit type.  You may have to twiddle around with the build system, and setup the relevant system specific defines/project files.
Quote
- Any simple example for play/stop/seek/etc., when comparing with Vorbis Tremor? (GSPlayer uses Tremor for Vorbis decoding, so it can be used as reference)

Libopus doesn't have a vorbisfile level interface, and no such high level interface exists currently. Libopus takes packets of opus data and returns PCM, the rest is up to the application.

Then how can I seek?
Does it seek like Vorbis?
Title: IETF Opus codec now ready for testing
Post by: NullC on 2012-07-25 07:49:09
Then how can I seek?
Does it seek like Vorbis?

The format seeks just like Vorbis: Via capture-and-bisect or capture-and-fancier-rootfinder-than-bisection (http://en.wikipedia.org/wiki/Brent%27s_method),  but libopus doesn't provide code for doing this for you. See also: http://wiki.xiph.org/GranulePosAndSeeking (http://wiki.xiph.org/GranulePosAndSeeking)
Title: IETF Opus codec now ready for testing
Post by: Brand on 2012-07-27 20:38:23
Is 'native' gapless support (like in Vorbis) planned for Opus?

I did a quick test with some problematic samples (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=81991&view=findpost&p=716229) and I can hear a tiny pop at the transition. (AAC and MP3 are the same, at least with VBR. The only lossy codec that plays that perfectly is Vorbis.)
Title: IETF Opus codec now ready for testing
Post by: CoRoNe on 2012-07-27 21:22:22
I've just released DC-Bass Source Mod 1.5.0.0 (http://reino.degeelebosch.nl), which I believe is the first DirectShow filter with Opus support. Have fun.
Title: IETF Opus codec now ready for testing
Post by: LigH on 2012-07-27 21:26:05
Nice. I hope BassSource for AviSynth will have it too, soon.
Title: IETF Opus codec now ready for testing
Post by: CoRoNe on 2012-07-27 21:32:27
There already is: bass_opus.dll (http://www.un4seen.com/forum/?topic=13870.0) (still experimental, but seems to be working great) in combination with BassAudio (http://forum.doom9.org/showthread.php?t=104686).
Title: IETF Opus codec now ready for testing
Post by: kode54 on 2012-07-27 21:54:59
Is 'native' gapless support (like in Vorbis) planned for Opus?

Opusdec itself has the potential to glitch on these samples if you don't specify --rate 48000 when decoding them to WAV files, as it doesn't use LPC to flush the resampler at the end of the tracks. I'll work on this after lunch if this is the case.

In the mean time, decode to WAV files with --rate 48000 and test those.

m1.flac/m2.flac sound gapless to me with or without the --rate 48000 switch, so maybe my hearing isn't the best.

EDIT: Maybe you're using old opus-tools?
Title: IETF Opus codec now ready for testing
Post by: Brand on 2012-07-28 10:47:44
It's not really a gap, but a tiny quiet pop/glitch.

I'm using LameXP to encode and Foobar 1.1.14 for playback. The version of Opus in LameXP is libopus 2012-7-24.

I tried converting the Opus to WAV from Foobar and it was the same, still a glitch. (Foobar created a 48k WAV file and it also displays 48k when playing the Opus file.)


However:
If I decode the Opus file to WAV with LameXP there's no glitch. And the decoded WAV is 44.1k.

Just out of curiosity, I converted to WAV from Foobar while resampling (with PPHS) to 44.1k and I couldn't hear a glitch in the resulting WAV.

So 44.1k appears to work better in this case.


EDIT2: I tried quickly enconding to Opus with the last opus-tools CLI (opusenc) and it's always glitching, at 44.1k and at 48k. But I'm also using different settings than with LameXP.
If I decode the LameXP Opus with opusdec CLI, then again, the 44.1k doesn't glitch, while the 48k does.
Title: IETF Opus codec now ready for testing
Post by: zerowalker on 2012-07-29 00:50:39
Where is the current "Transparent" settings right now, if there is any:)?

been playing with the one NullC gave, and it´s very neat;D
Title: IETF Opus codec now ready for testing
Post by: kode54 on 2012-07-29 02:16:49
EDIT2: I tried quickly enconding to Opus with the last opus-tools CLI (opusenc) and it's always glitching, at 44.1k and at 48k. But I'm also using different settings than with LameXP.
If I decode the LameXP Opus with opusdec CLI, then again, the 44.1k doesn't glitch, while the 48k does.

Try this set of opus-tools with foobar2000, or stand-alone from a console, if you have an x64 system with Windows x64 installed:

https://dl.dropbox.com/u/14849789/opus-tools.zip (https://dl.dropbox.com/u/14849789/opus-tools.zip)

They're based on the latest exp_analysis branch, with some minor changes that should hopefully fix any track start gaps. Although at least with m1.flac and m2.flac, I don't notice any glitch on m1->m2 transition, and pasting the two together in a sound editor shows that the end of m1 lines up with the start of m2. Note that the end of m2 is not supposed to loop seamlessly back to the start of m1, in case that's something you were trying.

My change for start gap reduction applies an LPC pre-extrapolation at the start of the file, adding 2.5ms of latency to the stream, which is then absorbed into the preskip. This change is disabled if you request frame sizes smaller than 10ms, or maximum Ogg latency of less than 120ms.


Something worth noting for whoever is maintaining LameXP, the current master for git.xiph.org/opus-tools.git includes all the Unicode changes, and the MSVC 2010 projects now include a git version generator, so the tools will accurately mark files with whichever versions of libopus and opus-tools were used when encoding.
Title: IETF Opus codec now ready for testing
Post by: Brand on 2012-07-29 14:49:02
To keep things standardized, I'm now just using opusenc.exe with Foobar and --music --bitrate 128 - %d.


This build (https://people.xiph.org/~greg/opus-tools_exp_32024cb5.zip) of opus-tools (from the previous page) produces, at least to my ears, an easily noticeable glitch when transitioning from m1 to m2. It's a quiet high pitched click, but with headphones and medium to loud volume I can easily hear it in the left channel.

The new build you just posted seems to make the glitch quieter, but it's still there.

EDIT:
I recorded the playback to compare the original FLAC, the older and the newer build:
http://dl.dropbox.com/u/81620025/opus gapless test.7z (http://dl.dropbox.com/u/81620025/opus%20gapless%20test.7z)
Title: IETF Opus codec now ready for testing
Post by: IgorC on 2012-07-29 17:49:52
Where is the current "Transparent" settings right now, if there is any:)?

Transparency is subjective. Furthermore Opus is on intensive development. So quality is improving constantly.
To have an idea, the last experimental build (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=86580&view=findpost&p=803283) is reaching the quality of MP3 130 kbps (LAME -V 5) at 80 kbps.
Title: IETF Opus codec now ready for testing
Post by: zerowalker on 2012-07-29 20:31:43
Where is the current "Transparent" settings right now, if there is any:)?

Transparency is subjective. Furthermore Opus is on intensive development. So quality is improving constantly.
To have an idea, the last experimental build (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=86580&view=findpost&p=803283) is reaching the quality of MP3 130 kbps (LAME -V 5) at 80 kbps.



Yes i understand that, but just that difference is very nice:)

I myself find 100 and below to sound extremely good, so i am hoping  for it´s continuation:)
Title: IETF Opus codec now ready for testing
Post by: zerowalker on 2012-07-31 21:54:40
Is there any software that´s using Opus for speech transfer (skype like)?
I know it´s not finished and all that, but maybe there´s some open source software trying it out or something?
Would be very interesting to try it with it´s real purpose.
Title: IETF Opus codec now ready for testing
Post by: Clifoo on 2012-08-01 12:07:25
Mumble will undoubtedly support Opus soon. Mumble upcoming features (http://mumble.sourceforge.net/Upcoming#Mumble_.28Client.29)
Title: IETF Opus codec now ready for testing
Post by: Garf on 2012-08-01 12:50:06
Is there any software that´s using Opus for speech transfer (skype like)?


Skype itself is using an older version of the algorithm (they contributed the speech encoding part to Opus).
Title: IETF Opus codec now ready for testing
Post by: PHOYO on 2012-08-01 20:59:03
Mind-blowing quality with only 64 kbps. Awesome work.
Title: IETF Opus codec now ready for testing
Post by: zerowalker on 2012-08-05 10:31:41
Mumble will undoubtedly support Opus soon. Mumble upcoming features (http://mumble.sourceforge.net/Upcoming#Mumble_.28Client.29)



Nice that Skype uses some old version, hope they upgrade to the new:)

And that mumble will use is very neat. Haven´t used it, but would be nice.

Does mumble have better quality than skype?

Am i supposed to open a server myself and let my friend connect to it, or vice versa?
Title: IETF Opus codec now ready for testing
Post by: LigH on 2012-08-05 18:27:14
Yes, you may use Murmur as server, and can tell friends about your IP address (or maybe DynDNS name) and other connection details to talk freely with each other via Mumble clients. But there are also public servers with voice chat channels, similar to IRC with text chat channels.

The quality of the service depends on the (mainly upload) bandwidth from the server and each client, you can configure bitrate and latency / packet size.
Title: IETF Opus codec now ready for testing
Post by: zerowalker on 2012-08-05 23:08:57
Yes, you may use Murmur as server, and can tell friends about your IP address (or maybe DynDNS name) and other connection details to talk freely with each other via Mumble clients. But there are also public servers with voice chat channels, similar to IRC with text chat channels.

The quality of the service depends on the (mainly upload) bandwidth from the server and each client, you can configure bitrate and latency / packet size.


Have tried it, using my PC as a server and my friend connecting to it, the difference from Skype in Sound Quality is SICK, it´s really amazing!
I think it´s lower latency aswell, as it´s not middle server.

But is there a Build that´s using OPUS, or can someone build one?
I know it´s experimental and all, but it would be very neat to try it on it´s home ground (speech).
Title: IETF Opus codec now ready for testing
Post by: LigH on 2012-08-06 05:35:32
It is a SourceForge project. So someone will probably be able to build an Opus DLL for it... But I would not recommend to rush it. It might be buggy. And it might be incompatible to other users not using exactly the same files.

Patience, young Padawan.
Title: IETF Opus codec now ready for testing
Post by: zerowalker on 2012-08-06 09:51:59
It is a SourceForge project. So someone will probably be able to build an Opus DLL for it... But I would not recommend to rush it. It might be buggy. And it might be incompatible to other users not using exactly the same files.

Patience, young Padawan.



Yeah i know, but i would like to test it with my Friend, so both will be using the Exact same file:)

Sadly i myself don´t know how to do it, as long as it´s not very easy, like changing a file or just some text etc.


Patience is something i lost long ago ;P
Title: IETF Opus codec now ready for testing
Post by: Gainless on 2012-08-06 21:41:02
One thing I've noticed is that Opus (the exp version of course) is pushing a lot of bits into pieces at higher bitrates for which other encoders like Vorbis or even Lame are using way less. Since Opus should be at least better than Vorbis at anything there could be probably a lot of average bitrate decrease done while still keeping the same quality overall.
Title: IETF Opus codec now ready for testing
Post by: Garf on 2012-08-07 09:51:12
One thing I've noticed is that Opus (the exp version of course) is pushing a lot of bits into pieces at higher bitrates for which other encoders like Vorbis or even Lame are using way less. Since Opus should be at least better than Vorbis at anything there could be probably a lot of average bitrate decrease done while still keeping the same quality overall.


Yes, that's why you can just lower the bitrate? I don't get your point.
Title: IETF Opus codec now ready for testing
Post by: LigH on 2012-08-07 10:00:13
I believe Gainless refers to something I would call "bitrate dynamics".

If one reduces the overall bitrate target, it does not only reduce the bitrate for the complex scenes which consume a lot of bitrate, but also for the simple scenes which are satisfied with less bitrate already. Gainless is probably interested in "compressing" only the high bitrate scenes, which he feels seem to get out of control.
Title: IETF Opus codec now ready for testing
Post by: Garf on 2012-08-07 10:03:12
I believe Gainless refers to something I would call "bitrate dynamics".

If one reduces the overall bitrate target, it does not only reduce the bitrate for the complex scenes which consume a lot of bitrate, but also for the simple scenes which are satisfied with less bitrate already. Gainless is probably interested in "compressing" only the high bitrate scenes, which he feels seem to get out of control.


If you don't want the encoder to adapt to the material, then use CBR mode.

If the reasoning is something like: "because Opus is better than Vorbis, it should be able to compress any piece/part of a piece of music to the same/better quality using less/same amount of bits" => this simply doesn't follow at all, which is exactly why VBR is boosting the bitrate.
Title: IETF Opus codec now ready for testing
Post by: LigH on 2012-08-07 10:18:11
Why black and white only?

Adapting the bitrate to the complexity of the material is useful. But tweaking the adaption factor might be useful in some cases where the bitrate dynamic is high. There might be situations where extreme bitrate fluctuations may lead to technical issues, e.g. regarding decoding buffers filled from slow sources like optical drives or network transfers. Of course, quality will be suboptimal where bitrate dynamics are dampened.

Do you know the Xvid video codec and the parameters for "Overflow treatment" and "Curve compression"?
Title: IETF Opus codec now ready for testing
Post by: Garf on 2012-08-07 11:01:56
There might be situations where extreme bitrate fluctuations may lead to technical issues, e.g. regarding decoding buffers filled from slow sources like optical drives or network transfers.


In such case you should really use constrained VBR, that mode exist exactly for those situations. Unfortunately I believe in the current Opus encoder the decoder buffer size is not fully configurable: Constrained VBR CTL (http://www.opus-codec.org/docs/html_api/group__encoderctls.html#gab1b534a4fe55373f1be407ad4b2b22bd)

In no circumstances should you use VBR if your transport has a limit that isn't far enough away from the expected maximal possible bitrate, that's just trying to make things work by coincidence. Let alone trying to make the bitrate stay within limits "by coincidence" by crippling the VBR behavior of the encoder, that's even worse as it will lower quality with zero guarantees it will work.

Quote
Do you know the Xvid video codec and the parameters for "Overflow treatment" and "Curve compression"?


In x264 you will configure the decoder buffer size and the channel bitrate, and this is really all the user needs to configure. And it's also exactly this that needs to be configured for proper support of hardware decoders, and it allows the encode to give the maximal possible quality knowing the constraints of the channel and the decoder. Other settings are, to put it mildly, suboptimal.
Title: IETF Opus codec now ready for testing
Post by: NullC on 2012-08-07 11:21:20
One thing I've noticed is that Opus (the exp version of course) is pushing a lot of bits into pieces at higher bitrates for which other encoders like Vorbis or even Lame are using way less. Since Opus should be at least better than Vorbis at anything there could be probably a lot of average bitrate decrease done while still keeping the same quality overall.


Different things are hard for Opus— so its expected that the rate will go up in some different places.  Its also possible that the encoder is making a mistake.  Do a CBR encode and see if you can get away with lowering the rate.  Examples of it being over eager would be helpful.
Title: IETF Opus codec now ready for testing
Post by: Gainless on 2012-08-07 11:22:41
I believe Gainless refers to something I would call "bitrate dynamics".

If one reduces the overall bitrate target, it does not only reduce the bitrate for the complex scenes which consume a lot of bitrate, but also for the simple scenes which are satisfied with less bitrate already. Gainless is probably interested in "compressing" only the high bitrate scenes, which he feels seem to get out of control.


If you don't want the encoder to adapt to the material, then use CBR mode.

If the reasoning is something like: "because Opus is better than Vorbis, it should be able to compress any piece/part of a piece of music to the same/better quality using less/same amount of bits" => this simply doesn't follow at all, which is exactly why VBR is boosting the bitrate.


I want the encoder to adapt to the material but maybe a bit more "intelligent". I cannot really imagine e.g. that Opus needs ~160 kbps for a simple kick and a baseline when Lame only takes ~90 kbps for it at the same target bitrate. If the developers would adapt the encoder to these kind of situations more precisely they could save bits that could be used either for decreasing the average bitrate or for parts that are more complex to encode. In short: They could improve the quality while still staying at the same bitrate.

Sorry for being a bit unclear in the last post btw, I was talking about the VBR model of Opus in general.
Title: IETF Opus codec now ready for testing
Post by: IgorC on 2012-08-07 11:29:07
Post your sample.
Title: IETF Opus codec now ready for testing
Post by: Garf on 2012-08-07 11:33:09
I cannot really imagine e.g. that Opus needs ~160 kbps for a simple kick and a baseline when Lame only takes ~90 kbps for it at the same target bitrate.


See NullC's post for a constructive way to determine what is happening.

In general, though, your reasoning is flawed. Opus isn't an improved version of MP3, Vorbis, or AAC. Clips that may be easy to encode for those codecs can be hard for Opus. We'd just expect the reverse to be true more often. It's also possible Opus' psymodel is more accurate and correctly determines more bits are needed for a transparent encode, while the other codecs artifact even if ever so slightly.

For example tonal clips with multiple different tonal instruments are harder for Opus than any of those codecs due to it having shorter blocks with a windowing function that has higher leakage. Music that has a strong lowpass below 20kHz (for example clips that have been decoded from the other codecs) may also be harder to encode for Opus. There may be other cases - those are just the ones that are obvious to me after looking at the codec designs.
Title: IETF Opus codec now ready for testing
Post by: LigH on 2012-08-07 11:43:36
OK, substantially different algorithms will legitimately produce remarkably different results, compared to previously known algorithms.

I see you are quite active in your development, so I wish you best success, and I hope to find material to support it...
Title: IETF Opus codec now ready for testing
Post by: Gainless on 2012-08-07 12:03:08
I know that the argumentation "If Vorbis can do it then Opus can do it even better" is not really appropiate in general, I'm mainly talking about the really basic examples where a lot of encoders are behaving similarly.

Here is the kick sample I mentioned.
Kick sample (http://www.mediafire.com/download.php?opyao7qq3xjwi9w)

Tested with a target bitrate of 192 kbps and the difference to other encoders is pretty obvious: While Lame, FhG AAC and Vorbis are using 120-130 kbps in average, Opus is reaching out with 181 kbps.

Title: IETF Opus codec now ready for testing
Post by: Gainless on 2012-08-07 13:41:18
Ok, as NullC suggested I've played a bit around with the CBR mode of Opus (last exp version) and found an even better example at which the VBR mode may exaggerates a bit.

Audio Link (http://www.mediafire.com/download.php?drpgx8c5x17pd1s)

At a target bitrate of 192 kbps Opus is giving this sample an average of 214 kbps while it's not even ABXable for me at 96 kbps CBR. Other encoders behave different by giving it only around 150-160 (Lame and Ogg)  or even just around 100 kbps (FhG AAC).
Title: IETF Opus codec now ready for testing
Post by: jmvalin on 2012-08-07 21:36:34
At a target bitrate of 192 kbps Opus is giving this sample an average of 214 kbps while it's not even ABXable for me at 96 kbps CBR. Other encoders behave different by giving it only around 150-160 (Lame and Ogg)  or even just around 100 kbps (FhG AAC).


It looks like the reasons for the high rate Opus uses on this file are:
1) It's highly tonal, so the encoder tends to boost the rate
2) There isn't much useful content above about 5 kHz, but the encoder currently cannot take advantage of that

The main point that should be addressed is 2), but it's not something that's easy to do. It's a great example of something "simple" that doesn't fit well within the current theory of psycho-acoustics.
Title: IETF Opus codec now ready for testing
Post by: yourlord on 2012-08-07 23:35:52
is there any news on an eta for getting an RFC number?
Title: IETF Opus codec now ready for testing
Post by: jmvalin on 2012-08-08 03:15:12
is there any news on an eta for getting an RFC number?


I think we'll probably know the RFC number some time next week.
Title: IETF Opus codec now ready for testing
Post by: LigH on 2012-08-08 07:29:36
Very tonal ... do you know "Stranglehold" by Jeroen Tel (http://www.ligh.de/tmp/stranglehold.xm)? It's an XM (FastTracker "Extended Module") which uses only a single sine wave as "instrument". Use e.g. ModPlug Player (or any audio player with module support and WAV export, e.g. foobar2000) to export it as WAV to get encodable material.

(http://frupic.frubar.net/thumbs/26559.png) (http://frupic.frubar.net/shots/26559.png)

LAME 3.99.5 -V2: 180.0 kbps
Ogg Vorbis aoTuVb6.03 SSE3 -q5: 129.1 kbps
QAAC 1.39 (CATB 7.9.7.9) -V82: 147.7 kbps
Opus 0.9.11-92 (rel. gc329045) music 160: 157.8 kbps (149.6-278.0)
Opus 0.9.11-139 (exp. g2c7f8cd) music 160: 187.8 kbps (138.8-287.2)
Opus 0.9.11-142 (exp. 32024cb5) music 160: 189.2 kbps (137.6-311.6)

based on an amplified (about +9 dB, nearly normalized) 24-bit export from ModPlug Player with some sound enhancements enabled
Title: IETF Opus codec now ready for testing
Post by: Gainless on 2012-08-08 10:26:16
What I really wonder is how much potential the codec still has for tonal pieces. Is there still any room for improvements apart from tuning the VBR- and psymodel?
Title: IETF Opus codec now ready for testing
Post by: Garf on 2012-08-08 13:02:59
What I really wonder is how much potential the codec still has for tonal pieces. Is there still any room for improvements apart from tuning the VBR- and psymodel?


Your question doesn't make any sense to me. Opus is a set, standardized codec. You can not change it and expect it to stay compatible. You can improve the quality of the encoder by improving the encoding decisions, which will generally be done by improving the psymodel to advise the encoder when it makes sense to do or not do something (of which one would be "spend more bits here"). It's very exceptional to improve a lossy encoder (for a given codec) by anything that doesn't depend on the psymodel.

I could replace "Opus" by AAC/MP3/Vorbis/... in the above sentence.
Title: IETF Opus codec now ready for testing
Post by: IgorC on 2012-08-08 16:13:44
What I really wonder is how much potential the codec still has for tonal pieces. Is there still any room for improvements apart from tuning the VBR- and psymodel?

Well, Opus was on deep freeze during more than year. All last improvements come from tuning of VBR and psy.  There is still a lot  to improve.
Opus is already better than AoTuv and HE-AAC at 64 kbps. Even future standard (USAC) can't do any better than Opus at the same 64 kbps. Opus should do already better than Vorbis at 96 kbps too.
Given superior quality of Opus at 64 kbps and its good scalability I'm confident that it will present the same advantage at higher bitrates. But it will take time.
Title: IETF Opus codec now ready for testing
Post by: jensend on 2012-08-08 17:46:25
What I really wonder is how much potential the codec still has for tonal pieces. Is there still any room for improvements apart from tuning the VBR- and psymodel?
The encoder does make a lot of decisions, any of which might be improved- just from what little I know about it these include overall VBR rate control, long vs short blocks for each frequency band, whether to tilt the normal per-band bit allocation in favor of lower or higher frequencies, whether to boost the bits used by a particular band, whether to change the stereo mode, whether to change the codec mode (LP/hybrid/MDCT), and more.

But as Garf said, the psymodel is how a lossy encoder makes its decisions. So your question sounds much like "What I really wonder is how much potential cars still have for transportation. Is there still any way they can get me from place to place apart from using a motor or an engine?"

The latest tonal "problem samples" only seem to be problems for the experimental version's rate control, not problems for the codec's quality. I admittedly don't have golden ears, but I can't abx them at 64kbps using the non-experimental 0.1.4 opus-tools build.
Title: IETF Opus codec now ready for testing
Post by: IgorC on 2012-08-08 18:42:18
The latest tonal "problem samples" only seem to be problems for the experimental version's rate control

The experimental branch actually improves quality of tonal samples.
Title: IETF Opus codec now ready for testing
Post by: NullC on 2012-08-08 19:12:09
The latest tonal "problem samples" only seem to be problems for the experimental version's rate control, not problems for the codec's quality. I admittedly don't have golden ears, but I can't abx them at 64kbps using the non-experimental 0.1.4 opus-tools build.


No one is claiming to ABX it with EXP either, they're claiming that at high rates its using more rate than it strictly needs to.
Title: IETF Opus codec now ready for testing
Post by: jensend on 2012-08-08 19:20:27
IgorC, NullC: Uh, I'm quite aware of that. What part of "only seem to be problems for rate control, not quality" didn't you guys understand?

If I need to be more explicit: the experimental version's increase in quality of tonal samples in general seems to be accompanied by some minor problems with rate control on these specific samples.
Title: IETF Opus codec now ready for testing
Post by: Gainless on 2012-08-08 20:05:52
What I really wonder is how much potential the codec still has for tonal pieces. Is there still any room for improvements apart from tuning the VBR- and psymodel?


Your question doesn't make any sense to me. Opus is a set, standardized codec. You can not change it and expect it to stay compatible. You can improve the quality of the encoder by improving the encoding decisions, which will generally be done by improving the psymodel to advise the encoder when it makes sense to do or not do something (of which one would be "spend more bits here"). It's very exceptional to improve a lossy encoder (for a given codec) by anything that doesn't depend on the psymodel.

I could replace "Opus" by AAC/MP3/Vorbis/... in the above sentence.


Sorry if the question came along a bit stupid, I wasn't really aware of the fact that the bitstream freeze means it's totally impossible to add some new technical abilities. 

What I really wonder is how much potential the codec still has for tonal pieces. Is there still any room for improvements apart from tuning the VBR- and psymodel?

Well, Opus was on deep freeze during more than year. All last improvements come from tuning of VBR and psy.  There is still a lot  to improve.
Opus is already better than AoTuv and HE-AAC at 64 kbps. Even future standard (USAC) can't do any better than Opus at the same 64 kbps. Opus should do already better than Vorbis at 96 kbps too.
Given superior quality of Opus at 64 kbps and its good scalability I'm confident that it will present the same advantage at higher bitrates. But it will take time.


Maybe I got it wrong, but I thought that the Psymodel is at least so far done that the rough behaviour (these bitrates for noisy samples, that one for...) is set properly and that it's now more about fixing the last problems for difficult/exceptional cases. But that would be more a question for NullC. I would be a bit careful with the statement that Opus is generally better than HE-AAC at 64 kbps btw, in my experience the FhG AAC encoder never had heavy problems with any sample (with the price of being slightly defficient at high frequencies), while Opus has quite a lot ones.


What I really wonder is how much potential the codec still has for tonal pieces. Is there still any room for improvements apart from tuning the VBR- and psymodel?
The encoder does make a lot of decisions, any of which might be improved- just from what little I know about it these include overall VBR rate control, long vs short blocks for each frequency band, whether to tilt the normal per-band bit allocation in favor of lower or higher frequencies, whether to boost the bits used by a particular band, whether to change the stereo mode, whether to change the codec mode (LP/hybrid/MDCT), and more.

But as Garf said, the psymodel is how a lossy encoder makes its decisions. So your question sounds much like "What I really wonder is how much potential cars still have for transportation. Is there still any way they can get me from place to place apart from using a motor or an engine?"

The latest tonal "problem samples" only seem to be problems for the experimental version's rate control, not problems for the codec's quality. I admittedly don't have golden ears, but I can't abx them at 64kbps using the non-experimental 0.1.4 opus-tools build.


I was more thinking about some new techniques instead of just deciding how to use the ones that are already there (as I assume that this is set at least substantially), but as Garf pointed out that's unfortunately not possible.
Title: IETF Opus codec now ready for testing
Post by: IgorC on 2012-08-08 20:25:11
I would be a bit careful with the statement that Opus is generally better than HE-AAC at 64 kbps btw, in my experience the FhG AAC encoder never had heavy problems with any sample (with the price of being slightly defficient at high frequencies), while Opus has quite a lot ones.

Probably You are not sensitive to pre-echo artifacts. Absolutely (!) every HE-AAC encoder exposes transients issues and that's where Opus has an advantage over it.
I have done a very extensive tests on HE-AAC vs Opus during last year on very large set of samples.

Feel free to  try the last experimental build on big set of samples and post your results.
Title: IETF Opus codec now ready for testing
Post by: Gainless on 2012-08-08 21:04:40
I would be a bit careful with the statement that Opus is generally better than HE-AAC at 64 kbps btw, in my experience the FhG AAC encoder never had heavy problems with any sample (with the price of being slightly defficient at high frequencies), while Opus has quite a lot ones.

Probably You are not sensitive to pre-echo artifacts. Absolutely (!) every HE-AAC encoder exposes transients issues and that's where Opus has an advantage over it.
I have done a very extensive tests on HE-AAC vs Opus during last year on very large set of samples.

Feel free to  try the last experimental build on big set of samples and post your results.


Well, I've mainly tried Opus with electronic music and noticed things like unrelated sounds crushing in, artifacts on snares that made them sound like they were breaking apart (aren't that also pre-echos?) or simply heavy distortions on Hi-Hats and cymbals.
Title: IETF Opus codec now ready for testing
Post by: IgorC on 2012-08-08 21:31:34
Now that's really strange. 

You really don't hear issues with HE-AAC  but Opus ... on electronic music. It's completely vice-versa for average listener.

Please, search for eig and fatboy samples .... the most tested electronic samples.
Title: IETF Opus codec now ready for testing
Post by: jensend on 2012-08-08 22:39:13
I was more thinking about some new techniques instead of just deciding how to use the ones that are already there (as I assume that this is set at least substantially), but as Garf pointed out that's unfortunately not possible.
Have you ever compared the original 1994 l3enc mp3 encoder with modern encoders? (http://listening-tests.hydrogenaudio.org/sebastian/mp3-128-1/results.htm) There were no "new techniques" in the mp3 format, which was frozen in 1992, just vastly improved ways of making the decisions afforded by the format. The improvment is tremendous. Current opusenc may do a somewhat better job of showing the possibilities of opus than l3enc did for mp3, but there's still plenty of room for improvement without breaking the bitstream format.
Title: IETF Opus codec now ready for testing
Post by: C.R.Helmrich on 2012-08-08 22:56:04
Even future standard (USAC) can't do any better than Opus at the same 64 kbps.

What makes you come to that conclusion? So far, the only reasonable demos of the quality USAC can offer are the bit-streams used in the MPEG verification test, which are CBR and created by an encoder which wasn't tuned for killer items like Fatboy and eig. A decent-quality USAC stereo encoder is not yet publicly available.

Quote from: jensend link=msg=0 date=
Have you ever compared the original 1994 l3enc mp3 encoder with modern encoders? There were no "new techniques" in the mp3 format, which was frozen in 1992, just vastly improved ways of making the decisions afforded by the format. The improvment is tremendous.

That's simply because that l3enc version (which wasn't even version 1.0!) was buggy and frankly sounded like shit. I seriously doubt that at 64 kbps future Opus encoders will sound much better than the recent experimental branch. Which I haven't actually looked at or listened to, but from what NullC writes here it's already well tested for bugs and quality... which that l3enc version wasn't.

Chris
Title: IETF Opus codec now ready for testing
Post by: IgorC on 2012-08-09 01:42:40
Even future standard (USAC) can't do any better than Opus at the same 64 kbps.

What makes you come to that conclusion?

You know what it is. http://www.hydrogenaudio.org/forums/index....st&p=797609 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=90824&view=findpost&p=797609)


So far, the only reasonable demos of the quality USAC can offer are the bit-streams used in the MPEG verification test, which are CBR and created by an encoder which wasn't tuned for killer items like Fatboy and eig. A decent-quality USAC stereo encoder is not yet publicly available.

If those USAC and HE-AAC encoders were tested in CBR mode how can You explain that your FhG HE-AAC (which I consider as best HE-AAC  encoder)  VBR ends up with practicaly identical quality? 
Furthermore the advantage of USAC over HE-AAC is ... 8 kbps. Do You beleive that HE-AAC (64+8) 72 kbps is somehow superior to Opus 64 kbps? 

Consider my post as constructive criticism and not as personal attack.
Title: IETF Opus codec now ready for testing
Post by: jmvalin on 2012-08-09 02:16:27
Well, I've mainly tried Opus with electronic music and noticed things like unrelated sounds crushing in, artifacts on snares that made them sound like they were breaking apart (aren't that also pre-echos?) or simply heavy distortions on Hi-Hats and cymbals.


One thing worth checking is whether any of these artefacts are caused by clipping of the decoded values. Recent music is often mastered at such high level that lossy compression will cause some clipping when the output is a 16-bit int (not for float output). So it may be worth checking if a lower input level still causes these problems. If so, then it's something we're interested in fixing.
Title: IETF Opus codec now ready for testing
Post by: jmvalin on 2012-08-09 02:30:25
That's simply because that l3enc version (which wasn't even version 1.0!) was buggy and frankly sounded like shit. I seriously doubt that at 64 kbps future Opus encoders will sound much better than the recent experimental branch. Which I haven't actually looked at or listened to, but from what NullC writes here it's already well tested for bugs and quality... which that l3enc version wasn't.


Obviously, the Opus reference implementation isn't crappy enough to have as much room for improvement as l3enc did. That being said, even from the current experimental branch there's still room for significant improvements. The current and experimental encoders still have a bunch of decisions that are made by rough heuristics that can definitely be improved. Feel free to give us a hand on those 
Title: IETF Opus codec now ready for testing
Post by: NullC on 2012-08-09 03:23:22
Obviously, the Opus reference implementation isn't crappy enough to have as much room for improvement as l3enc did. That being said, even from the current experimental branch there's still room for significant improvements. The current and experimental encoders still have a bunch of decisions that are made by rough heuristics that can definitely be improved. Feel free to give us a hand on those 


There are also elements of the format that we don't make use of in the existing encoder—  the ability to switch frame sizes, changing the bandpass on a frame by frame basis, or switching frames to straight mono automatically. Nor do we have any analysis that adds latency (at a minimum the pitch-prefilter, transient detection, and coding mode decision could be smarter with more lookahead).

There are also more exotic things that could be done which might have useful payoffs, e.g. non-uniform weighing the codebooks search, analysis on the post-prefilter signal, low rate RDO on the band energy.
Title: IETF Opus codec now ready for testing
Post by: jmvalin on 2012-08-09 05:54:49
Oh, and we just released 1.0.0-rc and 1.0.1-rc. Please give those a try and report any problems so we can fix them for the final releases.
Title: IETF Opus codec now ready for testing
Post by: Gainless on 2012-08-09 09:27:14
Would be nice to have a compiled encoder.exe from this.
Title: IETF Opus codec now ready for testing
Post by: Garf on 2012-08-09 10:06:00
Oh, and we just released 1.0.0-rc and 1.0.1-rc. Please give those a try and report any problems so we can fix them for the final releases.


Would be nice to have a compiled encoder.exe from this.


Something went wrong with that release candidate tar, I think, because it's missing all the stuff to compile with MSVC & Win32 that kode54 and me added.

The stuff in git is fine, that's compiled here: http://www.hydrogenaudio.org/forums/index....showtopic=96416 (http://www.hydrogenaudio.org/forums/index.php?showtopic=96416)
Title: IETF Opus codec now ready for testing
Post by: NullC on 2012-08-09 18:47:23
Would be nice to have a compiled encoder.exe from this.


Nothing changed from the files on the site.
Title: IETF Opus codec now ready for testing
Post by: C.R.Helmrich on 2012-08-10 00:44:37
Jean-Marc, Greg, I see. The question is how much quality improvement you can get on top of the current encoder state by exploiting/encoder-tuning every tool the Opus decoder supports. From my experience in tuning Fraunhofer's HE-AAC encoder, the improvement can be quite large for individual items, but is surprisingly small on average over a large test set.

What makes you come to that conclusion?

You know what it is. http://www.hydrogenaudio.org/forums/index....st&p=797609 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=90824&view=findpost&p=797609)

OK, so you took the original_stereo_concat from that test and encoded it with Winamp's HE-AAC, VBR 2, to compare it against USAC?

Quote
If those USAC and HE-AAC encoders were tested in CBR mode how can You explain that your FhG HE-AAC (which I consider as best HE-AAC  encoder)  VBR ends up with practicaly identical quality? 

Because only one or two of the verification test samples were killer samples. On non-killer samples, CBR does quite well. And besides, the tested SBR configuration isn't the only possible one (see the discussion on downsampled SBR elsewhere on HA). Anyway, it would be nice if you could post on HA (not in this thread) your test results which made you conclude, "VBR ends up with practicaly identical quality". Not only would this help me find out if my VBR code works suboptimally somewhere, it's also required by TOS#8.

Quote
Furthermore the advantage of USAC over HE-AAC is ... 8 kbps. Do You beleive that HE-AAC (64+8) 72 kbps is somehow superior to Opus 64 kbps?

Well, don't know. As you mentioned, which codec does better depends on the audio material. But I hear a significant improvement of HE-AAC 72 kbps over HE-AAC 64 kbps, so I'd say: possibly  Btw, where does that 8-kbps rule-of-thumb come from? Is that your own finding?

Quote
Consider my post as constructive criticism and not as personal attack.

I do and hope you do the same

Chris
Title: IETF Opus codec now ready for testing
Post by: IgorC on 2012-08-10 03:07:32
OK, so you took the original_stereo_concat from that test and encoded it with Winamp's HE-AAC, VBR 2, to compare it against USAC?

Neither there was a need. It was HE-AAC (the version from a verification test) vs FhG/Winamp HE-AAC (and some other combinations).
I've received the complete package with USAC and HE-AAC samples at all tested bitrates, as well as some additional documentation of verification test.

Because only one or two of the verification test samples were killer samples. On non-killer samples, CBR does quite well.

It might be the case. Though there were more than 2 killer samples. Very difficult sample like Castanets, your super-killer Berlin Dug, a lot of trumpets, a lot of tonal samples, mixed samples speech+background noise/music, stereo samples like  velvet.  It doesn't  fit into an easy-to-compress stuff.

Anyway, it would be nice if you could post on HA (not in this thread) ...

It's my personal decision to make publicly available results or not. I have stopped to do that some time ago (with a few exceptions).


Quote
Well, don't know. As you mentioned, which codec does better depends on the audio material. But I hear a significant improvement of HE-AAC 72 kbps over HE-AAC 64 kbps, so I'd say: possibly  Btw, where does that 8-kbps rule-of-thumb come from? Is that your own finding?

http://www.hydrogenaudio.org/forums/index....st&p=781323 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=92751&view=findpost&p=781323)
http://www.hydrogenaudio.org/forums/index....st&p=781338 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=92751&view=findpost&p=781338)

Correct. A more accurate rule of thumb for music and mixed content (not for pure speech) is: USAC at x kbps sounds as good as HE-AAC at x+8 kbps. (Edit: looking at the report Igor linked to (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=92660&view=findpost&p=781041), this seems to be roughly true for x >= 16.)
Title: IETF Opus codec now ready for testing
Post by: C.R.Helmrich on 2012-08-11 09:24:42
I've received the complete package with USAC and HE-AAC samples at all tested bitrates, as well as some additional documentation of verification test.
Because only one or two of the verification test samples were killer samples. On non-killer samples, CBR does quite well.

It might be the case. Though there were more than 2 killer samples. Very difficult sample like Castanets, your super-killer Berlin Dug, a lot of trumpets, a lot of tonal samples, mixed samples speech+background noise/music, stereo samples like  velvet.  It doesn't  fit into an easy-to-compress stuff.

I just listened through the concatenated files, and you're right. It contains a lot of killer samples, basically every sample we used during the development of USAC. I had assumed it contains only the verification items. I guess I'll do my own MUSHRA test with these concatenated files then...


Quote
http://www.hydrogenaudio.org/forums/index....st&p=781323 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=92751&view=findpost&p=781323)
http://www.hydrogenaudio.org/forums/index....st&p=781338 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=92751&view=findpost&p=781338)
Correct. A more accurate rule of thumb for music and mixed content (not for pure speech) is: USAC at x kbps sounds as good as HE-AAC at x+8 kbps. (Edit: looking at the report Igor linked to (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=92660&view=findpost&p=781041), this seems to be roughly true for x >= 16.)


Thanks for reminding me of that post. I had already forgotten about that.

Chris
Title: IETF Opus codec now ready for testing
Post by: Gainless on 2012-08-11 11:13:34
Ok, here is one more sample that seems to make problems (with the 1.01 release candidate).

Bombat Sample (http://www.mediafire.com/download.php?sebjyc3hjaw6abu)

There is this sharp sound of some kind of distorted voice on which the encoder introduces noise/distortions. It's especially obvious at 64 kbps, but also noticeable at higher bitrates up to 160 kbps.
Title: IETF Opus codec now ready for testing
Post by: IgorC on 2012-08-11 20:47:21
Ok, as NullC suggested I've played a bit around with the CBR mode of Opus (last exp version) and found an even better example at which the VBR mode may exaggerates a bit.

Audio Link (http://www.mediafire.com/download.php?drpgx8c5x17pd1s)

At a target bitrate of 192 kbps Opus is giving this sample an average of 214 kbps while it's not even ABXable for me at 96 kbps CBR. Other encoders behave different by giving it only around 150-160 (Lame and Ogg)  or even just around 100 kbps (FhG AAC).
Bitrate is only part of  story. It's always worthy to check if LAME, Aotuv or FhG decrease bitrate without any audible issues.

My results for this sample:
Code: [Select]
ABC/HR for Java, Version 0.53a, 11 August 2012
Testname:

Tester: IgorC

1L = D:\Samples\01_Kick_sample\FhG VBR 5 192 kbps.wav
2L = D:\Samples\01_Kick_sample\48kHz_192kbps_Opus(transients build)_44.1kHz_SoX.wav
3L = D:\Samples\01_Kick_sample\AoTuV VBR q6 192 kbps .wav
4R = D:\Samples\01_Kick_sample\LAME 3.99.5 V2.wav

Ratings on a scale from 1.0 to 5.0

---------------------------------------
General Comments:
---------------------------------------
1L File: D:\Samples\01_Kick_sample\FhG VBR 5 192 kbps.wav
1L Rating: 4.9
1L Comment:
---------------------------------------
2L File: D:\Samples\01_Kick_sample\48kHz_192kbps_Opus(transients build)_44.1kHz_SoX.wav
2L Rating: 4.8
2L Comment:
---------------------------------------
3L File: D:\Samples\01_Kick_sample\AoTuV VBR q6 192 kbps .wav
3L Rating: 4.4
3L Comment: muddy bass. Probably as well as some tine pre-echo
---------------------------------------
4R File: D:\Samples\01_Kick_sample\LAME 3.99.5 V2.wav
4R Rating: 3.5
4R Comment: pre/post echo.
---------------------------------------

ABX Results:
Even such mature codecs like Vorbis and LAME drop bitrate but aslo drop quality. While only FhG AAC (VBR 5 192 kbps) could drop bitrate down to 120 kbps without any audible issues. I'm not sure how it will be easy or difficult to do that for Opus.



Ok, as NullC suggested I've played a bit around with the CBR mode of Opus (last exp version) and found an even better example at which the VBR mode may exaggerates a bit.

Audio Link (http://www.mediafire.com/download.php?drpgx8c5x17pd1s)

At a target bitrate of 192 kbps Opus is giving this sample an average of 214 kbps while it's not even ABXable for me at 96 kbps CBR. Other encoders behave different by giving it only around 150-160 (Lame and Ogg)  or even just around 100 kbps (FhG AAC).
Agree, CBR 96 kbps was already very good.
It's great sample where Opus could save bitrate.  All encoders decrease the bitrate on this sample without any audible issue. FhG AAC (VBR 5 ~192 kbps) shines again, 105 kbps while keeping perfect quality.



Ok, here is one more sample that seems to make problems (with the 1.01 release candidate).

Bombat Sample (http://www.mediafire.com/download.php?sebjyc3hjaw6abu)

There is this sharp sound of some kind of distorted voice on which the encoder introduces noise/distortions. It's especially obvious at 64 kbps, but also noticeable at higher bitrates up to 160 kbps.
It's rather a killer sample itself than a particular issue for 1.0.1. I couldn't find any other lossy codec that makes any better for this sample.
Comparison with HE-AAC:
Code: [Select]
ABC/HR for Java, Version 0.53a, 11 August 2012
Testname:

Tester: IgorC

1L = D:\Samples\HA_opus_topic\03 Bombat\Opus_EXP7_Transients_64kbps_resampled_44.1kHz_SoX.wav
2L = D:\Samples\HA_opus_topic\03 Bombat\Opus_1.0.1_64kpbs_resampled_44.1kHz_SoX.wav
3R = D:\Samples\HA_opus_topic\03 Bombat\FHG_VBR3_64kbps.wav

Ratings on a scale from 1.0 to 5.0

---------------------------------------
General Comments:
---------------------------------------
1L File: D:\Samples\HA_opus_topic\03 Bombat\Opus_EXP7_Transients_64kbps_resampled_44.1kHz_SoX.wav
1L Rating: 3.8
1L Comment:
---------------------------------------
2L File: D:\Samples\HA_opus_topic\03 Bombat\Opus_1.0.1_64kpbs_resampled_44.1kHz_SoX.wav
2L Rating: 3.8
2L Comment:
---------------------------------------
3R File: D:\Samples\HA_opus_topic\03 Bombat\FHG_VBR3_64kbps.wav
3R Rating: 3.4
3R Comment:
---------------------------------------

ABX Results:
Title: IETF Opus codec now ready for testing
Post by: IgorC on 2012-08-11 21:52:51
The first quote of previous post is wrong.
Shoud be
I know that the argumentation "If Vorbis can do it then Opus can do it even better" is not really appropiate in general, I'm mainly talking about the really basic examples where a lot of encoders are behaving similarly.

Here is the kick sample I mentioned.
Kick sample (http://www.mediafire.com/download.php?opyao7qq3xjwi9w)

Tested with a target bitrate of 192 kbps and the difference to other encoders is pretty obvious: While Lame, FhG AAC and Vorbis are using 120-130 kbps in average, Opus is reaching out with 181 kbps.

Title: IETF Opus codec now ready for testing
Post by: Kvanto on 2012-08-11 21:57:05
Does anyone have some info about how opus performs compared to AAC-LC (Apple,Nero or winamp encoder) on medium to high bitrate, like up to 512kbps?
Title: IETF Opus codec now ready for testing
Post by: saratoga on 2012-08-11 22:35:08
Does anyone have some info about how opus performs compared to AAC-LC (Apple,Nero or winamp encoder) on medium to high bitrate, like up to 512kbps?


Pretty much anything will be transparent.  At those bitrates, you can probably use mp2 just as well.
Title: IETF Opus codec now ready for testing
Post by: eahm on 2012-08-11 23:05:54
foobar2000 1.1.14 beta 3 released (http://www.foobar2000.org/download):

Added Opus encoding support in Converter (requires external opusenc.exe binary) (beta 3).
Title: IETF Opus codec now ready for testing
Post by: jensend on 2012-08-11 23:32:53
Does anyone have some info about how opus performs compared to AAC-LC (Apple,Nero or winamp encoder) on medium to high bitrate, like up to 512kbps?
Both of these codecs should be basically transparent by the time you reach 192kbps (if not long before). Being able to find a sample where you can hear any difference -in completely ideal circumstances- between either codec at 192kbps and the original would be extraordinarily rare. For the quality of either at 192kbps to be worse than the original by enough to seriously impact your normal music-listening experience is unheard of.

How on earth would you propose to compare codec performance at bitrates well above their normal transparency threshholds? What basis would you have for saying "though x and y both sound identical to the original, x performs better than y"?

If you're trying to preserve non-perceptible details of the original then it's foolish to be looking at lossy codecs, which are designed around human perception. (Lossless codecs often get roughly 50% compression; for CD audio that means ~700kbps.)

If you only care about how it's perceived when listening then there's no point in considering >192kbps rates with either of these codecs.
Title: IETF Opus codec now ready for testing
Post by: Gainless on 2012-08-12 10:24:59
Thanks for the tests Igor, noticed the bad performance of Lame at the Kick sample and FhG at the Bombat sample now either. A definately Opus related problem I've noticed though is that the exp version performs generally better at tonal samples than the "official" one, but in return often worse at certain other situations. A good example is this sample:

VD Sample (http://www.mediafire.com/download.php?17oqjiewoir8bw5)

While the 1.0.1 rc handles the rythmic snare in it pretty well (at 64 kbps) the exp version introduces some kind of crackling sounds.
Title: IETF Opus codec now ready for testing
Post by: larryfine on 2012-08-12 17:40:11
I'm a strange here so...

Original file:

01. Giorgio Federico Ghedini - Mazurka (1908).wav --> 44.056.576 bytes

Compressed with Opus:

> opusenc.exe --bitrate 512 --music

01. Giorgio Federico Ghedini - Mazurka (1908).opus --> 15.794.176 bytes (lossy)

Compressed with TAK:

> Takc.exe -e -ihs -pMax

01. Giorgio Federico Ghedini - Mazurka (1908).tak --> 12.816.384 bytes (lossless)

Title: IETF Opus codec now ready for testing
Post by: Gainless on 2012-08-12 17:48:57
Well, if you set the encoder to 512 kbps it'll keep the resulting file around that bitrate, no matter how far it could be compressed further losslessly.
Title: IETF Opus codec now ready for testing
Post by: zerowalker on 2012-08-12 18:48:25
Opus has received the IETF's approval to become a standard.  There will be some weeks of publication / pure-editorial delay and it will receive and RFC number and we'll make the big public announcements.

Now is really the time to get support into applications (well, this was also true for some time, but doubly so now).  If there is an application you think should have Opus support that doesn't, especially open source ones, please post about it here and I'll do what I can to coordinate with their authors.



I say Mumble, but it already says it´s going to have support so not sure it counts?
Other than that, i say Megui, for encoding?

And Youtube for allowing Opus decoding for there Re-Encode (probably a bit harder here as it´+s not open source or anything)
Title: IETF Opus codec now ready for testing
Post by: CoRoNe on 2012-08-12 21:04:13
Doesn't MeGUI use Avisynth and BassAudio for audio encoding? In that case it's already possible.
Title: IETF Opus codec now ready for testing
Post by: zerowalker on 2012-08-12 21:40:19
Doesn't MeGUI use Avisynth and BassAudio for audio encoding? In that case it's already possible.


Not sure what BassAudio is?

But well, it´s probably Very Easy to implement, as it just redirect to the encoder pretty much.


But, does anyone know if youtube supports Opus? (can´t see that it does).
Title: IETF Opus codec now ready for testing
Post by: CoRoNe on 2012-08-12 22:30:21
I'm sorry, I'm mixing up encoding and decoding.
Opus decoding through Avisynth is already possible with BassAudio, but the encoding part...that's indeed up to MeGUI to add a profile. In the meantime you could use avs2pipe (http://forum.doom9.org/showthread.php?t=160383) to pipe Avisynth's audio output to the input of the audio encoder of your choosing.
Title: IETF Opus codec now ready for testing
Post by: zerowalker on 2012-08-12 23:02:05
I'm sorry, I'm mixing up encoding and decoding.
Opus decoding through Avisynth is already possible with BassAudio, but the encoding part...that's indeed up to MeGUI to add a profile. In the meantime you could use avs2pipe (http://forum.doom9.org/showthread.php?t=160383) to pipe Avisynth's audio output to the input of the audio encoder of your choosing.


Oh, well i will just wait for MeGUI, as youtube doesn´t support Opus yet i think:)
Title: IETF Opus codec now ready for testing
Post by: lvqcl on 2012-08-13 15:20:40
Something strange with experimental codec: I took 41_30 sample and encoded it with "--bitrate 96 --music". The bitrate is 109 kbps. Then I replaced the right channel with silence. Bitrate -> 105 kbps. Replaced the left channel (of the original sample) with silence -> 32 kbps. So:

Both channels in a stereo file -> 109 kbps;
Left channel only -> 105 kbps;
Right channel only -> 32 kbps.


1.0.1 rc works fine, BTW.
Title: IETF Opus codec now ready for testing
Post by: jmvalin on 2012-08-14 05:42:17
Something strange with experimental codec: I took 41_30 sample and encoded it with "--bitrate 96 --music". The bitrate is 109 kbps. Then I replaced the right channel with silence. Bitrate -> 105 kbps. Replaced the left channel (of the original sample) with silence -> 32 kbps. So:

Both channels in a stereo file -> 109 kbps;
Left channel only -> 105 kbps;
Right channel only -> 32 kbps.


Thanks very much for reporting this. It was a silly bug that is now fixed in git. Let us know if you find any other issues where the experimental encoder is worse than 1.0.1-rc. Or even when it generally does poorly on a certain file.
Title: IETF Opus codec now ready for testing
Post by: NullC on 2012-08-14 06:34:57
Thanks very much for reporting this. It was a silly bug that is now fixed in git. Let us know if you find any other issues where the experimental encoder is worse than 1.0.1-rc. Or even when it generally does poorly on a certain file.

And here is a new build of the EXP encoder with this fix: https://people.xiph.org/~greg/opus-tools_exp_dc4f83be.zip (https://people.xiph.org/~greg/opus-tools_exp_dc4f83be.zip)  As JM says, thanks!
Title: IETF Opus codec now ready for testing
Post by: LigH on 2012-08-14 07:52:13
Again with Stranglehold:
LAME 3.99.5 -V2: 180.0 kbps
Ogg Vorbis aoTuVb6.03 SSE3 -q5: 129.1 kbps
QAAC 1.39 (CATB 7.9.7.9) -V82: 147.7 kbps
Opus 0.9.11-92 (rel. gc329045) music 160: 157.8 kbps (149.6-278.0)
Opus 0.9.11-139 (exp. g2c7f8cd) music 160: 187.8 kbps (138.8-287.2)
Opus 0.9.11-142 (exp. 32024cb5) music 160: 189.2 kbps (137.6-311.6)

Opus 0.9.11-146 (exp. gdc4f83b) music 160: 190.6 kbps (137.2-316.0)
Title: IETF Opus codec now ready for testing
Post by: punkrockdude on 2012-08-14 09:35:05
And here is a new build of the EXP encoder with this fix: https://people.xiph.org/~greg/opus-tools_exp_dc4f83be.zip (https://people.xiph.org/~greg/opus-tools_exp_dc4f83be.zip)  As JM says, thanks!

The link is dead. Regards.
Title: IETF Opus codec now ready for testing
Post by: Garf on 2012-08-14 09:46:43
And here is a new build of the EXP encoder with this fix: https://people.xiph.org/~greg/opus-tools_exp_dc4f83be.zip (https://people.xiph.org/~greg/opus-tools_exp_dc4f83be.zip)  As JM says, thanks!

The link is dead. Regards.


WORKSFORME.
Title: IETF Opus codec now ready for testing
Post by: LigH on 2012-08-14 09:54:53
Worked earlier today; now it returns emptiness. – Worked again. But who knows, sometimes I have issues with HTTPS and some proxy.
Title: IETF Opus codec now ready for testing
Post by: punkrockdude on 2012-08-14 10:39:24
And here is a new build of the EXP encoder with this fix: https://people.xiph.org/~greg/opus-tools_exp_dc4f83be.zip (https://people.xiph.org/~greg/opus-tools_exp_dc4f83be.zip)  As JM says, thanks!

The link is dead. Regards.


WORKSFORME.

It works for me now, too.
Title: IETF Opus codec now ready for testing
Post by: Gecko on 2012-08-14 14:47:16
And here is a new build of the EXP encoder with this fix: https://people.xiph.org/~greg/opus-tools_exp_dc4f83be.zip (https://people.xiph.org/~greg/opus-tools_exp_dc4f83be.zip)  As JM says, thanks!

Note: these are my first steps with Opus, so I may have done something wrong.

Using the above build with foobar 1.1.14 beta 3 I tried the first track I came across, which happened to be "Pendulum - Slam" from the album "Hold Your Colour" which can be classified as Drum 'N' Bass. The quality was unexpectedly bad: mushy/metallic highs. Quick ABX 15/16. Done on my not-so-amazing PC speakers with a washing machine running in the background.

For kicks I tried using NeroACC in 2-pass ABR mode to achieve the same bitrate (which was 54kbps). The result sounded fine to me under the same circumstances. I may have imagined some lowpassing but it wasn't readily audible so I didn't bother to ABX.

The point is that Opus did significantly worse than NeroACC when I was expecting it to be similar. I can provide a sample if needed.

Settings in foobar for Opus: Target Bitrate 64, Bitrate Management VBR, Optimize for Music.

Code: [Select]
foo_abx 1.3.4 report
foobar2000 v1.1.14 beta 3
2012/08/14 15:07:19

File A: F:\tmp\soundcheck\Electronica\Pendulum - Slam (incl intro).flac
File B: F:\tmp\soundcheck\Electronica\Pendulum - Slam (incl intro)_opus.opus

15:07:19 : Test started.
15:07:44 : 01/01  50.0%
15:07:59 : 01/02  75.0%
15:08:16 : 02/03  50.0%
15:08:54 : 03/04  31.3%
15:09:00 : 04/05  18.8%
15:09:05 : 05/06  10.9%
15:09:10 : 06/07  6.3%
15:09:25 : 07/08  3.5%
15:09:33 : 08/09  2.0%
15:09:42 : 09/10  1.1%
15:09:53 : 10/11  0.6%
15:10:03 : 11/12  0.3%
15:10:10 : 12/13  0.2%
15:10:13 : 13/14  0.1%
15:10:17 : 14/15  0.0%
15:10:27 : 15/16  0.0%
15:10:31 : Test finished.

 ----------
Total: 15/16 (0.0%)
Title: IETF Opus codec now ready for testing
Post by: NullC on 2012-08-14 17:00:29
The point is that Opus did significantly worse than NeroACC when I was expecting it to be similar. I can provide a sample if needed.

Samples are helpful, also— can you try the non-experimental encoder (see http://www.opus-codec.org/downloads/ (http://www.opus-codec.org/downloads/) ) and see if its obviously better?
Title: IETF Opus codec now ready for testing
Post by: Gecko on 2012-08-14 20:07:25
Samples are helpful, also— can you try the non-experimental encoder (see http://www.opus-codec.org/downloads/ (http://www.opus-codec.org/downloads/) ) and see if its obviously better?

Sample: http://www.hydrogenaudio.org/forums/index....showtopic=96497 (http://www.hydrogenaudio.org/forums/index.php?showtopic=96497)

Using Headphones (Beyerdynamic DT 880):
Original vs. non-experimental (libopus 0.9.11-134-gda3b5f7): ABX 16/16 (felt significantly harder than this noon on my PC speakers)
experimental vs. non-experimental: ABX failed

Using PC speakers again (Teufel Concept E Magnum):
experimental vs. non-experimental: ABX 16/16 relatively easy. Non-experimental is clearly better.

Bitrates for the complete track (target bitrate 64 kbps):
NonExp: 62 kbps
Exp: 54 kbps

I would have expected the artifact to be blatantly obvious on headphones, but the opposite was the case. This was a first for me.

Orig vs. NonExp on headphones
Code: [Select]
foo_abx 1.3.4 report
foobar2000 v1.1.14 beta 3
2012/08/14 20:01:15

File A: F:\tmp\soundcheck\Electronica\Pendulum - Slam (incl intro).flac
File B: F:\tmp\soundcheck\Electronica\Pendulum - Slam (incl intro)_NonExp.opus

20:01:15 : Test started.
20:01:50 : 01/01  50.0%
20:01:55 : 02/02  25.0%
20:02:02 : 03/03  12.5%
20:02:54 : 04/04  6.3%
20:03:14 : 05/05  3.1%
20:03:25 : 06/06  1.6%
20:04:01 : 07/07  0.8%
20:04:23 : 08/08  0.4%
20:04:44 : 09/09  0.2%
20:04:59 : 10/10  0.1%
20:05:21 : 11/11  0.0%
20:05:33 : 12/12  0.0%
20:06:15 : 13/13  0.0%
20:06:34 : 14/14  0.0%
20:08:13 : 15/15  0.0%
20:08:20 : 16/16  0.0%
20:08:22 : Test finished.

 ----------
Total: 16/16 (0.0%)

Exp vs. NonExp on PC speakers
Code: [Select]
foo_abx 1.3.4 report
foobar2000 v1.1.14 beta 3
2012/08/14 20:46:39

File A: E:\tmp\Pendulum - Slam (excerpt)_Exp.opus
File B: E:\tmp\Pendulum - Slam (excerpt)_NonExp.opus

20:46:39 : Test started.
20:47:21 : 01/01  50.0%
20:47:34 : 02/02  25.0%
20:47:45 : 03/03  12.5%
20:48:04 : 04/04  6.3%
20:48:14 : 05/05  3.1%
20:48:36 : 06/06  1.6%
20:49:22 : 07/07  0.8%
20:49:41 : 08/08  0.4%
20:49:58 : 09/09  0.2%
20:50:05 : 10/10  0.1%
20:50:12 : 11/11  0.0%
20:50:30 : 12/12  0.0%
20:50:43 : 13/13  0.0%
20:51:02 : 14/14  0.0%
20:51:38 : 15/15  0.0%
20:51:45 : 16/16  0.0%
20:51:48 : Test finished.

 ----------
Total: 16/16 (0.0%)
Title: IETF Opus codec now ready for testing
Post by: El Stew on 2012-08-14 22:06:35
Thanks very much for reporting this. It was a silly bug that is now fixed in git. Let us know if you find any other issues where the experimental encoder is worse than 1.0.1-rc. Or even when it generally does poorly on a certain file.


Don't know if it matters, but:

In the VisualStudio project files for the experimental encoder there are some missing .c files that prevent it from compiling successfully. They have to be added manually.

Also some of the code in the experimental encoder uses the keyword "inline", which VisualStudio doesn't like in plain C code. Had to replace it with "__inline".
Title: IETF Opus codec now ready for testing
Post by: LigH on 2012-08-15 08:21:34
Again with Stranglehold:
LAME 3.99.5 -V2: 180.0 kbps
Ogg Vorbis aoTuVb6.03 SSE3 -q5: 129.1 kbps
QAAC 1.39 (CATB 7.9.7.9) -V82: 147.7 kbps
Opus 0.9.11-92 (rel. gc329045) music 160: 157.8 kbps (149.6-278.0)

Opus 0.9.11-134 (rel. gda3b5f7) music 160: 157.8 kbps (149.6-278.0) -- no change between Opus Tools 0.1.3 and 0.1.4
Opus 0.9.11-139 (exp. g2c7f8cd) music 160: 187.8 kbps (138.8-287.2)
Opus 0.9.11-142 (exp. 32024cb5) music 160: 189.2 kbps (137.6-311.6)
Opus 0.9.11-146 (exp. gdc4f83b) music 160: 190.6 kbps (137.2-316.0)

__

@ zerowalker:

Apropos ... unnecessary full-quotes are redundancy as well.
Title: IETF Opus codec now ready for testing
Post by: lvqcl on 2012-08-15 17:04:19
This sample (http://www.hydrogenaudio.org/forums/index.php?act=attach&type=post&id=6531) is easy to ABX with --bitrate 128 --music; both exp and 1.0.1-rc encoders.
(time range: 0:07.1 - 0:09.6)

Code: [Select]
foo_abx 1.3.4 report
foobar2000 v1.1.14 beta 3
2012/08/15 15:47:24

File A: E:\Samples\Interesting.flac
File B: E:\Samples\Interesting.opus

15:47:24 : Test started.
15:47:52 : 01/01  50.0%
15:47:56 : 02/02  25.0%
15:48:01 : 03/03  12.5%
15:48:07 : 04/04  6.3%
15:48:14 : 05/05  3.1%
15:48:18 : 06/06  1.6%
15:48:25 : 07/07  0.8%
15:48:30 : 08/08  0.4%
15:48:35 : 09/09  0.2%
15:48:39 : 10/10  0.1%
15:48:43 : 11/11  0.0%
15:48:47 : 12/12  0.0%
15:48:52 : Test finished.

 ----------
Total: 12/12 (0.0%)

Title: IETF Opus codec now ready for testing
Post by: mamboman on 2012-08-15 20:30:26
How can I preserve metadata/tags when converting flac files to opus on Linux?

When using oggenc to convert from flac to vorbis the tags are automatically preserved

With opusenc, however, as far as I can tell, I need to decode flac to wav first and then convert wav to opus and, in the process, tagging information is lost.
If I try to convert flac files directly to opus using opusenc I get an error message "error parsing input file".

Is there or will there be an easy way to preserve flac tags with opusenc - perhaps a command line switch?
I did try writing a bash script to do this but was struggling.

Is it necessary to convert to wav first or can opusenc convert flac to opus after all but I am doing something wrong?

I am using Debian Wheezy.

By the way, I think opus is a terrific codec and hope it gains wide adoption - it certainly deserves to.
Title: IETF Opus codec now ready for testing
Post by: The Link on 2012-08-15 21:25:53
How can I preserve metadata/tags when converting flac files to opus on Linux?
You could try it with caudec (https://code.google.com/p/caudec/).
Title: IETF Opus codec now ready for testing
Post by: jmvalin on 2012-08-16 05:14:48
To those who had problems on Windows, please try the new 1.0.1-rc2 release and see if it works now.
Title: IETF Opus codec now ready for testing
Post by: NullC on 2012-08-16 05:16:51
To those who had problems on Windows, please try the new 1.0.1-rc2 release and see if it works now.
Compiling on Windows.
Title: IETF Opus codec now ready for testing
Post by: NullC on 2012-08-16 14:45:14
Jmvalin has been working on some doubly experimental stuff that we hope improves the transient response.
It would be helpful if people could test it and compare it against the prior EXP builds: https://people.xiph.org/~greg/opus-tools_exp_tfsel5.zip (https://people.xiph.org/~greg/opus-tools_exp_tfsel5.zip)  (and against master, if you like but the comparison with regular exp is most important).
Title: IETF Opus codec now ready for testing
Post by: LigH on 2012-08-16 14:52:56
Yikes! Lots of debugging output!

Bitrate is in a similar high and very variable range as the other experimental builds.

Can't offer you a listening test right now, sorry.
Title: IETF Opus codec now ready for testing
Post by: IgorC on 2012-08-16 14:57:33
Can't offer you a listening test right now, sorry.

What do You mean?
Title: IETF Opus codec now ready for testing
Post by: LigH on 2012-08-16 15:03:23
I am at work in the office. Would be strange if I pumped up the volume right now.
Title: IETF Opus codec now ready for testing
Post by: NullC on 2012-08-16 15:33:40
Bitrate is in a similar high and very variable range as the other experimental builds.
This is not a problem. (I'm only commenting because people keep seeing these posts and thinking something is wrong and then not testing.)
Title: IETF Opus codec now ready for testing
Post by: LigH on 2012-08-16 16:21:01
 Uhm ... wow. You make it really hard for me. Either my ears are too old now, or your algorithms are too good. 

At 64 kbps, I could hardly spot any really obvious artefacts anymore. So I turned down the target bitrate to 48 kbps. And still, the artefacts were not even really annoying.

True, the release encoder has its flaws you can point at. In "Peter Heppner - Twelve"*, it is especially the second theme with the "subthreshold finger cymbals (or triangle)" (0:55-1:07 – for the complete song, not only Roberto's test part); they start to disappear in crackling noise.

But the experimental encoders are able to squeeze still a bit of melodic sound out of this part. And both are so similar to me, I couldn't decide which one is better.

Maybe another sample would tell me better. Maybe another listener has a more certain opinion than me.
_

*MODERATION: attempt to circumvent TOS#9 removed.
Title: IETF Opus codec now ready for testing
Post by: punkrockdude on 2012-08-16 18:31:00
I've tested the latest exp version and I am so surprised of the quality. Ten years years ago companies said that wma and aac sounded like mp3 128kbps at half the bitrate. That was not true, but now, Opus is almost there in my opinion.

By the way why is the sample rate always 48khz and does this make it possible for aliasing IF the decoder somehow resamples it back to 44.1khz? Another question is if 96kHz is or will be supported?

Regards.
Title: IETF Opus codec now ready for testing
Post by: Atak_Snajpera on 2012-08-16 18:53:06
Quote
By the way why is the sample rate always 48khz and does this make it possible for aliasing IF the decoder somehow resamples it back to 44.1khz? Another question is if 96kHz is or will be supported?

Regards.


Quote
Input sample rate

This is not the sample rate to use for playback of the encoded data.

Opus has a handful of coding modes, with internal audio bandwidths of 4, 6, 8, 12, and 20 kHz. Each packet in the stream may have a different audio bandwidth. Regardless of the audio bandwidth, the reference decoder supports decoding any stream at a sample rate of 8, 12, 16, 24, or 48 kHz. The original sample rate of the encoder input is not preserved by the lossy compression.

An Ogg Opus player SHOULD select the playback sample rate according to the following procedure:

    If the hardware supports 48 kHz playback, decode at 48 kHz,
    else if the hardware's highest available sample rate is a supported rate, decode at this sample rate,
    else if the hardware's highest available sample rate is less than 48 kHz, decode at the next higher supported rate and resample,
    else decode at 48 kHz and resample.

However, the 'input sample rate' field allows the encoder to pass the sample rate of the original input stream as metadata. This may be useful when the user requires the output sample rate to match the input sample rate. For example, a non-player decoder writing PCM format to disk might choose to resample the output audio back to the original input rate to reduce surprise to the user, who might reasonably expect to get back a file with the same sample rate as the one they fed to the encoder.

A value of zero indicates 'unspecified'. Encoders SHOULD write the actual input rate or zero, but decoder implementations which do something with this field SHOULD take care to behave sanely if given crazy values (e.g. don't actually upsample the output to 10 MHz if requested).


http://wiki.xiph.org/OggOpus (http://wiki.xiph.org/OggOpus)
Title: IETF Opus codec now ready for testing
Post by: jensend on 2012-08-16 19:22:16
I've tested the latest exp version and I am so surprised of the quality. Ten years years ago companies said that wma and aac sounded like mp3 128kbps at half the bitrate. That was not true, but now, Opus is almost there in my opinion.

By the way why is the sample rate always 48khz and does this make it possible for aliasing IF the decoder somehow resamples it back to 44.1khz? Another question is if 96kHz is or will be supported?

Opus uses 48kHz internally. This simplifies a lot of things about the design of the format and allows it to be more efficient.

Since a lossy audio format's goal is to provide a version which sounds like the original to human listeners, Opus doesn't waste any bits on information about frequencies above 20 kHz, which are inaudible to humans. That's pretty much the case for any other intelligent lossy audio format. If you want to encode lossy audio for bats' higher frequency hearing range, you may need to come up with a new format designed around bat psychoacoustics.

The opus-tools encoder records the sample rate and exact number of samples from your original file, and the opus-tools decoder uses a quality resampler and returns a file with the same sample rate and exact same number of samples. So 96kHz is supported in that the encoder will accept such a file and the decoder will give you a 96kHz file back, but the decoded file will have no >20kHz content.

No halfway decent resampler will have aliasing problems if used correctly. You generally get aliasing problems either with extremely poor quality resampling filters or if you're trying to use too narrow of a transition band for the resampler's filter. Downsampling to 44.1 with a 20kHz passband leaves a wide enough transition band (from 20kHz to the nyquist limit of 22.05kHz) for any good resampler to avoid aliasing.
Title: IETF Opus codec now ready for testing
Post by: Gecko on 2012-08-16 19:44:17
Jmvalin has been working on some doubly experimental stuff that we hope improves the transient response.
It would be helpful if people could test it and compare it against the prior EXP builds: https://people.xiph.org/~greg/opus-tools_exp_tfsel5.zip (https://people.xiph.org/~greg/opus-tools_exp_tfsel5.zip)  (and against master, if you like but the comparison with regular exp is most important).

I could not ABX build tfsel5 against dc4f83be at 64 kbps on the Pendulum sample on either headphones or PC speakers. The tfsel5 file is about 0.1% larger. As per the metadata, both files identify the encoder as libopus 0.9.11-146-gdc4f83b-exp_analysis.
Title: IETF Opus codec now ready for testing
Post by: kode54 on 2012-08-17 03:48:58
MSVC x64 build, which should be faster:

http://kode54.foobar2000.org/opus-tools_ex...l5_MSVC_x64.zip (http://kode54.foobar2000.org/opus-tools_exp_tfsel5_MSVC_x64.zip)
Title: IETF Opus codec now ready for testing
Post by: IgorC on 2012-08-17 04:27:10
Speed:
official  build - 47x
MSVC buiild - 51x

foobar, 2 threads, AMD Turion II P540, Windows 7 Enterprise 64 bits.
Title: IETF Opus codec now ready for testing
Post by: kode54 on 2012-08-17 04:39:31
It should be even faster when it's actually resampling the input.
Title: IETF Opus codec now ready for testing
Post by: IgorC on 2012-08-17 04:42:02
OK, it was a native 48 kHz input.
Title: IETF Opus codec now ready for testing
Post by: lvqcl on 2012-08-17 15:42:35
Encoding time of a test album (68m 22s):

44.1 kHz:
1.0.1-rc: 90.0 s
experim.: 104.0 s
tfsel-x32: 105.7 s
tfsel-x64: 97.5 s

after resampling to 48 kHz:
1.0.1-rc: 68.3 s
experim.: 90.4 s
tfsel-x32: 92.1 s
tfsel-x64: 82.0 s
Title: IETF Opus codec now ready for testing
Post by: 2304p on 2012-08-17 22:42:56
hello!

I downloaded the lastest one of opus and my antivirus reports: opus-tools.2012.08-16.zip is an infact file "Virus.JS.Psyme"

http://code.google.com/p/mulder/downloads/...;sort=-uploaded (http://mulder.googlecode.com/files/opus-tools.2012-08-16.zip)
Title: IETF Opus codec now ready for testing
Post by: LigH on 2012-08-17 22:54:43
False positives are always possible. Some antivirus tools are rather notorious...

VirusTotal (https://www.virustotal.com/file/8ea4c66f9f9ed57b005ea0d2df44fe10469fbea810c8384b83d41cbd41def4a8/analysis/1345240297/) reports 2/42, so it's most probably a false positive.

Emsisoft? Ikarus? They are not even known as most reliable detectors. Well possible they are provoked by generical CPU optimizations.
Title: IETF Opus codec now ready for testing
Post by: saratoga on 2012-08-18 00:48:55
hello!

I downloaded the lastest one of opus and my antivirus reports: opus-tools.2012.08-16.zip is an infact file "Virus.JS.Psyme"

http://code.google.com/p/mulder/downloads/...;sort=-uploaded (http://mulder.googlecode.com/files/opus-tools.2012-08-16.zip)


Get a better antivirus.
Title: IETF Opus codec now ready for testing
Post by: LigH on 2012-08-18 05:31:10
There is no "perfect" antivirus. They are all "snake oil" you would trust until they fail. They all didn't find Flame early, rated it at most "suspicious" for years; and even worse are the over-optimistic false positive heuristic results which detect usual Windows kernel features as malware (e.g. Avira kept users from logging in not only once).

But well ... this is an Audio forum.
Title: IETF Opus codec now ready for testing
Post by: Clifoo on 2012-08-18 18:39:00
I've found out that Opus with --music switch and without it produces same output (music is default). A hybid mode would be useful.
Anyway, I'd like to be able to switch between music/speech and stereo/mono at certain times of one stream by hand. On the main Opus page there was a statement that some options are dynamically adjustable.
Any chances for such features?
Title: IETF Opus codec now ready for testing
Post by: El Stew on 2012-08-18 22:27:50
By looking at the code, the signal type is set to OPUS_AUTO (as opposed to OPUS_SIGNAL_MUSIC or OPUS_SIGNAL_VOICE) when neither --music nor --speech has been specified.

I haven't looked into actual encoder lib deep enough to see what happens internally, but one would assume Opus selects the "suitable" signal type automatically in that case...
Title: IETF Opus codec now ready for testing
Post by: 2012 on 2012-08-19 00:00:44
It looks like the developers are busy. So, I will try to answer to the best of my understanding.

IIUC, Opus operates in 3 modes:

1) SILK only.
2) Hybrid.
3) CELT only.

The mode is selected based on requested bitrate/quality. Not based on the nature of content as one might think.

All --speech and --music do (at this point) is shift the mode decision lower or higher (in that order).

e.g. If you pass --music, CELT mode might be chosen instead of hybrid at a certain requested bitrate/quality.
Title: IETF Opus codec now ready for testing
Post by: m45t3r on 2012-08-19 04:30:44
I compiled rockbox-opus (https://github.com/freqmod/rockbox-opus) for Sansa Clip+ and did some performance tests as described on this page (http://www.rockbox.org/wiki/CodecPerformanceComparison). I transcoded flac_5.flac from Rockbox test_files (http://download.rockbox.org/test_files/) to Opus, starting with 8 kbps and doubling the bitrate up to the maximum (512 kbps), always using default mode. I used this (http://www.hydrogenaudio.org/forums/index.php?showtopic=86580&st=200&p=803283&#entry803283) compiled version of exp branch, forget to update my encoder before creating the files (there is a new compile fixing a bug) but shouldn't matter to much since is only a decode test. The vorbis_96.ogg and flac_5.flac are only references from test_files and a complete test can be obtained here (http://www.rockbox.org/wiki/CodecPerformanceComparison#AMS_AS3525v2_w_47_24MHz_PClK_40ARM926EJ_45S_41) (it's for Sansa Clip v2, but it shouldn't be too much different, since they use the same chipset (http://www.rockbox.org/wiki/SansaAMS#AMSv2_issues_40Fuzev2_44_Clipv2_44_Clip_43_44_ClipZip_41)).

It should be noted that Opus support on Rockbox is still very early and optimizations are expected (http://www.rockbox.org/mail/archive//rockbox-dev-archive-2012-08/0007.shtml). I'm trying to compile to Android too but I'm having some issues. If I can get it I will make some tests too.

Code: [Select]
vorbis_096.ogg
175906 of 175906
Decode time - 35.85s
File duration - 175.90s
490.65% realtime
48.91MHz needed for realtime

flac_5.flac
175906 of 175906
Decode time - 6.51s
File duration - 175.90s
2701.99% realtime
8.88MHz needed for realtime

opus_008.opus
176786 of 175914
Decode time - 11.98s
File duration - 175.91s
1468.36% realtime
16.34MHz needed for realtime

opus_016.opus
176786 of 175914
Decode time - 18.60s
File duration - 175.91s
945.75% realtime
25.37MHz needed for realtime

opus_032.opus
176786 of 175914
Decode time - 77.33s
File duration - 175.91s
227.47% realtime
105.50MHz needed for realtime

opus_064.opus
176786 of 175914
Decode time - 88.68s
File duration - 175.91s
198.36% realtime
120.99MHz needed for realtime

opus_128.opus
176786 of 175914
Decode time - 95.57s
File duration - 175.91s
184.06% realtime
130.39MHz needed for realtime

opus_256.opus
176786 of 175914
Decode time - 106.60s
File duration - 175.91s
165.01% realtime
145.44MHz needed for realtime

opus_512.opus
176006 of 175914
Decode time - 129.43s
File duration - 175.91s
135.91% realtime
176.58MHz needed for realtime
Title: IETF Opus codec now ready for testing
Post by: Garf on 2012-08-19 15:10:43
The mode is selected based on requested bitrate/quality. Not based on the nature of content as one might think.


This is the case only in the master branch, not in the exp encoder.
Title: IETF Opus codec now ready for testing
Post by: NullC on 2012-08-19 21:25:20
I've found out that Opus with --music switch and without it produces same output (music is default). A hybid mode would be useful.
Anyway, I'd like to be able to switch between music/speech and stereo/mono at certain times of one stream by hand. On the main Opus page there was a statement that some options are dynamically adjustable.
Any chances for such features?

I've now removed the --music and --speech options from opusenc, so they'll be gone in the next release. 2012's description (with Garf's addition) is accurate.  They don't really do much of anything useful, and I've yet to see evidence of people using them in a productive way: instead it seems that almost everyone assumes that they switch between MDCT and LP modes which isn't actually sensible as options.

What do you actually wish to accomplish with your hand switching?  In libopus all options are dynamically adjustable, though that mostly makes sense in realtime usage e.g. to adapt to network conditions changing or having the ability to change settings without dropping your call.  Without a use-case I don't know what kind of interface I'd provide for that in opusenc.
Title: IETF Opus codec now ready for testing
Post by: NullC on 2012-08-19 21:35:20
hello!
I downloaded the lastest one of opus and my antivirus reports: opus-tools.2012.08-16.zip is an infact file "Virus.JS.Psyme"

Uh. The opus-tools on the opus site report no such thing: https://www.virustotal.com/file/56092827e2a...a4806/analysis/ (https://www.virustotal.com/file/56092827e2a862c487285badc0beae0cb81e19f32e7623b061e4d8fbf55a4806/analysis/)

The file you linked to is not the official opus site, I don't know where they came from. The executables have been passed through some kind encryption/obfuscation (none of the normal strings are visible in the binaries) which has made them _substantially_ larger (e.g. opusinfo.exe has gone from 60k to 211k), I would not be too surprised if they were in fact malware infected.
Title: IETF Opus codec now ready for testing
Post by: LigH on 2012-08-19 21:50:09
LoRd MuldeR will be notified.
Title: IETF Opus codec now ready for testing
Post by: lvqcl on 2012-08-19 22:39:16
The file you linked to is not the official opus site, I don't know where they came from. The executables have been passed through some kind encryption/obfuscation (none of the normal strings are visible in the binaries) which has made them _substantially_ larger (e.g. opusinfo.exe has gone from 60k to 211k), I would not be too surprised if they were in fact malware infected.


They are packed with UPX. ~470 kb after unpacking, but I think that's because they were compiled with Intel C/C++ Compiler.
Title: IETF Opus codec now ready for testing
Post by: m45t3r on 2012-08-20 00:12:39
So here I have the results of rockbox-opus on Android. The device used was a Samsung Galaxy S II I9100 (http://www.gsmarena.com/samsung_galaxy_nexus-4219.php). I compiled using the default settings, what it means it compiled for ARMv5 instructions, but the SGS II support the ARMv7 instructions. I'll try to compile for ARMv7 later. Since there is no reference to this processor, I did a full test, including all samples on test_files (http://download.rockbox.org/test_files/) page.

One note, the phone a little hot and drains the battery very fast when using Opus. This test shows that the cause is Opus using way more CPU time than other codecs. It's normal since Opus isn't optimized yet.

Code: [Select]
opus_512.opus
176006 of 175914
Decode time - 12.76s
File duration - 175.91s
1378.60% realtime

opus_256.opus
176786 of 175914
Decode time - 9.88s
File duration - 175.91s
1780.46% realtime

opus_128.opus
176786 of 175914
Decode time - 8.02s
File duration - 175.91s
2193.39% realtime

opus_064.opus
176786 of 175914
Decode time - 6.56s
File duration - 175.91s
2681.55% realtime

opus_032.opus
176786 of 175914
Decode time - 5.50s
File duration - 175.91s
3198.36% realtime

opus_016.opus
176786 of 175914
Decode time - 1.94s
File duration - 175.91s
9067.52% realtime

opus_008.opus
176786 of 175914
Decode time - 1.22s
File duration - 175.91s
14418.85% realtime

vorbis_096.ogg
175906 of 175906
Decode time - 1.94s
File duration - 175.90s
9067.01% realtime

flac_5.flac
175906 of 175906
Decode time - 1.01s
File duration - 175.90s
17415.84% realtime

pegase_l2_192.mp2
175897 of 175908
Decode time - 2.33s
File duration - 175.90s
7549.35% realtime

lame_192.mp3
175909 of 175960
Decode time - 2.69s
File duration - 175.96s
6541.26% realtime

wv_normx4.wv
175900 of 175906
Decode time - 2.89s
File duration - 175.90s
6086.50% realtime

wv_fastx3.wv
175900 of 175906
Decode time - 2.47s
File duration - 175.90s
7121.45% realtime

wma_96.wma
174294 of 177504
Decode time - 1.99s
File duration - 177.50s
8919.59% realtime

wma_320.wma
174294 of 177504
Decode time - 2.17s
File duration - 177.50s
8179.72% realtime

wma_256.wma
174294 of 177504
Decode time - 2.11s
File duration - 177.50s
8412.32% realtime

wma_192.wma
174294 of 177504
Decode time - 2.42s
File duration - 177.50s
7334.71% realtime

wma_128.wma
174294 of 177504
Decode time - 2.50s
File duration - 177.50s
7100.00% realtime

wmapro_80k.wma
174248 of 178941
Decode time - 2.31s
File duration - 178.94s
7746.32% realtime

wmapro_55k.wma
174248 of 178941
Decode time - 2.29s
File duration - 178.94s
7813.97% realtime

wmapro_271k.wma
174248 of 178941
Decode time - 2.79s
File duration - 178.94s
6413.62% realtime

wmapro_173k.wma
174248 of 178941
Decode time - 2.58s
File duration - 178.94s
6935.65% realtime

wmapro_141k.wma
174248 of 178941
Decode time - 2.40s
File duration - 178.94s
7455.83% realtime

vorbis_500.ogg
175906 of 175906
Decode time - 2.92s
File duration - 175.90s
6023.97% realtime

vorbis_350.ogg
175906 of 175906
Decode time - 3.37s
File duration - 175.90s
5219.58% realtime

vorbis_256.ogg
175906 of 175906
Decode time - 2.49s
File duration - 175.90s
7064.25% realtime

vorbis_192.ogg
175906 of 175906
Decode time - 2.48s
File duration - 175.90s
7092.74% realtime

vorbis_128.ogg
175906 of 175906
Decode time - 2.07s
File duration - 175.90s
8497.58% realtime

true_audio.tta
175000 of 175000
Decode time - 4.37s
File duration - 175.00s
4004.57% realtime

pegase_l2_384.mp2
175897 of 175908
Decode time - 2.34s
File duration - 175.90s
7517.09% realtime

pegase_l2_256.mp2
175897 of 175908
Decode time - 2.38s
File duration - 175.90s
7390.75% realtime

pegase_l2_128.mp2
175897 of 175908
Decode time - 1.84s
File duration - 175.90s
9559.78% realtime

pegase_l1_448.mp1
175908 of 175908
Decode time - 2.43s
File duration - 175.90s
7238.68% realtime

pegase_l1_352.mp1
175908 of 175908
Decode time - 2.16s
File duration - 175.90s
8143.51% realtime

pegase_l1_256.mp1
175908 of 175908
Decode time - 2.07s
File duration - 175.90s
8497.58% realtime

pegase_l1_192.mp1
175908 of 175908
Decode time - 2.26s
File duration - 175.90s
7783.18% realtime

nero_he_64.m4a
175906 of 176017
Decode time - 7.33s
File duration - 176.01s
2401.22% realtime

nero_hev2_64.m4a
175906 of 176034
Decode time - 8.06s
File duration - 176.03s
2183.99% realtime

nero_400.m4a
175906 of 175966
Decode time - 3.56s
File duration - 175.96s
4942.69% realtime

nero_320.m4a
175906 of 175966
Decode time - 3.48s
File duration - 175.96s
5056.32% realtime

nero_256.m4a
175906 of 175966
Decode time - 2.94s
File duration - 175.96s
5985.03% realtime

nero_192.m4a
175906 of 175966
Decode time - 3.01s
File duration - 175.96s
5845.84% realtime

nero_128.m4a
175906 of 175966
Decode time - 2.46s
File duration - 175.96s
7152.84% realtime

nero_096.m4a
175906 of 175966
Decode time - 2.30s
File duration - 175.96s
7650.43% realtime

mpc_350.mpc
175906 of 175906
Decode time - 1.86s
File duration - 175.90s
9456.98% realtime

mpc_300.mpc
175906 of 175906
Decode time - 1.85s
File duration - 175.90s
9508.10% realtime

mpc_224.mpc
175906 of 175906
Decode time - 1.64s
File duration - 175.90s
10725.60% realtime

mpc_170.mpc
175906 of 175906
Decode time - 1.82s
File duration - 175.90s
9664.83% realtime

mpc_128.mpc
175906 of 175906
Decode time - 1.53s
File duration - 175.90s
11496.73% realtime

mpc_096.mpc
175906 of 175906
Decode time - 1.39s
File duration - 175.90s
12654.67% realtime

lame_320.mp3
175909 of 175960
Decode time - 3.07s
File duration - 175.96s
5731.59% realtime

lame_256.mp3
175909 of 175960
Decode time - 3.06s
File duration - 175.96s
5750.32% realtime

lame_128.mp3
175909 of 175960
Decode time - 2.76s
File duration - 175.96s
6375.36% realtime

lame_096.mp3
175951 of 175968
Decode time - 1.96s
File duration - 175.96s
8977.55% realtime

flac_8.flac
175906 of 175906
Decode time - 1.07s
File duration - 175.90s
16439.25% realtime

cook_stereo_96.ra
176431 of 175906
Decode time - 3.21s
File duration - 175.90s
5479.75% realtime

cook_stereo_64.ra
176431 of 175906
Decode time - 3.13s
File duration - 175.90s
5619.80% realtime

cook_stereo_32.ra
176431 of 175904
Decode time - 1.24s
File duration - 175.90s
14185.48% realtime

cook_mono_64.ra
176431 of 175904
Decode time - 1.51s
File duration - 175.90s
11649.00% realtime

cook_mono_32.ra
177449 of 175904
Decode time - 1.39s
File duration - 175.90s
12654.67% realtime

atrac3_lp2_132.oma
174294 of 176360
Decode time - 3.11s
File duration - 176.36s
5670.73% realtime

applelossless.m4a
175906 of 175906
Decode time - 5.00s
File duration - 175.90s
3518.00% realtime

ape_c5000.ape
175906 of 175906
Decode time - 126.73s
File duration - 175.90s
138.79% realtime

ape_c4000.ape
175906 of 175906
Decode time - 34.91s
File duration - 175.90s
503.86% realtime

ape_c3000.ape
175906 of 175906
Decode time - 11.58s
File duration - 175.90s
1518.99% realtime

ape_c2000.ape
175906 of 175906
Decode time - 9.91s
File duration - 175.90s
1774.97% realtime

ape_c1000.ape
175906 of 175906
Decode time - 9.08s
File duration - 175.90s
1937.22% realtime

a52_stereo_192.ac3
176325 of 176000
Decode time - 1.89s
File duration - 176.00s
9312.16% realtime
Title: IETF Opus codec now ready for testing
Post by: Brazil2 on 2012-08-20 16:22:03
There already is: bass_opus.dll (http://www.un4seen.com/forum/?topic=13870.0) (still experimental, but seems to be working great) in combination with BassAudio (http://forum.doom9.org/showthread.php?t=104686).

But it seems to be a complete channels mayhem with 5.1 files or is it only me ?
I've encoded 6_Channel_ID.wav (http://ftp://ftp1.fraunhofer.de/institute/iis/amm/mp3surround/DemoSongs/6_Channel_ID.wav) with opus-tools-0.1.4-win32 but I've found nothing using BASSOPUS.dll which can properly play it back. And same goes with the release version of the DLL. However decoding back to WAV creates a working file.
Title: IETF Opus codec now ready for testing
Post by: LoRd_MuldeR on 2012-08-20 20:33:38
hello!
I downloaded the lastest one of opus and my antivirus reports: opus-tools.2012.08-16.zip is an infact file "Virus.JS.Psyme"

Uh. The opus-tools on the opus site report no such thing: https://www.virustotal.com/file/56092827e2a...a4806/analysis/ (https://www.virustotal.com/file/56092827e2a862c487285badc0beae0cb81e19f32e7623b061e4d8fbf55a4806/analysis/)

The file you linked to is not the official opus site, I don't know where they came from. The executables have been passed through some kind encryption/obfuscation (none of the normal strings are visible in the binaries) which has made them _substantially_ larger (e.g. opusinfo.exe has gone from 60k to 211k), I would not be too surprised if they were in fact malware infected.


Please see:
http://lamexp.sourceforge.net/doc/FAQ.html#96205e91 (http://lamexp.sourceforge.net/doc/FAQ.html#96205e91)
Title: IETF Opus codec now ready for testing
Post by: mamboman on 2012-08-20 23:16:38
In the man page for opusenc it says that bigger framesizes yield more quality at a given bitrate but it also says:

"Sizes greater than 20ms  are  only  interesting  at  fairly  low bitrates."

In this context, what is regarded as a low bitrate?
Is it worth increasing framesize at the default bitrate of 96kbps or will this have a negligible impact upon quality?
I am not sure whether 96kbps is considered to be a fairly low bitrate or not given that opus can go as low as 6kbps.

Presumably what is considered a low bitrate for music would probably not be considered a low bitrate for speech?

Also, is there a Debian package of the Xiph ABX program Squishyball available to download anywhere? I would like to do some ABX tests with opus but, as I use Linux, foobar is not an option.
Title: IETF Opus codec now ready for testing
Post by: jensend on 2012-08-20 23:55:52
Is it worth increasing framesize at the default bitrate of 96kbps or will this have a negligible impact upon quality?
I am not sure whether 96kbps is considered to be a fairly low bitrate or not given that opus can go as low as 6kbps.
96kbps is definitely not a low bitrate in most opus contexts. The bitrate savings of the >20ms frames is about 0.4kbps, which won't be noticeable above 16kbps. (http://lists.xiph.org/pipermail/opus/2011-November/001608.html) The longer frames also save transport protocol/container overhead if you're streaming over the Internet or whatever; that can be a much bigger deal, but is irrelevant for opusenc.
Quote
Presumably what is considered a low bitrate for music would probably not be considered a low bitrate for speech?
Actually, in this instance it doesn't matter; stereo vs mono doesn't matter either. It's just a question of how 0.4kbps compares to your target bitrate.
Quote
Also, is there a Debian package of the Xiph ABX program Squishyball available to download anywhere? I would like to do some ABX tests with opus but, as I use Linux, foobar is not an option.
I don't see any Debian package, but it compiles from source quite easily and cleanly in my experience. You could also use the java version of ABC/HR from rarewares.
Title: IETF Opus codec now ready for testing
Post by: Speckmade on 2012-08-21 00:07:41
In this context, what is regarded as a low bitrate?

Bitrates, where overhead from transmission protocols gets relevant.

Is it worth increasing framesize at the default bitrate of 96kbps or will this have a negligible impact upon quality?

So: no.
Title: IETF Opus codec now ready for testing
Post by: CoRoNe on 2012-08-21 17:30:37
I've encoded 6_Channel_ID.wav (http://ftp://ftp1.fraunhofer.de/institute/iis/amm/mp3surround/DemoSongs/6_Channel_ID.wav) with opus-tools-0.1.4-win32 but I've found nothing using BASSOPUS.dll which can properly play it back. And same goes with the release version of the DLL. However decoding back to WAV creates a working file.
I have no idea why they release it as bassopus.dll, because you have to rename it to bass_opus.dll for it to work.

But it seems to be a complete channels mayhem with 5.1 files or is it only me?
Strange indeed. Although the opus-tools should have multichannel support (https://wiki.xiph.org/OPUS_TODO#Opus-tools) (don't know who doneish is), they spit out stereo only.
Title: IETF Opus codec now ready for testing
Post by: kode54 on 2012-08-21 18:46:03
For it to even play streams normally in BASS, you need to load it with BASS_PluginLoad.
Title: IETF Opus codec now ready for testing
Post by: NullC on 2012-08-22 03:47:47
Although the opus-tools should have multichannel support (https://wiki.xiph.org/OPUS_TODO#Opus-tools) (don't know who doneish is), they spit out stereo only.
Huh? Opus-tools has complete multichannel support, and multichannel files round trip fine. If you force it to crazy low bitrates it will downmix for you rather than produce crap, but it warns you when it does this.
Title: IETF Opus codec now ready for testing
Post by: mudlord on 2012-08-22 05:48:03
There is no "perfect" antivirus. They are all "snake oil" you would trust until they fail. They all didn't find Flame early, rated it at most "suspicious" for years; and even worse are the over-optimistic false positive heuristic results which detect usual Windows kernel features as malware (e.g. Avira kept users from logging in not only once).

But well ... this is an Audio forum.


Excuse me, but Flame is a state sanctioned rootkit. Of course it won't be detected! Did you know some mobs pay AV companies to NOT detect thier crap? 
Title: IETF Opus codec now ready for testing
Post by: Atak_Snajpera on 2012-08-22 11:56:32
I must admit that Opus at 64kbps with some magic tuning may finally reach mp3 CBR 128 (joint-stereo) in terms of quality.
Already Opus 64kbps sounds less annoying than mp3 CBR 128 (stereo) for me!
Title: IETF Opus codec now ready for testing
Post by: LithosZA on 2012-08-22 12:00:59
Document is in AUTH48 State
Title: IETF Opus codec now ready for testing
Post by: CoRoNe on 2012-08-22 17:16:39
Huh? Opus-tools has complete multichannel support, and multichannel files round trip fine. If you force it to crazy low bitrates it will downmix for you rather than produce crap, but it warns you when it does this.
Code: [Select]
Notice: Surround bitrate less than 32kbit/sec/channel, downmixing.
Ah, I see. I'm using Foobar, so I didn't know.

But it seems to be a complete channels mayhem with 5.1 files or is it only me?
I can now reproduce the issue with bass_opus.dll indeed. It seems the opus-plugin for Foobar doesn't have multichannel support at all.
Title: IETF Opus codec now ready for testing
Post by: Garf on 2012-08-22 20:46:27
It seems the opus-plugin for Foobar doesn't have multichannel support at all.


Of course it does. Please post in more detail what you're doing (wrong :-)).
Title: IETF Opus codec now ready for testing
Post by: CoRoNe on 2012-08-22 21:22:30
Ugh...darn dsp filters. Wouldn't accept multichannel. Sorry, my bad!
Title: IETF Opus codec now ready for testing
Post by: CoRoNe on 2012-08-23 21:32:17
I've encoded 6_Channel_ID.wav (http://ftp://ftp1.fraunhofer.de/institute/iis/amm/mp3surround/DemoSongs/6_Channel_ID.wav) with opus-tools-0.1.4-win32 but I've found nothing using BASSOPUS.dll which can properly play it back.

BASSOPUS 2.4.0.1 (http://www.un4seen.com/download.php?bassopus24) should fix that problem.
Title: IETF Opus codec now ready for testing
Post by: zerowalker on 2012-08-25 20:22:06
Document is in AUTH48 State


What does that mean;O?
Is it soon approved?
Title: IETF Opus codec now ready for testing
Post by: db1989 on 2012-08-25 21:39:10
From Google:
http://www.rfc-editor.org/pubprocess.html#auth48 (http://www.rfc-editor.org/pubprocess.html#auth48)
Title: IETF Opus codec now ready for testing
Post by: IgorC on 2012-08-26 01:18:49
Have tried these two builds on transients samples at 64 kbps.
https://people.xiph.org/~greg/opus-tools_exp_tfsel5.zip (https://people.xiph.org/~greg/opus-tools_exp_tfsel5.zip) (have called it as transients2)
https://people.xiph.org/~greg/opus-tools_exp_32024cb5.zip (https://people.xiph.org/~greg/opus-tools_exp_32024cb5.zip) (transients1)


Velvet sample. T2 and T1 have the same bitrate and less or more the  same quality.
Code: [Select]
ABC/HR for Java, Version 0.53a, 25 August 2012
Testname:

Tester: IgorC

1L = D:\Opus\opus_transients_TEST\Samples for transients2\01 Velvet\velvet_TRANSIENTS_1.wav
2R = D:\Opus\opus_transients_TEST\Samples for transients2\01 Velvet\velvet_TRANSIENTS_2.wav

Ratings on a scale from 1.0 to 5.0

---------------------------------------
General Comments:
---------------------------------------
1L File: D:\Opus\opus_transients_TEST\Samples for transients2\01 Velvet\velvet_TRANSIENTS_1.wav
1L Rating: 3.0
1L Comment:
---------------------------------------
2R File: D:\Opus\opus_transients_TEST\Samples for transients2\01 Velvet\velvet_TRANSIENTS_2.wav
2R Rating: 3.0
2R Comment:
---------------------------------------

ABX Results:

Fatboy. T2 - 92 kbps, T1 - 90 kbps.
Code: [Select]
ABC/HR for Java, Version 0.53a, 25 August 2012
Testname:

Tester: IgorC

1L = D:\Opus\opus_transients_TEST\Samples for transients2\02 Fatboy\fatboy_TRANSIENTS_2.wav
2R = D:\Opus\opus_transients_TEST\Samples for transients2\02 Fatboy\fatboy_TRANSIENTS_1.wav

Ratings on a scale from 1.0 to 5.0

---------------------------------------
General Comments:
---------------------------------------
1L File: D:\Opus\opus_transients_TEST\Samples for transients2\02 Fatboy\fatboy_TRANSIENTS_2.wav
1L Rating: 3.5
1L Comment:
---------------------------------------
2R File: D:\Opus\opus_transients_TEST\Samples for transients2\02 Fatboy\fatboy_TRANSIENTS_1.wav
2R Rating: 3.3
2R Comment: The strange clicking-like pulse during the first second.
---------------------------------------

ABX Results:
D:\Opus\opus_transients_TEST\Samples for transients2\02 Fatboy\fatboy_TRANSIENTS_2.wav vs D:\Opus\opus_transients_TEST\Samples for transients2\02 Fatboy\fatboy_TRANSIENTS_1.wav
    5 out of 5, pval = 0.031


---- Detailed ABX results ----
D:\Opus\opus_transients_TEST\Samples for transients2\02 Fatboy\fatboy_TRANSIENTS_2.wav vs D:\Opus\opus_transients_TEST\Samples for transients2\02 Fatboy\fatboy_TRANSIENTS_1.wav
Playback Range: 00.000 to 29.206
    8:20:04 PM p 1/1 pval = 0.5
    8:20:06 PM p 2/2 pval = 0.25
    8:20:08 PM p 3/3 pval = 0.125
    8:20:14 PM p 4/4 pval = 0.062
    8:20:16 PM p 5/5 pval = 0.031


EIG. T2 and T1 have the same bitrate.
Code: [Select]
ABC/HR for Java, Version 0.53a, 25 August 2012
Testname:

Tester: IgorC

1L = D:\Opus\opus_transients_TEST\Samples for transients2\03 EIG\eig_TRANSIENTS2.wav
2R = D:\Opus\opus_transients_TEST\Samples for transients2\03 EIG\eig_TRANSIENTS1.wav

Ratings on a scale from 1.0 to 5.0

---------------------------------------
General Comments:
---------------------------------------
1L File: D:\Opus\opus_transients_TEST\Samples for transients2\03 EIG\eig_TRANSIENTS2.wav
1L Rating: 3.0
1L Comment:
---------------------------------------
2R File: D:\Opus\opus_transients_TEST\Samples for transients2\03 EIG\eig_TRANSIENTS1.wav
2R Rating: 3.2
2R Comment: Less clicking.
---------------------------------------

ABX Results:
D:\Opus\opus_transients_TEST\Samples for transients2\03 EIG\eig_TRANSIENTS2.wav vs D:\Opus\opus_transients_TEST\Samples for transients2\03 EIG\eig_TRANSIENTS1.wav
    5 out of 5, pval = 0.031


---- Detailed ABX results ----
D:\Opus\opus_transients_TEST\Samples for transients2\03 EIG\eig_TRANSIENTS2.wav vs D:\Opus\opus_transients_TEST\Samples for transients2\03 EIG\eig_TRANSIENTS1.wav
Playback Range: 00.000 to 15.000
    8:58:18 PM p 1/1 pval = 0.5
    8:58:23 PM p 2/2 pval = 0.25
    8:58:30 PM p 3/3 pval = 0.125
    8:58:35 PM p 4/4 pval = 0.062
    8:58:40 PM p 5/5 pval = 0.031

T2 was better than T1 only on Fatboy sample while also increases bitrate for it a bit.
Title: IETF Opus codec now ready for testing
Post by: Brazil2 on 2012-08-28 11:09:17
I've encoded 6_Channel_ID.wav (http://ftp://ftp1.fraunhofer.de/institute/iis/amm/mp3surround/DemoSongs/6_Channel_ID.wav) with opus-tools-0.1.4-win32 but I've found nothing using BASSOPUS.dll which can properly play it back.

BASSOPUS 2.4.0.1 (http://www.un4seen.com/download.php?bassopus24) should fix that problem.

This version is now working fine, thanks for the info
Title: IETF Opus codec now ready for testing
Post by: zerowalker on 2012-09-02 14:49:35
I know i asked this before, but when is OPUS supposed to be released?
And what is it about the IEFT, is it approved or what?
Where can i check the status?

Thanks:)!
Title: IETF Opus codec now ready for testing
Post by: LithosZA on 2012-09-02 15:52:35
Quote
Where can i check the status?

http://tools.ietf.org/wg/codec/ (http://tools.ietf.org/wg/codec/)


Title: IETF Opus codec now ready for testing
Post by: mamboman on 2012-09-03 23:15:11
With the official release of opus imminent would be curious to know how we can anticipate future development.

Is future opus development likely to be mainly community driven (as Vorbis was with different tunings such as those of Aoyumi)?

Once opus is officially released will Xiph then concentrate their efforts upon another project (such as Ghost or some video codec work) or will official opus development continue to be priority for foreseeable future?

Also, being a bit speculative here but would be interesting to hear do folks believe that in time opus will be likely to supersede Vorbis as the open source lossy codec of choice for pre-recorded music?
I am sure Vorbis will be around for some time, but will Opus relegate it to being a legacy format as newer users favour opus?
Title: IETF Opus codec now ready for testing
Post by: NullC on 2012-09-04 19:55:26
There is a new opus 1.0.1 RC3 release candidate up, as well as a 0.1.5 opus-tools at http://www.opus-codec.org/downloads/ (http://www.opus-codec.org/downloads/) .  These releases make minor build system changes and other small cleanups, other than some command-line options being changed a bit in opus-tools they are functionally identical to prior versions.

As always testing and trouble reports are appreciated.
Title: IETF Opus codec now ready for testing
Post by: darkbyte on 2012-09-06 12:50:40
I've encoded some C64 game music with Opus using the latest exp build with --bitrate 96 and they ended up as ~160kbps VBR files although the sources where mono. Is this a bug or just Opus likes SID music that much?
Title: IETF Opus codec now ready for testing
Post by: LithosZA on 2012-09-06 13:28:22
Weird, does CVBR do the same?
Title: IETF Opus codec now ready for testing
Post by: Martel on 2012-09-06 13:40:03
Did you use some low-pass with the C64 stuff? I know I tried some emulator once and it was producing way too much harmonics above 12kHz, it was practically unlistenable using monitoring headphones (unless you like your ears bleeding from the treble).
Title: IETF Opus codec now ready for testing
Post by: jmvalin on 2012-09-06 14:31:39
I've encoded some C64 game music with Opus using the latest exp build with --bitrate 96 and they ended up as ~160kbps VBR files although the sources where mono. Is this a bug or just Opus likes SID music that much?


Are you talking about a one-channel file or a two-channel file where both channels are the same. If it's the former, then the behaviour is probably normal considering that your C64 music is likely highly tonal.
Title: IETF Opus codec now ready for testing
Post by: LigH on 2012-09-06 14:34:37
The SID synthesizer is rather simple, the spectrum of frequencies probably very distinct. Similar to the results for "Stranglehold".
Title: IETF Opus codec now ready for testing
Post by: darkbyte on 2012-09-06 16:38:36
Weird, does CVBR do the same?

I'll try this out later.

Did you use some low-pass with the C64 stuff? I know I tried some emulator once and it was producing way too much harmonics above 12kHz, it was practically unlistenable using monitoring headphones (unless you like your ears bleeding from the treble).

Haven't used lowpass. The source was a 44.1kHz Mono 16 bit WAV file.

Are you talking about a one-channel file or a two-channel file where both channels are the same. If it's the former, then the behaviour is probably normal considering that your C64 music is likely highly tonal.

Yes, it was a single channel WAV file. They are the tunes of the game: Creatures.

The SID synthesizer is rather simple, the spectrum of frequencies probably very distinct. Similar to the results for "Stranglehold".

Probably. But the bitrate is still much more higher than expected
Title: IETF Opus codec now ready for testing
Post by: softrunner on 2012-09-07 02:31:57
There is a new opus 1.0.1 RC3 release candidate up, as well as a 0.1.5 opus-tools at http://www.opus-codec.org/downloads/ (http://www.opus-codec.org/downloads/) .  These releases make minor build system changes and other small cleanups, other than some command-line options being changed a bit in opus-tools they are functionally identical to prior versions.

As always testing and trouble reports are appreciated.

Why "--music" option was removed?

Imho, the usage of the encoder should be like this:
> opusenc [options] input_file [output_file[.opus]]
If no output file is specified, it should become input_file_name.opus automatically. If no extension for output file is specified, it should become ".opus" automatically (except when there is a "." at the end of it).
Title: IETF Opus codec now ready for testing
Post by: saratoga on 2012-09-07 02:41:34
Why "--music" option was removed?


http://www.hydrogenaudio.org/forums/index....st&p=805845 (http://www.hydrogenaudio.org/forums/index.php?showtopic=86580&view=findpost&p=805845)

Title: IETF Opus codec now ready for testing
Post by: Dynamic on 2012-09-08 17:58:36
From http://wiki.xiph.org/OggOpus (http://wiki.xiph.org/OggOpus):
Quote
If a tool modifies the OpusHead "output gain" field, it MUST also update or remove the R128_TRACK_GAIN comment field.

There is no comment field corresponding to Replaygain's ALBUM_GAIN; that information should instead be stored in the OpusHead 'output gain' field.

To avoid confusion with multiple normalization schemes, an OpusTags packet SHOULD NOT contain any of the REPLAYGAIN_TRACK_GAIN, REPLAYGAIN_TRACK_PEAK, REPLAYGAIN_ALBUM_GAIN, or REPLAYGAIN_ALBUM_PEAK fields.


Good to see R128 as default.

I'm just wondering about the implications of this for people using OPUS as a music storage format (rather than streaming).

While I'm entirely happy to normalize all my music using Album Gain, I know there are people who are a bit 'precious' about preserving of being able to revert to the 'original loudness' of the tracks as if it were 'intended' by a mastering engineer with reference to a standard, which is barely ever the case, unlike with calibrated movie theatre audio.

Can the reversion gain be applied in an optional and unsupported comment tag field (which could eventually be used to modify the file to retroactively adjust the mandatory 'output gain' field, and also update or remove the R128_TRACK_GAIN comment field as it MUST), or would most encoders be likely (but not guaranteed) to produce the original loudness by treating the OpusHead 'output gain' field as if it were zero?
Title: IETF Opus codec now ready for testing
Post by: LigH on 2012-09-12 12:10:49
Possibly interesting sidenote:

A "notorious" (politically interested) german blogger and podcaster, Fefe, discovered Opus as a) efficient codec for speech, to save bandwidth; b) flagship of freedom, using patent-free open-source code. So I'd expect the next releases of "Alternativlos" being offered in Opus as well. And that may just be a beginning...
Title: IETF Opus codec now ready for testing
Post by: Silversight on 2012-09-14 12:36:16
Chiptunes and similarly synthesized music seem to pose a problem for Opus. I've encountered a difficult sample for Opus 1.0.1 RC3: The beginning of the track "Flicker" by Big Giant Circles, which consists of two side-alternating NES-like synths.

Opus produces a distortion that is quite annoying up to VBR ~130 kbit/s and can be ABXed up to VBR ~200 kbit/s. The distortion is most noticeable in the first 5-6 seconds, after which an underlying pad sound begins to make distinction a little more difficult. I also did a test with VBR ~300 kbit/s but could not get conclusive ABX results.

I've uploaded the sample FLAC, the encoded Opus files and the ABX results for 130, 160 and 200 kbit/s VBR here (http://dl.dropbox.com/u/1100000/bgc_flicker_sample.zip) so you can have a look (and a listen) at it. I don't have access to my FTP from the office, so Dropbox will have to do.

Download Sample ZIP (http://dl.dropbox.com/u/1100000/bgc_flicker_sample.zip)
Title: IETF Opus codec now ready for testing
Post by: NullC on 2012-09-14 13:17:47
Chiptunes and similarly synthesized music seem to pose a problem for Opus. I've encountered a difficult sample for Opus 1.0.1 RC3: The beginning of the track "Flicker" by Big Giant Circles, which consists of two side-alternating NES-like synths.

Please be sure to also try the exp encoder higher up in the thread here.

Thanks for the report.
Title: IETF Opus codec now ready for testing
Post by: Silversight on 2012-09-15 01:28:21
Please be sure to also try the exp encoder higher up in the thread here.
I've tested the two exp encoders from #365 and got results similar to those of darkbyte's SID music: With both encoders, bitrates were way higher than with 1.0.1 RC3. Here's a crude table with the average bitrates of the three encoders for different encoding settings. T1 is g32024cb, T2 is gdc4f83b, in tune with #365.

Code: [Select]
Setting      1.0.1RC3 T1   T2

VBR 64          66    130  118
VBR 100        103    191  182
VBR 130        134    239  233
VBR 200        206    348  346
The sound quality was significantly higher for each setting, which did not surprise me that much anymore after looking at the bitrate. Still, VBR 130 (exp) was still ABX-able despite the high bitrate. I didn't try ABXing anything higher than that due to fatigue (tests were done around 1 am, it's 2:30 am now). Also, I could not find any audible differences between the two exp encoders at any of the tested quality settings.

Out of curiosity, I also did a matchup between 1.0.1RC3 and T1 at CVBR 64. Here T1 produces the same kind of distorted noise, but it is louder than with 1.0.1RC3.

Download audio and ABX results (http://dl.dropbox.com/u/1100000/bgc_flicker_exp.zip)
Title: IETF Opus codec now ready for testing
Post by: Undesirable on 2012-09-15 06:28:37
I thought you guys might like to know that the PowerAMP for Android developers have confirmed that they're integrating the OPUS CODEC into the app soon:

Quote
Actually, we're looking into adding it. Most probably will be in the next intermediate build.
Thanks!

Title: IETF Opus codec now ready for testing
Post by: foxyshadis on 2012-09-15 08:07:23
Chiptunes and similarly synthesized music seem to pose a problem for Opus. I've encountered a difficult sample for Opus 1.0.1 RC3: The beginning of the track "Flicker" by Big Giant Circles, which consists of two side-alternating NES-like synths.

Opus produces a distortion that is quite annoying up to VBR ~130 kbit/s and can be ABXed up to VBR ~200 kbit/s. The distortion is most noticeable in the first 5-6 seconds, after which an underlying pad sound begins to make distinction a little more difficult. I also did a test with VBR ~300 kbit/s but could not get conclusive ABX results.

I've uploaded the sample FLAC, the encoded Opus files and the ABX results for 130, 160 and 200 kbit/s VBR here (http://dl.dropbox.com/u/1100000/bgc_flicker_sample.zip) so you can have a look (and a listen) at it. I don't have access to my FTP from the office, so Dropbox will have to do.

Download Sample ZIP (http://dl.dropbox.com/u/1100000/bgc_flicker_sample.zip)

I figured I'd add a datapoint: I've seen the exact same behavior with all other audio codecs. Vorbis, MP3, and AAC definitely all jump enormously with such synthetic triangle and square waves, and I can ABX their sound at much higher bitrates than even otherwise difficult samples like classical music. For instance, using vorbis at q2, ~96kbps, I get 140-160kbps for some complex SID songs. SID conversions (along with NSF and other pure synth music) should be considered torture samples and treated as such, although if a way to model them shows up I'll be greatly appreciative and gladly reconvert my entire library of old-school favorites.
Title: IETF Opus codec now ready for testing
Post by: Silversight on 2012-09-15 08:53:30
For the sample I've tested, the other lossy encoders don't show the same behaviour. I did a quick comparison at ~64 kbit settings, and while LAME V9 goes up to an average of 80 kbit/s, the other encoders (Quicktime AAC, Nero AAC, aoTuV Vorbis, Opus 1.0.1RC3) all stay around 64 kbit/s. Plus, the two AAC encoders produce less noise than the two Opus encoders which use roundabout the double amount of bits.

Of course I know this is difficult terrain for lossy codecs, where distortion and noise can quite easily be found amidst the clean synth waves. Nevertheless, at this point this seems to be not only problematic in comparison to other kinds of sound, but also in comparison to other encoders.
Title: IETF Opus codec now ready for testing
Post by: NullC on 2012-09-17 02:35:33
I've tested the two exp encoders from #365 and got results similar to those of darkbyte's SID music: With both encoders, bitrates were way higher than with 1.0.1 RC3.
This is because you're testing on a sample that is hard for Opus. This is the reasonable and expected behavior. On large diverse collections the EXP should give ~the same average rates... but on single tracks it can crank the rate.

I'm not sure what "VBR 130 (exp)"  means because you have datapoints where 130 was delivered and where it was requested.  ABXable for 66kbit/sec collection average (requested) is expected, hopefully it just doesn't sound bad.  ABXable for 130 collection-rate (requested) would be worth a closer look.

For the sample I've tested, the other lossy encoders don't show the same behaviour. I did a quick comparison at ~64 kbit settings, and while LAME V9 goes up to an average of 80 kbit/s, the other encoders (Quicktime AAC, Nero AAC, aoTuV Vorbis, Opus 1.0.1RC3) all stay around 64 kbit/s. Plus, the two AAC encoders produce less noise than the two Opus encoders which use roundabout the double amount of bits.
Of course I know this is difficult terrain for lossy codecs, where distortion and noise can quite easily be found amidst the clean synth waves. Nevertheless, at this point this seems to be not only problematic in comparison to other kinds of sound, but also in comparison to other encoders.

Opus is not MP3, AAC, or Vorbis. It is a _very_ different format and has different difficulty areas owing to the short (low latency) low-overlap transforms and the enormous vector quantization. Tonal samples without simple harmonic structure are a known and expected challenge area. On the other hand it handles noisy and high transient samples fairly well.
Title: IETF Opus codec now ready for testing
Post by: Silversight on 2012-09-17 11:41:31
I'm not sure what "VBR 130 (exp)"  means because you have datapoints where 130 was delivered and where it was requested.  ABXable for 66kbit/sec collection average (requested) is expected, hopefully it just doesn't sound bad.  ABXable for 130 collection-rate (requested) would be worth a closer look.


Ah yes, that might have been confusing. I meant VBR with requested 130 where exp encoders delivered 239 and 233 respectively.

ABXable for 130 collection-rate (requested) would be worth a closer look.


My ears can't pull that off. With the majority of my music, distinction is difficult or impossible for me at ~80 kbit/s. Good job!
Title: IETF Opus codec now ready for testing
Post by: Dandruff on 2012-09-17 12:10:00
Anybody knows what Opus Encoder setting gives "same" result as Ogg Vorbis at q6.0?

192kbps VBR maybe?
Title: IETF Opus codec now ready for testing
Post by: maikmerten on 2012-09-17 12:36:11
Anybody knows what Opus Encoder setting gives "same" result as Ogg Vorbis at q6.0?


Given that these codecs differ a lot in what material is "difficult" for them and produce different artifacts, I would assume this is hard (impossible) to say, aside from transparent bitrates. However, I would also assume the jury is still out to determine what setting is transparent for Opus (and this will change as the encoder progresses).
Title: IETF Opus codec now ready for testing
Post by: skamp on 2012-09-17 12:36:19
Ogg Vorbis -q 6 is transparent to me, so I assume that you want to achieve transparency. Only an ABX session can tell you that. I ran a few myself, and I couldn't ABX Opus at 128 kbps.
Title: IETF Opus codec now ready for testing
Post by: Dandruff on 2012-09-17 12:47:41
Ok, thanks. I wan't to use it for my mobile music library.
Title: IETF Opus codec now ready for testing
Post by: LigH on 2012-09-17 12:53:25
I'd prefer to wait with this attempt. There are still experimental encoders being tested (remember aoTuV mods for Vorbis?), and there is no reliable expectation about consumer player support yet...
Title: IETF Opus codec now ready for testing
Post by: Dandruff on 2012-09-17 13:26:31
Ok, thanks! I've always used the original Ogg Vorbis Encoder ...
Title: IETF Opus codec now ready for testing
Post by: Silversight on 2012-09-20 14:30:32
I'm just wondering about the implications of this for people using OPUS as a music storage format (rather than streaming).

While I'm entirely happy to normalize all my music using Album Gain, I know there are people who are a bit 'precious' about preserving of being able to revert to the 'original loudness' of the tracks as if it were 'intended' by a mastering engineer with reference to a standard, which is barely ever the case, unlike with calibrated movie theatre audio.

There is another implication that I had first flagged as a foobar2000 bug before realizing it is a result of the gain tags in Opus.
Following the recommendations in the Ogg Mapping for Opus document (http://wiki.xiph.org/OggOpus), the following situations are indistinguishable for a decoder:
1. Track Gain = X; Album Gain = X
2. Track Gain = X; Album Gain is not set

Both situations result in an "output gain" value of X while R128_TRACK_GAIN is set to 0 or missing. At the moment, foobar2000 interprets it as "Track Gain = X; Album Gain = X". That means that for tracks that have been scanned for Track Gain only, it also reports an Album Gain value that is the same as the Track Gain value.

While that is no problem for playback, it wreaks havoc with my (and possibly other people's) playlist grouping scheme. Of course I don't know the format very well, but in my opinion the introduction of a field like "R128_ALBUM_GAIN" could have avoided that minor nuisance easily.
Title: IETF Opus codec now ready for testing
Post by: Dynamic on 2012-09-20 19:22:36
I guess a minor workaround would be to change the least significant digit of one of the gain figures by the smallest increment possible to make them different values in fb2k. It's a fudge, but it might be possible with no audible change. Another option might be to add a non-standard comment field to indicate that Album Gain Equals Track Gain = TRUE while not specifying an Album Gain figure as it's 'prohibited' (which is a nice way to force Opus players to support at least some form of volume normalization, so I can see why it's worthwhile).
Title: IETF Opus codec now ready for testing
Post by: saratoga on 2012-09-21 16:07:43
Current (dev) builds of rockbox now have preliminary support for Opus.  The current code has zero optimizations, so older devices probably won't be able to play it without skipping, but thats normal for new codecs before they get rewritten for ARM
Title: IETF Opus codec now ready for testing
Post by: lvqcl on 2012-09-21 19:35:37
how does Rockbox resample from Opus' 48kHz to its own 44.1?
Title: IETF Opus codec now ready for testing
Post by: IgorC on 2012-09-21 21:04:14
Current (dev) builds of rockbox now have preliminary support for Opus.  The current code has zero optimizations, so older devices probably won't be able to play it without skipping, but thats normal for new codecs before they get rewritten for ARM

Not sure whether there is much sense to keep  development for old devices.  DAPs start to see their end while the sales of smartphones grow.  Today the  vast majority of smartphones have powerful CPUs.

Have tried Opus on phone with Android  http://rasher.dk/rockbox/android/ (http://rasher.dk/rockbox/android/) . Works well and has plenty of battery life.
Probably the battery life isn't an issue anymore.  Anyway people should recharge it (almost) every day.

Title: IETF Opus codec now ready for testing
Post by: m45t3r on 2012-09-22 01:09:52
Current (dev) builds of rockbox now have preliminary support for Opus.  The current code has zero optimizations, so older devices probably won't be able to play it without skipping, but thats normal for new codecs before they get rewritten for ARM

Not sure whether there is much sense to keep  development for old devices.  DAPs start to see their end while the sales of smartphones grow.  Today the  vast majority of smartphones have powerful CPUs.

Have tried Opus on phone with Android  http://rasher.dk/rockbox/android/ (http://rasher.dk/rockbox/android/) . Works well and has plenty of battery life.
Probably the battery life isn't an issue anymore.  Anyway people should recharge it (almost) every day.


I did some tests with a earlier version of rockbox-opus (it should still be valid since there still no optimizations on code) on a Samsung Galaxy S II (http://www.hydrogenaudio.org/forums/index....st&p=805855 (http://www.hydrogenaudio.org/forums/index.php?showtopic=86580&view=findpost&p=805855), just for update I did compile using ARMv7 optimizations and NEON fpu, but didn't see any increase of performance, probably because Rockbox uses the integer version of Opus decoder) and it shows that optimizations would be really welcome. Opus on Rockbox simple use too many cycles even on a fast (1,2GHz) dual-core, ARMv7 processor, so while it's capable to decode even the highest bitrate sample with easy, it simple uses too many cycles and uses too much power (my CPU gets really hot when playing Opus files). My Sansa Clip+ was clearly using more power to play Opus files than Vorbis too.

Either way, Opus is designed for embedded devices in mind, so with properly optimizations maybe it will use less CPU to decode Opus than even MP3 on future.
Title: IETF Opus codec now ready for testing
Post by: m45t3r on 2012-09-22 02:41:06
Just started a page about Opus on Wiki: http://wiki.hydrogenaudio.org/index.php?title=Opus (http://wiki.hydrogenaudio.org/index.php?title=Opus)

It's still pretty rough but I will try to add more content as I learn how to edit MediaWiki.
Title: IETF Opus codec now ready for testing
Post by: sluggy on 2012-09-22 16:55:26
CDBurnerXP has just added opus support for burning audio cds, which is great news 
Title: IETF Opus codec now ready for testing
Post by: saratoga on 2012-09-22 23:20:04
how does Rockbox resample from Opus' 48kHz to its own 44.1?


Using the normal crappy linear resampler.  Integrating a better one is on my todo list.  Probably borrow the neat looking one from speex if i ever get around to it.
Title: IETF Opus codec now ready for testing
Post by: jensend on 2012-09-23 00:00:55
how does Rockbox resample from Opus' 48kHz to its own 44.1?
Left in the middle of writing this and when I'd come back Saratoga had beaten me to it- Rockbox's built-in resampler uses linear interpolation. While this does mean that it's fast and has practically zero impact on battery life, it definitely has an impact on sound quality. Could be worse (zero-order-hold), and the problems may not be audible in many portable listening settings (esp. since an Opus file will have no frequency content above 20kHz), but there are much better resamplers that aren't that much slower. (Take a look at what SRC Comparisons (http://src.infinitewave.ca/) has to say about the Xiph "Speex resampler," which is also used in opus-tools, versus a linear resampler.)

On most of the devices Rockbox supports, the hardware could natively play back sounds at all realistic/real-world rates. But the switching the hardware's output rate whenever a new sound played would be extremely onerous to code and support across all those devices. They chose to stick with the most common music rate and resample everything else to keep things simple.

(Rockbox devs seem short-staffed as it is, given all the different hardware they're trying to support. Their current release is being held up because they're encountering difficult-to-diagnose bugs with some devices' USB support, for instance.)

In IRC, one Rockbox dev (I forget who) mentioned that it would be fairly easy to build 48k-native versions of Rockbox if there were demand for them. For people who plan to go opus-only with their collection, this might be the best route.
Title: IETF Opus codec now ready for testing
Post by: lvqcl on 2012-09-23 01:06:08
Probably borrow the neat looking one from speex if i ever get around to it.
the Xiph "Speex resampler," which is also used in opus-tools

Yeah, I already noticed that opus-tools uses slightly modified (http://git.xiph.org/?p=opus-tools.git;a=history;f=src/resample.c) Speex resampling algorithm.

Take a look at what SRC Comparisons (http://src.infinitewave.ca/) has to say about the Xiph "Speex resampler,"

I can see only the results of Speex@Quality 10 there, but probably this setting is too CPU-intensive for portable devices... However, the Speex manual (http://www.speex.org/docs/manual/speex-manual/node7.html) states that even "quality 0 usually has a decent sound (certainly better than using linear interpolation resampling)". And this algorithm already has fixed-point version.
Title: IETF Opus codec now ready for testing
Post by: saratoga on 2012-09-23 01:49:25
I can see only the results of Speex@Quality 10 there, but probably this setting is too CPU-intensive for portable devices... However, the Speex manual (http://www.speex.org/docs/manual/speex-manual/node7.html) states that even "quality 0 usually has a decent sound (certainly better than using linear interpolation resampling)". And this algorithm already has fixed-point version.


Yeah I was thinking Q1 for most devices, and maybe Q4 for highend hardware.  That resampler looks a little painful, and there is no asm so gcc will likely make a mess of it.

I still wonder how that would compare to something like 2x oversampled cubic hermite though.  That can be done really efficiently, and should give pretty good results.
Title: IETF Opus codec now ready for testing
Post by: maikmerten on 2012-09-23 09:30:05
how does Rockbox resample from Opus' 48kHz to its own 44.1?


Not being familiar with Rockbox I would like like to ask: why would Rockbox not just output at 48 kHz (except for devices that do not support 48 kHz)?
Title: IETF Opus codec now ready for testing
Post by: Soap on 2012-09-23 12:43:50
Not being familiar with Rockbox I would like like to ask: why would Rockbox not just output at 48 kHz (except for devices that do not support 48 kHz)?


Because even during music playback Rockbox can make lots of other sounds (talking menus, key clicks, etc etc) and they would all need to be mixed and output at a common samplerate.
Title: IETF Opus codec now ready for testing
Post by: maikmerten on 2012-09-23 13:42:01
Not being familiar with Rockbox I would like like to ask: why would Rockbox not just output at 48 kHz (except for devices that do not support 48 kHz)?


Because even during music playback Rockbox can make lots of other sounds (talking menus, key clicks, etc etc) and they would all need to be mixed and output at a common samplerate.


Ah, thanks, this makes sense
Title: IETF Opus codec now ready for testing
Post by: C.R.Helmrich on 2012-09-23 13:58:38
I still wonder how that would compare to something like 2x oversampled cubic hermite though.  That can be done really efficiently, and should give pretty good results.

Is there an implementation of such a resampler in existence that you know of? Never heard/seen one and would like to learn how it works.

Chris
Title: IETF Opus codec now ready for testing
Post by: LordWarlock on 2012-09-23 16:07:22
I have bumped into this pdf (http://yehar.com/blog/wp-content/uploads/2009/08/deip.pdf), hermite doesn't look that efficient to me.
Title: IETF Opus codec now ready for testing
Post by: saratoga on 2012-09-23 19:26:36
I still wonder how that would compare to something like 2x oversampled cubic hermite though.  That can be done really efficiently, and should give pretty good results.

Is there an implementation of such a resampler in existence that you know of? Never heard/seen one and would like to learn how it works.


I prototyped it quickly in matlab a while ago for the 48k to 44.1k case: 

Code: [Select]
function out = over2x(in)

in2x=upsample(in,2);

f = [0 17/96 33/96 1]; a = [1 1 0 0 ];
b = firls(7,f,a);

upsampled=filter(b, [1; zeros(length(b),1)], in2x);

out = herm(upsampled, 2*48000/44100 );


Code: [Select]
function outbuf = herm(inptr, delta)

insamps=length(inptr);
pos=4;
phases=pos;
outsamps=0;
c=0;
while (pos < insamps)
    c=c+1;
    x3 = inptr(pos-3);
    x2 = inptr(pos-2);
    x1 = inptr(pos-1);

    x0 = inptr(pos);
    
    frac = phases -floor(phases);

    %/* 4-tap Hermite, using Farrow structure */
    acc0 = (3 * (x2 - x1) + x0 - x3) / 2;
    acc0 = (acc0 * frac);
    acc0 = acc0 + 2 * x1 + x3 - ((5 * x2 + x0) / 2);
    acc0 = (acc0 * frac);
    acc0 = acc0 + (x1 - x3) / 2;
    acc0 = (acc0 * frac);
    acc0 = acc0 + x2;

    phases = phases +delta;
    pos = floor(phases);
    
    
    outsamps = outsamps+1;  
    outbuf(outsamps) = acc0;
end


Its a little ugly, but its basically ported straight over from some c code I found online for the hermite polynomial.  Basically, my ideas was that you could FIR oversample by 2x which would both eliminate ultrasonic noise and reduce the error in the polynomial fit. Since hermite polynomials are simple, and on armv5e and higher you can do an FIR tap in 2.5 cycles (ignoring memory latency anyway), the overall computational load is pretty low.  I did some quick testing and it indeed worked pretty well, much better then linear or conventional hermite.  Then I found the speex code, and spent a while looking into it and haven't had time to come back to this.
Title: IETF Opus codec now ready for testing
Post by: IgorC on 2012-09-24 16:52:01
I did some tests with a earlier version of rockbox-opus (it should still be valid since there still no optimizations on code) on a Samsung Galaxy S II (http://www.hydrogenaudio.org/forums/index....st&p=805855 (http://www.hydrogenaudio.org/forums/index.php?showtopic=86580&view=findpost&p=805855), just for update I did compile using ARMv7 optimizations and NEON fpu, but didn't see any increase of performance, probably because Rockbox uses the integer version of Opus decoder) and it shows that optimizations would be really welcome. Opus on Rockbox simple use too many cycles even on a fast (1,2GHz) dual-core, ARMv7 processor, so while it's capable to decode even the highest bitrate sample with easy, it simple uses too many cycles and uses too much power (my CPU gets really hot when playing Opus files). My Sansa Clip+ was clearly using more power to play Opus files than Vorbis too.

Either way, Opus is designed for embedded devices in mind, so with properly optimizations maybe it will use less CPU to decode Opus than even MP3 on future.

While optimizations are clearly desired still Opus is perfectly usable on smartphones. Your report indicates that Opus 128 kbps consumes less than 5% of phone's CPU.
http://www.hydrogenaudio.org/forums/index....st&p=805855 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=86580&view=findpost&p=805855)

The battery of my Samsung Galaxy II has lasted 15 hours and 33 minutes for playback of Opus 128 kbps at my average volume on 10 albums.
2-3 hours of playback per day is enough and I recharge the battery almost every day because other functions consume considerably more. A display already consumes 50-70% of battery.

Title: IETF Opus codec now ready for testing
Post by: m45t3r on 2012-09-25 01:13:37
I did some tests with a earlier version of rockbox-opus (it should still be valid since there still no optimizations on code) on a Samsung Galaxy S II (http://www.hydrogenaudio.org/forums/index....st&p=805855 (http://www.hydrogenaudio.org/forums/index.php?showtopic=86580&view=findpost&p=805855), just for update I did compile using ARMv7 optimizations and NEON fpu, but didn't see any increase of performance, probably because Rockbox uses the integer version of Opus decoder) and it shows that optimizations would be really welcome. Opus on Rockbox simple use too many cycles even on a fast (1,2GHz) dual-core, ARMv7 processor, so while it's capable to decode even the highest bitrate sample with easy, it simple uses too many cycles and uses too much power (my CPU gets really hot when playing Opus files). My Sansa Clip+ was clearly using more power to play Opus files than Vorbis too.

Either way, Opus is designed for embedded devices in mind, so with properly optimizations maybe it will use less CPU to decode Opus than even MP3 on future.

While optimizations are clearly desired still Opus is perfectly usable on smartphones. Your report indicates that Opus 128 kbps consumes less than 5% of phone's CPU.
http://www.hydrogenaudio.org/forums/index....st&p=805855 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=86580&view=findpost&p=805855)

The battery of my Samsung Galaxy II has lasted 15 hours and 33 minutes for playback of Opus 128 kbps at my average volume on 10 albums.
2-3 hours of playback per day is enough and I recharge the battery almost every day because other functions consume considerably more. A display already consumes 50-70% of battery.

Maybe but just consider the low-end phones that are based on older architectures (like ARM11, there still lots of devices using it). If rockbox-opus uses 5% of CPU on a high-end phone, on a low-end smartphone it would means 10% or even 15% of CPU time. It is sufficient to put the CPU on a higher energy state that would drains lots of battery. Just saying "forget the less powerful devices" isn't really realist considering all the differents devices around.

Anyway, these tests are made with the phone fully awake. It didn't really represents the reality, where the phone would go to a lower energy state, but it shows how Opus is really unoptimized compared to another similar codecs (e.g. that uses MDCT like Vorbis, AAC or even MP3).
Title: IETF Opus codec now ready for testing
Post by: saratoga on 2012-09-25 01:59:05
Arguing about current Opus is pretty silly since just replacing the fixed point operations with their corresponding ARM instructions would massively increase performance.
Title: IETF Opus codec now ready for testing
Post by: brat-h on 2012-09-25 15:28:50
Well, could someone "optimize" window's build of opus-tools for processors without SSE-instructions support?
Title: IETF Opus codec now ready for testing
Post by: jensend on 2012-09-25 20:33:41
Well, could someone "optimize" window's build of opus-tools for processors without SSE-instructions support?
How many people are really Seems like an inconsistent triad to me.
Title: IETF Opus codec now ready for testing
Post by: brat-h on 2012-09-26 11:43:29
I didn't mean actually OPTIMIZATION, but a build of opus-tools which would work without SSE (as opus-tools-0.1.3 did for example)
Title: IETF Opus codec now ready for testing
Post by: saratoga on 2012-09-26 16:08:37
Arguing about current Opus is pretty silly since just replacing the fixed point operations with their corresponding ARM instructions would massively increase performance.


A few optimizations have gone in, bringing playback down to about 100MHz on a (slow) ARM7TDMI core.  More will probably follow.

I didn't mean actually OPTIMIZATION, but a build of opus-tools which would work without SSE (as opus-tools-0.1.3 did for example)


Probably a good idea to specify which CPU you actually have.  Non-sse CPUs are so ancient it may be somewhat difficult to find a suitable compiler. 
Title: IETF Opus codec now ready for testing
Post by: lvqcl on 2012-09-26 17:35:50
Duron Spitfire, Athlon Thunderbird? 12 years ago they were very good.
Also, a good idea to specify an OS. E.g. MSVC 2010 doesn't support Win2000 (let alone Win98/Me).
Title: IETF Opus codec now ready for testing
Post by: NullC on 2012-09-26 18:17:30
Probably a good idea to specify which CPU you actually have.  Non-sse CPUs are so ancient it may be somewhat difficult to find a suitable compiler.
What? no. There is no difficulty in this.  In fact, for x86 builds you have to go out of your way a build-time to enable SSE in Opus-tools.

I don't really think Ralph wants to build two separate windows binaries (or if he did they're probably be x86 vs x86_64, and the latter would have SSE as it's required there)... so I'll suggest that he just do the next 32bit windows builds without SSE.

Title: IETF Opus codec now ready for testing
Post by: lvqcl on 2012-09-26 19:03:48
AFAIK Opus internal resampler is noticeably faster with SSE enabled, and most of audio files are still 44.1kHz. I'm not sure that disabling SSE is a good thing.
Title: IETF Opus codec now ready for testing
Post by: Dukers on 2012-09-26 23:20:24
exp_analysis7 branch doesn't compile on MSVC. src\analysis.c, src\mlp.c, src\mlp_data.c, and src\mlp_train.c are missing from the solution file. And mlp_train.c depend on pthread. I know it's probably low priority, but anyway...
Title: IETF Opus codec now ready for testing
Post by: lvqcl on 2012-09-27 15:38:55
Last time I tried to compile opus mlp_train.c was unnecessary for en- and decoder.
Title: IETF Opus codec now ready for testing
Post by: The Sheep of DEATH on 2012-10-03 09:13:07
Decoding complexity is a huge consideration when (properly) implementing a decoder on a mobile device.

That said, I locked my Evo LTE at its lowest speed (single-threaded 384MHz powersave), where it still managed to play my 64kbps test files (with full Beats Audio doing goodness-knows-what in the background, using the "Java"/non-native mixer). This was with a NEON build of VLC for Android running at high priority.

Good news, I suppose, especially since I can't bring myself to imagine that alpha-quality VLC-Android codebase is in any way optimized for Opus playback (half the GUI options don't work and the app crashes playing videos, changing settings, etc).

I also hear the PowerAmp guys are working on getting Opus into their player, which is one of the most popular third-party players in Android land.
Title: IETF Opus codec now ready for testing
Post by: IgorC on 2012-10-03 15:12:38
You should get plenty of battery life as your EVO has 28 nm CPU. Mine is 45 nm and battery last 15 hours and 33 minutes on rockbox. http://rasher.dk/rockbox/android/ (http://rasher.dk/rockbox/android/)
http://www.hydrogenaudio.org/forums/index....st&p=809617 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=86580&view=findpost&p=809617)

Even more at 64 kbps.
Title: IETF Opus codec now ready for testing
Post by: The Sheep of DEATH on 2012-10-04 07:48:27
You should get plenty of battery life as your EVO has 28 nm CPU. Mine is 45 nm and battery last 15 hours and 33 minutes on rockbox. http://rasher.dk/rockbox/android/ (http://rasher.dk/rockbox/android/)
http://www.hydrogenaudio.org/forums/index....st&p=809617 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=86580&view=findpost&p=809617)

Even more at 64 kbps.


Thanks for the link to RockBox. Never tried it on here before, but I trust the maturity of the codebase (if not the interface) on mobile devices and ARM architecture more than VLC. It indeed plays the files with incredible ease, but the interface is non-existent (downloaded the 720x1280 but still, no controls visible and I had to guess where to tap -- eventually ended up playing, which is great). Comparison might not be as "fair" with VLC because RockBox doesn't work with Beats or Direct Volume Control like VLC seemed to. Also, VLC supports native ICS lockscreen and such, so right now it is probably the better player on the interface/app level.

I wonder what resampler (48KHz > 44.1KHz) VLC uses (linear for RockBox I believe). Either way, very promising news indeed!
Title: IETF Opus codec now ready for testing
Post by: Serge Smirnoff on 2012-10-11 21:53:55
I wonder what is the correct (recommended) way to decode .opus files with 24 or 32 bit-depth accuracy. OpusDec outputs 16bit only with or without dithering. Foobar can convert .opus files to 24bit wavs but it is still unclear whether they are true 24bit outputs of the decoder or derived from 16bit outputs in some way.
Title: IETF Opus codec now ready for testing
Post by: saratoga on 2012-10-12 02:12:56
I wonder what is the correct (recommended) way to decode .opus files with 24 or 32 bit-depth accuracy. OpusDec outputs 16bit only with or without dithering. Foobar can convert .opus files to 24bit wavs but it is still unclear whether they are true 24bit outputs of the decoder or derived from 16bit outputs in some way.


You could probably just modify it to dump the raw floats then convert them to whatever precision you wanted.
Title: IETF Opus codec now ready for testing
Post by: Dynamic on 2012-10-12 11:01:12
I wonder what is the correct (recommended) way to decode .opus files with 24 or 32 bit-depth accuracy. OpusDec outputs 16bit only with or without dithering. Foobar can convert .opus files to 24bit wavs but it is still unclear whether they are true 24bit outputs of the decoder or derived from 16bit outputs in some way.


Opusdec definitely tries to return the original bit depth and sampling rate and duration so as not to surprise the user. Internally, it works with floating point (unless compiled for fixed point). Doesn't it return 24-bit if the encoder's input was 24-bit. I could see it using only 16-bit as 24-bit is pointless for a lossy encoder, and really for anything in a final consumer delivery format, as Monty's blog post at xiph.org explains in detail.

fb2k is geared to playback and uses floating point processing architecture, so doesn't as yet pass these original parameters to the Converter to allow automatic resampling and dithering to the original bit depth and sampling rate when decoding Opus.

I'd be astounded if fb2k decoded Opus then converted to 16-bit anywhere before the end of the entire processing chain. That's just not the fb2k design philosophy! Simple to check though if you turn off dither in the Converter dialogue and choose your bit depth or output floats. You could even edit the OpusGain field in the Opus stream with a hex editor to turn it down by 100 dB, decode to 24-bit/32-bit Float in fb2k then apply 100 dB of gain to confirm it's not throwing it away.
Title: IETF Opus codec now ready for testing
Post by: Serge Smirnoff on 2012-10-12 11:47:37
Opusdec definitely tries to return the original bit depth and sampling rate and duration so as not to surprise the user. Internally, it works with floating point (unless compiled for fixed point). Doesn't it return 24-bit if the encoder's input was 24-bit. I could see it using only 16-bit as 24-bit is pointless for a lossy encoder, and really for anything in a final consumer delivery format, as Monty's blog post at xiph.org explains in detail.

For 48/24 input OpusDec returns 48/16. I foresee that 24bit input and output will be the most popular usage scenario for Opus because in most cases there is a need to resample input and output for the codec.

I'd be astounded if fb2k decoded Opus then converted to 16-bit anywhere before the end of the entire processing chain. That's just not the fb2k design philosophy! Simple to check though if you turn off dither in the Converter dialogue and choose your bit depth or output floats. You could even edit the OpusGain field in the Opus stream with a hex editor to turn it down by 100 dB, decode to 24-bit/32-bit Float in fb2k then apply 100 dB of gain to confirm it's not throwing it away.

After your's and Peter's (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=97011&view=findpost&p=811231) replies I'm pretty sure that Foobar can decode .opus with true 24bit accuracy. Your test suggestion is clever, not tried it yet though.
Title: IETF Opus codec now ready for testing
Post by: Gainless on 2012-10-12 16:17:46
This one here might be a useful test sample for NullC as it's highly tonal and easy to ABX at high bitrates:

Albibeno Sample (http://www.mediafire.com/download.php?9vk5gx2fz5zcy2o)

The included ABX log is from a test with a 192 kbps file, encoded with the recent Opus tools.
Title: IETF Opus codec now ready for testing
Post by: Dynamic on 2012-10-12 17:09:42
For 48/24 input OpusDec returns 48/16. I foresee that 24bit input and output will be the most popular usage scenario for Opus because in most cases there is a need to resample input and output for the codec.


Hmm, for playback, I'd imagine you'd just decode to whatver your hardware supports, so that could well be 24-bit/48 kHz on most devices with no resampling (unless you have native 44.1kHz DSP like Rockbox). Many operating systems like Windows have native 48 kHz mixers unless you bypass to special modes so it's utterly pointless to go 48 -> 44.1 -> 48.

I'd imagine decoding to a PCM file is fairly rare use case compared to playback to the soundcard, and opusdec would in any case decode AND resample in floating point before switching to fixed-point PCM. The imperfections allowed by lossy encoding are usually far above 16-bit quantization noise.
You might then indirectly resample that PCM (with calculations carried out at 24 or 32-bit) if, for some reason, you chose to play it over your soundcard via e.g. Windows Mixer at 48kHz.

Any added noise is broad-spectrum, and only adds up to -90 to -95 dB over the entire bandwidth. The ear is more of a spectrum analyzer than an oscilloscope. Over the ear's typical discriminating bandwidth it is probably about 110-120 dB below a full-scale sinusoid at the same frequency and even with music mastered with 20 dB of headroom, that's over 90 dB per band. Considering a very quiet room is about 30 dB SPL, pretty loud music is 90 dB SPL and pain is about 120 dB SPL, that's plenty unless you start turning up the volume hugely during fade-outs.

Sure it's always good practice to process and edit at 24 bits or better to prevent significant accumulation of noise over many many multiple editing processes and echo and reverb, but for regular listening even with pretty heavy dynamic range compression, it should be overkill by quite a big margin.
Title: IETF Opus codec now ready for testing
Post by: NullC on 2012-10-13 03:23:00
Hmm, for playback, I'd imagine you'd just decode to whatver your hardware supports, so that could well be 24-bit/48 kHz on most devices with no resampling (unless you have native 44.1kHz DSP like Rockbox). Many operating systems like Windows have native 48 kHz mixers unless you bypass to special modes so it's utterly pointless to go 48 -> 44.1 -> 48.

I'd imagine decoding to a PCM file is fairly rare use case compared to playback to the soundcard, and opusdec would in any case decode AND resample in floating point before switching to fixed-point PCM. The imperfections allowed by lossy encoding are usually far above 16-bit quantization noise.
You might then indirectly resample that PCM (with calculations carried out at 24 or 32-bit) if, for some reason, you chose to play it over your soundcard via e.g. Windows Mixer at 48kHz.
Right, our recommendation is to only preserve the original rate for file output; for playback you playback at 48kHz preferably, whatever you can do otherwise (with resampling).

Opusdec does this.  And for the float->16 bit conversion it uses a proper noise shaping triangular dither with a conservative shaping filter that limits the HF noise boost.  Why bother? Why not. You can construct crazy cases where the intermod from straight truncated quantization is audible... and I don't know how loud the signal will be played back. It probably doesn't matter, but on desktops CPU time is free relative to how much work it takes.  (plus you can turn it off)

I'll gladly take a patch to add float output, I just couldn't be bothered to figure out the required wav magic, though the reader code for opusenc handles it.
Title: IETF Opus codec now ready for testing
Post by: jmvalin on 2012-10-13 04:18:34
This one here might be a useful test sample for NullC as it's highly tonal and easy to ABX at high bitrates:

The included ABX log is from a test with a 192 kbps file, encoded with the recent Opus tools.


I just checked and the latest code in master (just merged from exp_analysis branch) actually detects this as highly tonal and increase the bit-rate way up. This should be enough to fix the problem (please try it and let me know).
Title: IETF Opus codec now ready for testing
Post by: Serge Smirnoff on 2012-10-13 09:39:18
For 48/24 input OpusDec returns 48/16. I foresee that 24bit input and output will be the most popular usage scenario for Opus because in most cases there is a need to resample input and output for the codec.


Hmm, for playback, I'd imagine you'd just decode to whatver your hardware supports, so that could well be 24-bit/48 kHz on most devices with no resampling (unless you have native 44.1kHz DSP like Rockbox). Many operating systems like Windows have native 48 kHz mixers unless you bypass to special modes so it's utterly pointless to go 48 -> 44.1 -> 48. ....................
Sure it's always good practice to process and edit at 24 bits or better to prevent significant accumulation of noise over many many multiple editing processes and echo and reverb, but for regular listening even with pretty heavy dynamic range compression, it should be overkill by quite a big margin.


24bit output is important not only because of resampling of course; consuming of audio becomes more and more sophisticated on listener's side today - at least using of some DSP is presupposed, not to say about mixing with other audio and frequent necessity to transcode to lower bitrates. From this perspective the use of 16bit audio and corresponding bit reduction techniques look supplementary while 24bit audio chain on consumer side looks quite natural and even more simple.
Title: IETF Opus codec now ready for testing
Post by: Gainless on 2012-10-14 11:48:59
This one here might be a useful test sample for NullC as it's highly tonal and easy to ABX at high bitrates:

The included ABX log is from a test with a 192 kbps file, encoded with the recent Opus tools.


I just checked and the latest code in master (just merged from exp_analysis branch) actually detects this as highly tonal and increase the bit-rate way up. This should be enough to fix the problem (please try it and let me know).


Sorry, I don't really get what you mean (English is not my native language). Is there already a newer "official" encoder version than the one from the 0.1.5 Opus tools or do you just talk about the last exp_analysis branch?
Title: IETF Opus codec now ready for testing
Post by: nu774 on 2012-10-14 12:03:29
Sorry, I don't really get what you mean (English is not my native language). Is there already a newer "official" encoder version than the one from the 0.1.5 Opus tools or do you just talk about the last exp_analysis branch?

My English is even worse, but he's saying that PSY tuning developed under exp_analysis7 branch was merged into main branch recently, therefore soon it will become "official".
(This merge was committed at Oct 9, so current official win32 binary (0.15) doesn't include this).
Code: [Select]
commit 7315b35e13a3a7c504ed6b1fe2d28ad500eb2701
Merge: ca82894 317ffc2
Author: Jean-Marc Valin <jmvalin@jmvalin.ca>
Date:   Tue Oct 9 03:07:06 2012 -0400

    Merge branch 'exp_analysis7'

    Conflicts:
        celt/celt.c
        celt/mdct.c
        include/opus_defines.h
        src/opus_encoder.c
Title: IETF Opus codec now ready for testing
Post by: Gainless on 2012-10-14 12:19:45
Sorry, I don't really get what you mean (English is not my native language). Is there already a newer "official" encoder version than the one from the 0.1.5 Opus tools or do you just talk about the last exp_analysis branch?

My English is even worse, but he's saying that PSY tuning developed under exp_analysis7 branch was merged into main branch recently, therefore soon it will become "official".
(This merge was committed at Oct 9, so current official win32 binary (0.15) doesn't include this).
Code: [Select]
commit 7315b35e13a3a7c504ed6b1fe2d28ad500eb2701
Merge: ca82894 317ffc2
Author: Jean-Marc Valin <jmvalin@jmvalin.ca>
Date:   Tue Oct 9 03:07:06 2012 -0400

    Merge branch 'exp_analysis7'

    Conflicts:
        celt/celt.c
        celt/mdct.c
        include/opus_defines.h
        src/opus_encoder.c



Thanks for the explanation, I guessed it somehow but wasn't sure. Would be nice to have a compiled exe of this btw. Can someone upload it?
Title: IETF Opus codec now ready for testing
Post by: brat-h on 2012-10-22 01:54:29
Quote
Would be nice to have a compiled exe of this btw. Can someone upload it?


Here is the Cygwin-build for win32 of the latest source code of opus-tools with the latest opus-codec as for now.

http://rghost.ru/41081608 (http://rghost.ru/41081608)
Title: IETF Opus codec now ready for testing
Post by: Gainless on 2012-10-22 15:14:52
Quote
Would be nice to have a compiled exe of this btw. Can someone upload it?

Here is the Cygwin-build for win32 of the latest source code of opus-tools with the latest opus-codec as for now.

http://rghost.ru/41081608 (http://rghost.ru/41081608)
Thank you very much!
I've tested the sample once again with the new version and could still ABX it at 192 kbps.

Code: [Select]
foo_abx 1.3.4 report
foobar2000 v1.1.14
2012/10/22 15:19:40

File A: C:\Dokumente und Einstellungen\Master O\Desktop\Albibeno (Sample).flac
File B: C:\Dokumente und Einstellungen\Master O\Desktop\Albibeno (Sample).opus

15:19:40 : Test started.
15:19:55 : 01/01  50.0%
15:20:49 : 02/02  25.0%
15:21:13 : 03/03  12.5%
15:21:34 : 04/04  6.3%
15:39:18 : 05/05  3.1%
15:39:38 : 06/06  1.6%
15:39:51 : 06/07  6.3%
15:41:11 : 07/08  3.5%
15:41:32 : 08/09  2.0%
15:42:38 : 08/10  5.5%
15:42:54 : 09/11  3.3%
15:43:21 : 10/12  1.9%
15:43:49 : 11/13  1.1%
15:45:11 : 12/14  0.6%
15:45:23 : Test finished.

 ----------
Total: 12/14 (0.6%)

I'm not sure if the result is of any worth though, as I used the Direct Sound output of Windows XP, which is known for its terrible resampler. The artifact I noticed is a slight distortion on the echo of the first two notes (right channel), which makes this sound a bit sharper. Maybe someone can verifiy it?
Title: IETF Opus codec now ready for testing
Post by: IgorC on 2012-10-22 15:58:52
You can try to set a native (the same as .opus file) sample rate to avoid possible resampling-related issues and/or resample the output with SoX with very high quality VHQ (which is transparent  ).

I would try to resample (44.1 kHz -> 48kHz) the original before encode to Opus with SoX VHQ resampler, just to see if it's not built-in Opus'es resampler.
Title: IETF Opus codec now ready for testing
Post by: foxyshadis on 2012-10-23 09:44:31
Quote
Would be nice to have a compiled exe of this btw. Can someone upload it?


Here is the Cygwin-build for win32 of the latest source code of opus-tools with the latest opus-codec as for now.

http://rghost.ru/41081608 (http://rghost.ru/41081608)

After almost pulling my hair out wondering why encodes with the exp7-merged branch were coming out bit-identical, I finally realized that the only changes were for CELT frames. Mine, at 96 kbps, are never getting anywhere near that low, so they're never hitting the analysis at all. At 192, I would expect the decodes to be bit-identical; you might want to test that before spending too much time abxing. The other changes since have just been minor bugfixes.
Title: IETF Opus codec now ready for testing
Post by: LithosZA on 2012-10-23 10:53:56
Quote
Here is the Cygwin-build for win32 of the latest source code of opus-tools with the latest opus-codec as for now.

http://rghost.ru/41081608 (http://rghost.ru/41081608)

Thanks for posting that. I saw there was a 'cygopus-0.dll' in the archive.

I quickly created a C# project to see if I can call any methods:

Code: [Select]
[DllImport("cygopus-0.dll", CallingConvention = CallingConvention.Cdecl, CharSet = CharSet.Ansi)]
public static extern string opus_get_version_string();


Once I called 'opus_get_version_string()' I received 'libopus 1.0.1'. Yay!

I think it would be nice if the next 'opus tools' release includes win32 dlls like this one. (Or a seperate download for the libopus dll)
Title: IETF Opus codec now ready for testing
Post by: Gainless on 2012-10-23 13:05:55
Quote
Would be nice to have a compiled exe of this btw. Can someone upload it?


Here is the Cygwin-build for win32 of the latest source code of opus-tools with the latest opus-codec as for now.

http://rghost.ru/41081608 (http://rghost.ru/41081608)

After almost pulling my hair out wondering why encodes with the exp7-merged branch were coming out bit-identical, I finally realized that the only changes were for CELT frames. Mine, at 96 kbps, are never getting anywhere near that low, so they're never hitting the analysis at all. At 192, I would expect the decodes to be bit-identical; you might want to test that before spending too much time abxing. The other changes since have just been minor bugfixes.

Sorry, but you lost me with the "CELT frames" and "hitting the analysis" part, can you explain that a bit further? I've compared the new master with the recent exp versions yet btw, and they differ at the bitrates and RG peaks, so I guess there happened more than just minor bugfixing at the updates.
Title: IETF Opus codec now ready for testing
Post by: jmvalin on 2012-10-23 13:58:59
After almost pulling my hair out wondering why encodes with the exp7-merged branch were coming out bit-identical, I finally realized that the only changes were for CELT frames. Mine, at 96 kbps, are never getting anywhere near that low, so they're never hitting the analysis at all. At 192, I would expect the decodes to be bit-identical; you might want to test that before spending too much time abxing. The other changes since have just been minor bugfixes.


Actually, the changes in exp_analysis7 (which are now in master) do affect 96 kb/s. If you're seeing bit-identical output, you're doing something wrong.
Title: IETF Opus codec now ready for testing
Post by: foxyshadis on 2012-10-23 19:02:17
After almost pulling my hair out wondering why encodes with the exp7-merged branch were coming out bit-identical, I finally realized that the only changes were for CELT frames. Mine, at 96 kbps, are never getting anywhere near that low, so they're never hitting the analysis at all. At 192, I would expect the decodes to be bit-identical; you might want to test that before spending too much time abxing. The other changes since have just been minor bugfixes.


Actually, the changes in exp_analysis7 (which are now in master) do affect 96 kb/s. If you're seeing bit-identical output, you're doing something wrong.

Not sure which, but I swear I ran the exact same conversions this morning as yesterday, and today the exp branch is hugely different on the same songs. (120kbps vs 97kbps on one track, 65 vs 94 on another.) Yesterday, only the library name and frame headers were different at all. I built it myself a few times and didn't change anything but the bitrates in FB's converter, even checked the process command lines in process explorer; but whatever, it is obviously doing something now.
Title: IETF Opus codec now ready for testing
Post by: The Sheep of DEATH on 2012-11-01 05:29:20
Poweramp gained OPUS support! Posted two days ago, "Opus is successfully added to current Poweramp dev builds, including opus in .opus and .ogg files, full gapless and replay gain support."

To commemorate the occasion, here is a CVS-master compile of opus-tools (use opusenc to encode), including dlls for libopus and libogg (1.3.0).

This is today's Opus as well as today's opus-tools, featuring the new experimental tweaks (the now-merged exp_analysis7 branch). It's also 3 times as fast as brat-h's cygwin compile above on my system (requires SSE).
Title: IETF Opus codec now ready for testing
Post by: Seren on 2012-11-01 16:33:43
Poweramp gained OPUS support! Posted two days ago, "Opus is successfully added to current Poweramp dev builds, including opus in .opus and .ogg files, full gapless and replay gain support."

To commemorate the occasion, here is a CVS-master compile of opus-tools (use opusenc to encode), including dlls for libopus and libogg (1.3.0).

This is today's Opus as well as today's opus-tools, featuring the new experimental tweaks (the now-merged exp_analysis7 branch). It's also 3 times as fast as brat-h's cygwin compile above on my system (requires SSE).


Thx The Sheep of DEATH, it also encodes much faster than the official release (45x vs 30x for me).
Though I'm having a hard time deciding which is better quality... The bitrate varies quite a lot but I managed to compare a few at the same bitrate (can't disclose what I thought sounded better since my I don't have the time or patience to do a proper ABX).
Title: IETF Opus codec now ready for testing
Post by: The Sheep of DEATH on 2012-11-03 18:42:04
Thx The Sheep of DEATH, it also encodes much faster than the official release (45x vs 30x for me).
Though I'm having a hard time deciding which is better quality... The bitrate varies quite a lot but I managed to compare a few at the same bitrate (can't disclose what I thought sounded better since my I don't have the time or patience to do a proper ABX).


Glad to hear it! Besides much more drastic bitrate fluctuations, a definitive improvement in ringing is noticeable on one of my samples at (specified) 68kbps. The old version produced a file at 62kbps (with ringing on the vocals), while the new version produced a file that was over 74kbps (with ringing much reduced on the vocals). The instrumental version (w/o vocals) of the same song came out to be nearly identical in bitrate (62 old, 63 new).

Interesting.
Title: IETF Opus codec now ready for testing
Post by: Seren on 2012-11-03 21:31:15
Glad to hear it! Besides much more drastic bitrate fluctuations, a definitive improvement in ringing is noticeable on one of my samples at (specified) 68kbps. The old version produced a file at 62kbps (with ringing on the vocals), while the new version produced a file that was over 74kbps (with ringing much reduced on the vocals). The instrumental version (w/o vocals) of the same song came out to be nearly identical in bitrate (62 old, 63 new).
Interesting.


For now I've been using your compile as it's a lot faster and can't tell the diff but set it to 104 bitrate since the default 96 produces bitrates a tad too low for my liking. I will try test for the ringing later on though.

And a totally unrelated question: How come opus encodes don't show the length in windows explorer (win7) but ogg do?
Also not getting title and artist to show up but not expecting them too since ogg don't either.
Title: IETF Opus codec now ready for testing
Post by: punkrockdude on 2012-11-03 21:47:14
I compared a an Opus encode (124kbps) vs an Vorbis encode (122kbps) and they sound very similar. What I noticed is that the ogg had a narrower stereo image but the Opus had more smearing. Both are ABXable but the Opus encode was more difficult to distinguish.

Code: [Select]
foo_abx 1.3.4 report
foobar2000 v1.1.14a
2012/11/03 22:38:23

File A: Z:\media\data\musik\temp\01-The_Decline.flac
File B: Z:\home\ickefes\Documents\01-The_Decline.flac.ogg

22:38:23 : Test started.
22:39:27 : 00/01  100.0%
22:39:28 : Trial reset.
22:40:16 : 01/01  50.0%
22:40:25 : 02/02  25.0%
22:40:40 : 03/03  12.5%
22:40:52 : 04/04  6.3%
22:41:10 : 05/05  3.1%
22:41:33 : 06/06  1.6%
22:42:03 : 07/07  0.8%
22:42:05 : Test finished.

----------
Total: 7/8 (3.5%)


Code: [Select]
foo_abx 1.3.4 report
foobar2000 v1.1.14a
2012/11/03 22:22:45

File A: Z:\media\data\musik\temp\01-The_Decline.flac
File B: Z:\home\ickefes\Documents\The Decline.opus

22:22:45 : Test started.
22:24:26 : 00/01  100.0%
22:25:32 : Trial reset.
22:26:32 : 01/01  50.0%
22:26:48 : 02/02  25.0%
22:27:35 : 03/03  12.5%
22:27:47 : 03/04  31.3%
22:28:19 : 04/05  18.8%
22:28:36 : 05/06  10.9%
22:29:27 : 06/07  6.3%
22:30:16 : 06/08  14.5%
22:31:17 : 07/09  9.0%
22:31:52 : 08/10  5.5%
22:32:08 : 09/11  3.3%
22:32:51 : 10/12  1.9%
22:33:50 : 10/13  4.6%
22:34:20 : 11/14  2.9%
22:34:40 : 12/15  1.8%
22:35:12 : 13/16  1.1%
22:35:51 : 13/17  2.5%
22:36:50 : 14/18  1.5%
22:37:22 : 15/19  1.0%
22:37:27 : Test finished.

----------
Total: 15/20 (2.1%)
Title: IETF Opus codec now ready for testing
Post by: lvqcl on 2012-11-03 22:48:48
but the Opus had more smearing.

BTW, from the Opus git (http://git.xiph.org/?p=opus.git;a=commit;h...33c10b5cec11649 (http://git.xiph.org/?p=opus.git;a=commit;h=fac68ce189a768b4f18bba88d33c10b5cec11649)), Fri, 2 Nov 2012:

Quote
New transient detection algorithm
This one is explicitly based on a simple temporal masking model
Title: IETF Opus codec now ready for testing
Post by: Gainless on 2012-11-03 22:59:19
but the Opus had more smearing.

BTW, from the Opus git (http://git.xiph.org/?p=opus.git;a=commit;h...33c10b5cec11649 (http://git.xiph.org/?p=opus.git;a=commit;h=fac68ce189a768b4f18bba88d33c10b5cec11649)), Fri, 2 Nov 2012:

Quote
New transient detection algorithm
This one is explicitly based on a simple temporal masking model


Now we just need something we can encode with from this.
Title: IETF Opus codec now ready for testing
Post by: punkrockdude on 2012-11-03 23:07:03
but the Opus had more smearing.

BTW, from the Opus git (http://git.xiph.org/?p=opus.git;a=commit;h...33c10b5cec11649 (http://git.xiph.org/?p=opus.git;a=commit;h=fac68ce189a768b4f18bba88d33c10b5cec11649)), Fri, 2 Nov 2012:

Quote
New transient detection algorithm
This one is explicitly based on a simple temporal masking model

Thanks for the tip. I will try that one but do you know which command line to use to compile under Linux? Regards.
Title: IETF Opus codec now ready for testing
Post by: lvqcl on 2012-11-03 23:31:30
I will try that one but do you know which command line to use to compile under Linux? Regards.

I don't use Linux, but it's probably something like this:
Code: [Select]
% ./autogen.sh
% ./configure
% make
% sudo make install


Now we just need something we can encode with from this.

here it is: [attachment=7169:opus_20121103.zip]
Title: IETF Opus codec now ready for testing
Post by: punkrockdude on 2012-11-04 00:17:29
I am tired now but from what I have listened to this will be a very hard ABX with that Nov 3rd version. I am starting to get really impressed by Opus. Maybe soon it can become a "true 128or". I really look forward to all improvement that will happen during the following years.

Title: IETF Opus codec now ready for testing
Post by: Gainless on 2012-11-04 01:55:48
Thanks to lvqcl for the new exe!

Just followed Igor's suggestion and tested the (resampled) Albibeno sample again with the new version, it's not ABXable for me anymore at 192 kbps. There are two other sampes though, which are pretty easy to ABX due to distortion on the kicks, even at that high bitrates.

Opus Test samples (http://www.mediafire.com/download.php?r9wt1g24d7cx9lu)

At the DnB Beat sample the distorted kick comes right after the third snare hit, ABX logs are included.
Title: IETF Opus codec now ready for testing
Post by: The Sheep of DEATH on 2012-11-06 01:13:07
Here's my bi-weekly Win32 compile of opus-tools and libopus.

This goes up to HEAD as of the time of posting (4ea3ae9a opus; 97a5c5fa opus-tools) and requires SSE (your CPU must be less than 15 years old to run these).

Changelog since my previous build:
Code: [Select]
opus:
Further cleanup of the MDCT code, fixes PLC bug
Avoid copying imdct output
Various fixes to draft-terriberry-oggopus.xml
Valincomb_filter() bypass for the case where the gain is...
Oops, put back the "static" for transient_analysis()
Fixes a fixed-point overflow in the new transient detector
Fixes a fixed-point divide-by-zero issue
New transient detection algorithm

opus-tools:
opusrtp now compiles properly for windows (but remains useless)


These binaries should be super fast (the rtp binary is useless on windows, however). Let me know.
Title: IETF Opus codec now ready for testing
Post by: punkrockdude on 2012-11-06 10:14:31
That AVX build encoded a single file around 45x speed using 128kbps VBR default in Foobar2000 under Window 7 x64 on a ASUS K53SV-SX812V (2.4GHZ).
Title: IETF Opus codec now ready for testing
Post by: The Sheep of DEATH on 2012-11-06 16:04:30
That AVX build encoded a single file around 45x speed using 128kbps VBR default in Foobar2000 under Window 7 x64 on a ASUS K53SV-SX812V (2.4GHZ).


Good news, I guess! That build wasn't for AVX -- it was generic w/SSE. I was contemplating producing an AVX build but then decided against it for now. Long live genericism!

As for the build speed, I guess the question is how it stacks up against the "official" release on a range of processors. Thanks for testing!
Title: IETF Opus codec now ready for testing
Post by: IgorC on 2012-11-06 18:16:07
BTW how big is speed gain for AVX build?
Title: IETF Opus codec now ready for testing
Post by: Seren on 2012-11-06 18:56:02
That AVX build encoded a single file around 45x speed using 128kbps VBR default in Foobar2000 under Window 7 x64 on a ASUS K53SV-SX812V (2.4GHZ).


Good news, I guess! That build wasn't for AVX -- it was generic w/SSE. I was contemplating producing an AVX build but then decided against it for now. Long live genericism!

As for the build speed, I guess the question is how it stacks up against the "official" release on a range of processors. Thanks for testing!


Weird it doesn't seem to be as fast as your last build... I've got a lot of stuff open atm and getting 37x on this 1 and 39x on the last. Probably due to opus code changes.
Oh and btw, do you mean SSE1 or SSE2? I know there's a lot of difference between those two but practically none between 2 and 4a (not sure about 4.1 and 4.2). My ancient AMD Athlon x2 245 doesn't support AVX but it would be interesting to see the difference none-the-less.
Thanks for the build btw =)
Title: IETF Opus codec now ready for testing
Post by: Krillo on 2012-11-06 20:48:51
Hi all,

First post here at Hydrogen Audio Forums
I've been reading the manpages for opusenc, but don't understand how to create multichannel opusfiles. I have 8 wavs that I would like, as a test convert to an 8 channel opus. Can this be done, or have I misunderstood?

thanks
Title: IETF Opus codec now ready for testing
Post by: jensend on 2012-11-06 21:12:49
I've been reading the manpages for opusenc, but don't understand how to create multichannel opusfiles.
No special method is required; wav files contain sufficient information about the channels for opusenc to just go ahead and encode it like any other file.

(If you're noticing the things in the manpage about multichannel, those are there so people who are encoding from raw audio can supply the channel information themselves.)
Title: IETF Opus codec now ready for testing
Post by: The Sheep of DEATH on 2012-11-07 06:21:01
BTW how big is speed gain for AVX build?


About 5-10% (which is actually unexpectedly large). Some benchmarks have been done (ex. Phoronix), but only on specific benchmarks. Obviously, floating point arithmetic sees the largest benefit, but compilers (icc, gcc) can optimize code significantly using these new instructions for all sorts of low-level optimizations.

Here's an SSE build with AVX "soft tuning" and other tweaks (plus sync to recent head). This only yields a maximum of 7% performance increase on my AVX machine since last build posted. I've measured a healthy speedup on non-AVX Intel Nehalem, and even Phenom II (AMD). But since it only requires SSE (the first) it should work perfectly down to 1999's Pentium 3 (or 2001's Athlon XP).

Some fat trimming occurs as a side effect. Latest HEAD as of this post (tiny stack tweaks, mostly to decoder).
Title: IETF Opus codec now ready for testing
Post by: no404error on 2012-11-07 09:35:33
Intel i7-3770 / AsRock B75 Pro3 / 16Gb DDRIII-1333 / Windows 7 Home Premium

opusenc --bitrate 24 --vbr --comp 10 --downmix-mono --framesize 40  test.wav test.opus

1. opus-tools-0.1.5-win32> 52.07x
2. opus_tools_11_7_2012> 45.78x
3. opus_tools_11_1_2012> 45.01x
4. opus_20121103\Release64> 44.26x
5. opus_20121103\Release32> 40.85x
6. opus-tools-0.1.5-Cygwin5_sl2_121022_04-25> 35.89x
Title: IETF Opus codec now ready for testing
Post by: The Sheep of DEATH on 2012-11-07 10:32:49
Intel i7-3770 / AsRock B75 Pro3 / 16Gb DDRIII-1333 / Windows 7 Home Premium

opusenc --bitrate 24 --vbr --comp 10 --downmix-mono --framesize 40  test.wav test.opus

1. opus-tools-0.1.5-win32> 52.07x
2. opus_tools_11_7_2012> 45.78x
3. opus_tools_11_1_2012> 45.01x
4. opus_20121103\Release64> 44.26x
5. opus_20121103\Release32> 40.85x
6. opus-tools-0.1.5-Cygwin5_sl2_121022_04-25> 35.89x


Cool, looks good! I wonder if the newer analysis7 branch and whatnot slowed down the code a little. Otherwise, I'm curious as to what xiph used to compile (ICC perhaps?).

Also, are the results similar for you when you tweak the commandline? For instance,
opusenc --bitrate 68 --vbr --comp 10 --framesize 60  test.wav test.opus

I certainly didn't test some of this (mono, bitrates less than 32 or 48, etc). Maybe different behavior is invoked. I suspect it will be similar, but it doesn't hurt to have some verification.
Title: IETF Opus codec now ready for testing
Post by: no404error on 2012-11-07 10:44:24
Intel i7-3770 / AsRock B75 Pro3 / 16Gb DDRIII-1333 / Windows 7 Home Premium

opusenc --bitrate 68 --vbr --comp 10 --framesize 60 test.wav test.opus

1. opus-tools-0.1.5-win32> 82.99x
2. opus_tools_11_7_2012> 80.47x
3. opus_tools_11_1_2012> 78.1x
4. opus_20121103\Release64> 66.39x
5. opus_20121103\Release32> 57.73x
6. opus-tools-0.1.5-Cygwin5_sl2_121022_04-25> 42.83x
Title: IETF Opus codec now ready for testing
Post by: Krillo on 2012-11-07 10:45:39
No special method is required; wav files contain sufficient information about the channels for opusenc to just go ahead and encode it like any other file.

(If you're noticing the things in the manpage about multichannel, those are there so people who are encoding from raw audio can supply the channel information themselves.)

I can't get it to work when I state multiple wav's (8 mono wav's), so if I rephrase my question:
How do I state all the input files? One works fine, but multiple doesn't.
Title: IETF Opus codec now ready for testing
Post by: The Sheep of DEATH on 2012-11-07 11:05:17
Intel i7-3770 / AsRock B75 Pro3 / 16Gb DDRIII-1333 / Windows 7 Home Premium

opusenc --bitrate 68 --vbr --comp 10 --framesize 60 test.wav test.opus

1. opus-tools-0.1.5-win32> 82.99x
2. opus_tools_11_7_2012> 80.47x
3. opus_tools_11_1_2012> 78.1x
4. opus_20121103\Release64> 66.39x
5. opus_20121103\Release32> 57.73x
6. opus-tools-0.1.5-Cygwin5_sl2_121022_04-25> 42.83x


Good, this is more in line with what I was hoping to see. I should compile the official 0.1.5 snapshot as well for comparison with the official release (otherwise it's apples and oranges comparing two different branches). Thanks again!
Title: IETF Opus codec now ready for testing
Post by: Seren on 2012-11-07 11:47:58
Intel i7-3770 / AsRock B75 Pro3 / 16Gb DDRIII-1333 / Windows 7 Home Premium

opusenc --bitrate 24 --vbr --comp 10 --downmix-mono --framesize 40  test.wav test.opus

1. opus-tools-0.1.5-win32> 52.07x
2. opus_tools_11_7_2012> 45.78x
3. opus_tools_11_1_2012> 45.01x
4. opus_20121103\Release64> 44.26x
5. opus_20121103\Release32> 40.85x
6. opus-tools-0.1.5-Cygwin5_sl2_121022_04-25> 35.89x


Why use --vbr and --comp 10 when they are already the default?
I suspect the official release is ICC since it runs significantly slower than the builds by The Sheep for me.
Also wondering why a i7-3770 is only producing speeds ~2x faster than my Athlon x2 on The Sheeps builds, is it even multithreaded?
Title: IETF Opus codec now ready for testing
Post by: The Sheep of DEATH on 2012-11-07 12:18:19
Why use --vbr and --comp 10 when they are already the default?

I don't know, but sometimes users like 'guarantees' in case defaults change. But just in case, it's good you pointed that out.

Quote
I suspect the official release is ICC since it runs significantly slower than the builds by The Sheep for me.

Mystery (if you could call it that) solved then, I guess! The question becomes whether mine is actually faster than ICC on the same hardware for the current snapshot. A large number of additional analyses were added since 0.1.5 -- new models, tunings, power functions, more compares in general. Tonality, pitch, VBR model, training, leakage prevention, transient detection, probability model, etc... all have been added to, tweaked, or revamped. Hence the apples and oranges comparison of 11-7-2012 with 0.1.5 in terms of speed -- a 3% difference in encoding speed means little in light of these changes. More testing is required.

Quote
Also wondering why a i7-3770 is only producing speeds ~2x faster than my Athlon x2 on The Sheeps builds, is it even multithreaded?

Nope, it's not multithreaded. Best practice for audio codecs is to parallelize them; foobar2000 does this by default.

Title: IETF Opus codec now ready for testing
Post by: no404error on 2012-11-07 17:37:10
And test on the censored newest OS

Intel i7-3770 / AsRock B75 Pro3 / 16Gb DDRIII-1333 / Windows 8 Pro

opusenc --bitrate 68 --vbr --comp 10 --framesize 60 test.wav test.opus

1. opus-tools-0.1.5-win32> 85.66x
2. opus_tools_11_7_2012> 80.47x
Title: IETF Opus codec now ready for testing
Post by: eahm on 2012-11-07 18:07:05
i7-2770k / ASUS P8H77-M PRO / 8GB DDR3-1333 / Windows 8 Pro 64-bit

"opusenc file.wav file.opus"

> opus-tools-0.1.5-win32 (from http://www.opus-codec.org/downloads/ (http://www.opus-codec.org/downloads/)): 69x

> opus-tools-0.1.5-win32_SSE (from http://www.rarewares.org/opus.php (http://www.rarewares.org/opus.php)): 60.38x

> opus_tools_11_7_2012 (from http://www.hydrogenaudio.org/forums/index....&p=813492 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=86580&view=findpost&p=813492)): 69x
Title: IETF Opus codec now ready for testing
Post by: Dynamic on 2012-11-07 22:16:44
I can't get it to work when I state multiple wav's (8 mono wav's), so if I rephrase my question:
How do I state all the input files? One works fine, but multiple doesn't.


Aha, 8 mono WAVs won't be recognised as being multiple channels, I believe. You need to render them into a multichannel WAV which will interleave the samples for all 8 channels at the same point in time. I can't recommend any software but a search for 7.1 channel audio editor freeware produces results such as n-Track Studio (http://downloads.phpnuke.org/en/download-item-view-y-b-m-y-l/N-TRACK%2BSTUDIO.htm) - just watch out for those annoyance-ware download managers and toolbar installers. That app claims to support multichannel WAV export, which should be just fine for providing to the Opus encoder and will tell it which channel is which. You might also wish to combine the LFE channel (the .1) into another channel, such as the centre channel - there's some guidance in the Opus pages, I believe.
Title: IETF Opus codec now ready for testing
Post by: The Sheep of DEATH on 2012-11-08 02:40:17
i7-2770k / ASUS P8H77-M PRO / 8GB DDR3-1333 / Windows 8 Pro 64-bit

"opusenc file.wav file.opus"

> opus-tools-0.1.5-win32 (from http://www.opus-codec.org/downloads/ (http://www.opus-codec.org/downloads/)): 69x

> opus-tools-0.1.5-win32_SSE (from http://www.rarewares.org/opus.php (http://www.rarewares.org/opus.php)): 60.38x

> opus_tools_11_7_2012 (from http://www.hydrogenaudio.org/forums/index....&p=813492 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=86580&view=findpost&p=813492)): 69x


This is almost identical to my system and results. Maybe ICC is generating some Ivy Bridge specific optimizations? Either way, it's very interesting that the rarewares ICC SSE compile is 15% slower than the official release. Since it's neck-and-neck at this point anyway, I thought it wouldn't hurt to include yet another build -- this one is the latest (again) as of this post. May be slightly faster due to stack changes.
Title: IETF Opus codec now ready for testing
Post by: jensend on 2012-11-08 03:11:03
I can't get it to work when I state multiple wav's (8 mono wav's), so if I rephrase my question:
How do I state all the input files? One works fine, but multiple doesn't.
  I'm not aware of any normal encoder that accepts multiple input files to be mixed as one output file. It's an encoder, not a mixer.

Plenty of options for that. Just one example: if you want to do the mixing from the command line, SoX (http://sox.sourceforge.net/sox.html) ??combine merge should do that for you.

A caveat, however: as far as I know, it doesn't currently have a way you can set the channel mask or a way to give explicit instructions about channel order. Instead, the channel order is just whatever order you specify your input files in, and the channel mask is whatever SoX thinks is the best guess given the number of channels you've input. It's quite possible that that works just fine for standard surround setups and only runs into trouble with exotic configurations; I don't have any surround files or equipment, so I don't really know.
Title: IETF Opus codec now ready for testing
Post by: eahm on 2012-11-08 03:13:02
> opus_tools_sse_11_7b_2012 (from http://www.hydrogenaudio.org/forums/index....&p=813592 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=86580&view=findpost&p=813592)): 69x
Title: IETF Opus codec now ready for testing
Post by: The Sheep of DEATH on 2012-11-08 07:42:49
> opus_tools_sse_11_7b_2012 (from http://www.hydrogenaudio.org/forums/index....&p=813592 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=86580&view=findpost&p=813592)): 69x


Thanks! I like to test speed by feeding the encoder a large series of streams (e.g. 50), or one very long concatenated stream, and measuring the time it takes to complete.

I also updated my previous post with a slightly tweaked compile. My tests measure between 0.5-2% speed increase over 11_7b with my test corpus on Sandy Bridge. It now edges up over the official build at --bitrate 68 --framesize 60. It's still neck and neck at anything higher, though.
Title: IETF Opus codec now ready for testing
Post by: no404error on 2012-11-08 12:02:44
Intel i7-3770 / AsRock B75 Pro3 / 16Gb DDRIII-1333 / ImDisk Virtual Disk Driver / Windows 8 Pro x64

Input: 44.1kHz 2 channels, 44 minutes and 15.54 seconds, 468 426 716 bytes

Encoder: opusenc --bitrate 24 --vbr --comp 10 --downmix-mono --framesize 40 test.wav nul

opus-tools-0.1.5-win32 - 85.66x

opus_tools_11_8_2012_sse - 85.66x
opus_tools_sse_11_7b_2012 - 82.99x
opus_tools_11_7_2012 - 82.99x
opus_tools_11_1_2012 - 80.47x
opus-tools-0.1.5-win32_SSE - 78.10x
opus_20121103 x64 - 71.77x
opus_20121103 x86 - 59.01x
opus-tools-0.1.5-Cygwin5_sl2_121022_04-25 - 43.53x
Title: IETF Opus codec now ready for testing
Post by: Krillo on 2012-11-08 13:07:44
Aha, 8 mono WAVs won't be recognised as being multiple channels, I believe. You need to render them into a multichannel WAV which will interleave the samples for all 8 channels at the same point in time.



I'm not aware of any normal encoder that accepts multiple input files to be mixed as one output file. It's an encoder, not a mixer.


I don't want to mix channels, but interleave them, thinking that it would make the opusfile smaller than having 8 separate files. Only that http://opus-codec.org/docs/html_api-1.0.1/index.html (http://opus-codec.org/docs/html_api-1.0.1/index.html) says opus supports upp to 255 channels, but after reading http://msdn.microsoft.com/en-us/windows/ha...e/gg463006.aspx (http://msdn.microsoft.com/en-us/windows/hardware/gg463006.aspx) it seems that wav support max 18 channels. No problem for what I'm trying to do, but how to create 255 channels? 

Thanks for pointing me in the right direction! Found this: http://people.bath.ac.uk/masrwd/mctools.html (http://people.bath.ac.uk/masrwd/mctools.html) will give it a try.
Title: IETF Opus codec now ready for testing
Post by: no404error on 2012-11-08 13:11:02
Quote
Encoder: opusenc --bitrate 24 --vbr --comp 10 --downmix-mono --framesize 40 test.wav nul

Encoder: opusenc --bitrate 68 --vbr --comp 10 --framesize 60 test.wav nul
Title: IETF Opus codec now ready for testing
Post by: CoRoNe on 2012-11-08 15:23:15
I've been reading the manpages for opusenc, but don't understand how to create multichannel opusfiles. I have 8 wavs that I would like, as a test convert to an 8 channel opus. Can this be done, or have I misunderstood?
Without having to download (or even buy) huge programs, there are 2 free simple ways to accomplish this:

- Avisynth (http://avisynth.org/mediawiki/Main_Page)
Open Notepad and enter:
Code: [Select]
FL=WavSource("FrontLeft.wav")
FR=WavSource("FrontRight.wav")
FC=WavSource("FrontCenter.wav")
LF=WavSource("Subwoofer.wav")
BL=WavSource("BackLeft.wav")
BR=WavSource("BackRight.wav")
FLC=WavSource("FrontCenterLeft.wav")
FRC=WavSource("FrontCenterRight.wav")
MergeChannels(FL,FR,FC,LF,BL,BR,FLC,FRC)
Save as output.avs. Download avs2pipemod (http://forum.doom9.org/showthread.php?p=1565165#post1565165). Open a command-prompt:
Code: [Select]
avs2pipemod.exe -extwav output.avs > output.wav
or to encode immediately to opus (not working yet!*):
Code: [Select]
avs2pipemod.exe -extwav script.avs | opusenc.exe - output.opus

- Sox - Sound eXchange (http://sourceforge.net/projects/sox/files/sox/14.4.0/)
Open a command-prompt:
Code: [Select]
sox.exe -M FrontLeft.wav FrontRight.wav FrontCenter.wav Subwoofer.wav BackLeft.wav BackRight.wav FrontCenterLeft.wav FrontCenterRight.wav output.wav
(-M is the same as/short version of --combine merge)
or to encode immediately to opus (not working yet!*):
Code: [Select]
sox.exe -M FrontLeft.wav FrontRight.wav FrontCenter.wav Subwoofer.wav BackLeft.wav BackRight.wav FrontCenterLeft.wav FrontCenterRight.wav -t wav - | opusenc.exe - output.opus
When merging to WAV in both cases a WAVEFORMATEXTENSIBLE header will be created in which the channel order will be specified.

=====================================

*For Opus devs:
I guess this has already been mentioned, but piping multichannel PCM is still bugged.
When I'm trying to pipe the "pcm_s16le, 44100Hz, quad, s16, 2822kb/s"-stream of an Avisynth-script with avs2pipemod to opusenc I get this:
Code: [Select]
avs2pipemod.exe -extwav script-quad.avs | opusenc.exe - output-quad.opus
avs2pipemod[info]: writing 25.500 seconds of 44100 Hz, 4 channel audio.
Skipping chunk of type "fact", length 4
 ☼", length 101843599e "b
Skipping chunk of type "Ö⌡]ⁿ", length 17496280
avs2pipemod[info]: finished, wrote 25.500 seconds [100%].
avs2pipemod[info]: total elapsed time is 0.063 sec.
Error parsing input file: -
With "pcm_s16le, 48000Hz, 5.1, s16, 4608kb/s" it's a lot worse:
Code: [Select]
avs2pipemod.exe -extwav script-5.1.avs | opusenc.exe - output-5.1.opus
avs2pipemod[info]: writing 60.000 seconds of 48000 Hz, 6 channel audio.
Skipping chunk of type "fact", length 4
Skipping chunk of type "", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 63817
Skipping chunk of type "╒²", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 56
Skipping chunk of type "â♠", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 4337
Skipping chunk of type "<", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 64882
Skipping chunk of type "Y♀", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 2980
Skipping chunk of type "φ∩", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 62286
Skipping chunk of type "l
", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 61502
Skipping chunk of type "≤∙", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 62833
Skipping chunk of type "`♥", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 59958
Skipping chunk of type "▒", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 64727
Skipping chunk of type "♦", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 1049
Skipping chunk of type "n≤", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 65361
Skipping chunk of type "µ∙", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 452
Skipping chunk of type "u≥", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 706
Skipping chunk of type "z", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 61704
Skipping chunk of type "ê ", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 1223
Skipping chunk of type ">", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 2459
Skipping chunk of type "╬♠", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 52340
Skipping chunk of type "♠≥", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 2502
Skipping chunk of type "", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 63559
Skipping chunk of type "ü", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 4094
Skipping chunk of type "╧∙", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 1192
Skipping chunk of type "┼∙", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 65155
Skipping chunk of type "╢·", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 62951
Skipping chunk of type "┴♣", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 65327
Skipping chunk of type "╞≤", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 980
Skipping chunk of type "δ♠", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 64679
Skipping chunk of type "↑♥", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 1254
Skipping chunk of type "ê°", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 64663
Skipping chunk of type "╩☻", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 2158
Skipping chunk of type "Æ∙", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 65309
Skipping chunk of type "┬♠", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 2711
Skipping chunk of type "j      ", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 2445
Skipping chunk of type "►", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 5647
Skipping chunk of type "", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 55841
Skipping chunk of type "z√", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 52067
Skipping chunk of type "ƒ≈", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 1925
Skipping chunk of type "∞ ", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 60874
Skipping chunk of type "x ", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 2087
Skipping chunk of type "G☺", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 64663
Skipping chunk of type "?☺", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 65231
Skipping chunk of type "?☻", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 63720
Skipping chunk of type "♣♣", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 263
Skipping chunk of type "â☺", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 1145
Skipping chunk of type "╕♠", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 627
Skipping chunk of type "≈≈", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 64594
Skipping chunk of type "B      ", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 160
Skipping chunk of type "↔♂", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 2439
Skipping chunk of type "Æ°", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 64777
Skipping chunk of type "&      ", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 62670
Skipping chunk of type " ÷", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 62168
Skipping chunk of type "S♣", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 61806
Skipping chunk of type "", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 63334
Skipping chunk of type "f⌡", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 4739
Skipping chunk of type "3", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 65364
Skipping chunk of type "⌠", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 65451
Skipping chunk of type "°ⁿ", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 5128
Skipping chunk of type "ÿ", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 63043
Skipping chunk of type "═      ", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 64874
Skipping chunk of type "
☺", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 3298
Skipping chunk of type "G ", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 63577
Skipping chunk of type "ì      ", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 63672
Skipping chunk of type "«Ω", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 64170
Skipping chunk of type "2☺", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 3514
Skipping chunk of type "q≥", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 4958
Skipping chunk of type "☻ⁿ", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 1737
Skipping chunk of type "A‼", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 40
Skipping chunk of type "m∙", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 64919
Skipping chunk of type "╣♀", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 64159
Skipping chunk of type "$♂", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 64349
Skipping chunk of type ☼", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 980
Skipping chunk of type "←°", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 64256
Skipping chunk of type "☺", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 64009
Skipping chunk of type "Ω‼", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 4292
Skipping chunk of type "─≥", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 5156
Skipping chunk of type " ≤", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 64471
Skipping chunk of type "", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 64727
Skipping chunk of type "╟", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 401
Skipping chunk of type "c☺", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 1497
Skipping chunk of type "G♂", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 1890
Skipping chunk of type "
ⁿ", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 63081
Skipping chunk of type "≡♦", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 431
Skipping chunk of type "6δ", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 65243
Skipping chunk of type "←♥", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 1778
Skipping chunk of type "Oⁿ", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 64832
Skipping chunk of type "o♦", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 903
", length 0unk of type "£
Skipping chunk of type "", length 0
Skipping chunk of type "", length 65052
Skipping chunk of type "▐", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 771
Skipping chunk of type "▐¶", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 725
Skipping chunk of type "A
", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 4399
Skipping chunk of type "Γ∩", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 1316
Skipping chunk of type "'ⁿ", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 3781
Skipping chunk of type "y°", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 477
Skipping chunk of type "█±", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 64795
Skipping chunk of type "", length 0
Skipping chunk of type "┼☺", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 5152
Skipping chunk of type "▼☻", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 63298
Skipping chunk of type "▼ ", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 509
Skipping chunk of type "½⌠", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 63611
Skipping chunk of type "/Θ", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 2667
Skipping chunk of type "╛♦", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 1577
Skipping chunk of type "é♠", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 59793
Skipping chunk of type "%·", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 65351
Skipping chunk of type "x", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 2000
Skipping chunk of type "0☺", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 64888
Skipping chunk of type "ì      ", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 64661
Skipping chunk of type "≤♦", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 580
Skipping chunk of type "ê♦", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 580
Skipping chunk of type "┬■", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 64047
Skipping chunk of type "÷☻", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 1181
Skipping chunk of type "╕♠", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 64930
Skipping chunk of type "ó", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 897
Skipping chunk of type "d÷", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 827
Skipping chunk of type "ï☺", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 150
Skipping chunk of type "Ç■", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 50
Skipping chunk of type "]ⁿ", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 2666
Skipping chunk of type "~ⁿ", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 63396
Skipping chunk of type "", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 65150
Skipping chunk of type "Ü♥", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 757
Skipping chunk of type "☻", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 64473
Skipping chunk of type "»²", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 64340
Skipping chunk of type "■²", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 2164
Skipping chunk of type "¡", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 34
Skipping chunk of type "¢☺", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 63645
", length 0unk of type "0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 4075
Skipping chunk of type "╥┌", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 59596
Skipping chunk of type "gτ", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 2533
Skipping chunk of type "≡♣", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 2843
Skipping chunk of type "", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 65349
Skipping chunk of type "J☻", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 64685
Skipping chunk of type "┬⌡", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 64696
Skipping chunk of type "
", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 3223
Skipping chunk of type "[", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 65107
Skipping chunk of type "╠°", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 1364
Skipping chunk of type "ÿ☻", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 64135
Skipping chunk of type "#·", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 64140
Skipping chunk of type "o      ", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 792
Skipping chunk of type "Æ≤", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 1664
Skipping chunk of type "◄", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 2433
Skipping chunk of type "¢■", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 65374
Skipping chunk of type "E☻", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 3267
Skipping chunk of type "┘☻", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 3873
Skipping chunk of type "┤≈", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 4810
Skipping chunk of type "f²", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 3132
Skipping chunk of type "Ñ∙", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 61594
Skipping chunk of type "┐♦", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 697
Skipping chunk of type "q♠", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 2962
Skipping chunk of type "f♫", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 229
Skipping chunk of type "^⌠", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 62594
Skipping chunk of type "u⌡", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 63541
Skipping chunk of type "‼≈", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 801
Skipping chunk of type "╕ⁿ", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 1957
Skipping chunk of type "▲►", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 64472
Skipping chunk of type "♠≥", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 2864
Skipping chunk of type "Éⁿ", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 2246
Skipping chunk of type "ï°", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 647
Skipping chunk of type "╥√", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 64928
Skipping chunk of type "}φ", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 64772
Skipping chunk of type "¢♦", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 2516
Skipping chunk of type "F♦", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 64568
Skipping chunk of type "╥☻", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 3943
Skipping chunk of type " ≤", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 65043
Skipping chunk of type "§ ", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 3603
Skipping chunk of type "j♥", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 1957
Skipping chunk of type "░≡", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 862
Skipping chunk of type "♣", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 2333
Skipping chunk of type "↔♥", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 64466
Skipping chunk of type "▌♥", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 188
Skipping chunk of type "ù■", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 3238
Skipping chunk of type "♠", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 61498
Skipping chunk of type "'²", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 1419
Skipping chunk of type "♦", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 63953
Skipping chunk of type "'", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 805
Skipping chunk of type "┤      ", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 2659
Skipping chunk of type "", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 62913
Skipping chunk of type "ë☻", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 64796
Skipping chunk of type "f♥", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 64408
Skipping chunk of type "‼♦", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 2897
Skipping chunk of type "", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 64918
Skipping chunk of type "╠♥", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 62684
Skipping chunk of type "┼⌠", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 2301
Skipping chunk of type "φ°", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 2474
Skipping chunk of type "╤
", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 64139
Skipping chunk of type "i²", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 995
Skipping chunk of type ")♣", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 62537
Skipping chunk of type "♣ ", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 63443
Skipping chunk of type "Q√", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 63153
Skipping chunk of type "/±", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 1313
Skipping chunk of type "┤∙", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 0
Skipping chunk of type "", length 0
avs2pipemod[info]: finished, wrote 60.000 seconds [100%].
avs2pipemod[info]: total elapsed time is 3.547 sec.
Error parsing input file: -
Extracting to WAV and feeding that to opusenc works just fine in both cases.
If you need samples, just ask.
Title: IETF Opus codec now ready for testing
Post by: Seren on 2012-11-08 17:50:30
opus_tools_11_8_2012_sse at top and opus tools release at bottom.
This is with nothing open and the same settings as you guys.
Oh and only 7min source sorry =(

(http://i.imgur.com/BIIJ3.png)
Title: IETF Opus codec now ready for testing
Post by: NullC on 2012-11-08 23:07:37
PLEASE STOP POSTING BINARIES THAT GIVE INCORRECT VERSION NUMBERS

I just downloaded "opus_tools_11_8_2012_sse.zip" from up-thread.  The commandline and the files it writes _claims_  that it is "libopus 1.0.1" but I decompiled the code and see that it's some random snapshot of our still fairly experimental 1.1 development branch.

This stinks. It make it hard to deal with quality reports.  You should not be running the pre-1.1. development code unless you're planning on performing some listening tests and reporting back your results.  You certainly shouldn't be posting binaries that create files that claim to be 1.0.1 that aren't.
Title: IETF Opus codec now ready for testing
Post by: greensdrive on 2012-11-09 01:39:47
configure.ac, as it is now, would require manual modification of version.mk in order to write something other than 1.0.1 unless git is used.  windows users would probably download the gitweb snapshot and compile vanilla.  that's not using git, and the snapshot from gitweb doesn't have the .git directory inside.  so even with git present, git describe will not work.

I guess people will have to adjust the version.mk whenever distributing a build, unless a better solution is around.

if I were going to distribute, I would edit version.mk like so (this is a hint to those wanting to compile and distribute):

Code: [Select]
OPUS_VERSION = "1.1-gXXXXXXXX"


where XXXXXXXX is an eight digit representation (seven digits might work) of the most recent git commit.  the actual developers may have a better idea.
Title: IETF Opus codec now ready for testing
Post by: The Sheep of DEATH on 2012-11-09 05:10:46
PLEASE STOP POSTING BINARIES THAT GIVE INCORRECT VERSION NUMBERS

I just downloaded "opus_tools_11_8_2012_sse.zip" from up-thread.  The commandline and the files it writes _claims_  that it is "libopus 1.0.1" but I decompiled the code and see that it's some random snapshot of our still fairly experimental 1.1 development branch.

This stinks. It make it hard to deal with quality reports.  You should not be running the pre-1.1. development code unless you're planning on performing some listening tests and reporting back your results.  You certainly shouldn't be posting binaries that create files that claim to be 1.0.1 that aren't.


From now on, version numbers of non-release builds will be properly reported as 1.1-gXXXXXXXX within the post, binary, filename, bitstream, "tool" tag, and included text file.

I thought it wasn't much of a concern at the time because I was clear to specify in each post (the only place the downloads could be found) it was experimental, and the most recent HEAD as of post time. (After all, it was an exploration of program speeds and compilation optimizations across system and time, not intended specifically for quality tests). The filename also indicates the date of source, which happened to coincide with compilation (I kept everything up to date). I did not consider that the quality would also be evaluated independently (much less reported by users based on the binary's invalid time stamp, which itself is a result of the stock configuration script). My apologies.

[edit]
So here goes. Latest git for both libopus (1.1.c55f4d8 2012-11-10) and opus-tools (0.15git 97a5c5f 2012-11-06) as of this post. Dates are also standardized format from now on (YYYY-MM-DD). Major changes include libopus bugfixes.
Title: IETF Opus codec now ready for testing
Post by: Seren on 2012-11-10 10:41:07
Quote
Bump version.mk.
Naive builders, particular on Windows without git installed, would get builds calling themselves 1.0.1 even though master has diverged significantly from the 1.0.x series at this point.
We should update this file both before and after release.


Looks like they are extremely serious about version numbering...
Though I think they were a bit harsh considering the 1.0.1 release shows RC3 still...
EDIT: Thx Sheep =)
Title: IETF Opus codec now ready for testing
Post by: eahm on 2012-11-14 16:58:52
Acrobits added Opus to its list of codecs. This is a great news and an awesome way to test with iPhone and Android.

http://www.acrobits.cz (http://www.acrobits.cz)
Title: IETF Opus codec now ready for testing
Post by: rt87 on 2012-11-17 08:08:48
kamedo2 has finished ABXing 75kbps/100kbps Opus/AAC-LC tests:
http://twitter.com/kamedo2/status/269517100954034176/photo/1 (http://twitter.com/kamedo2/status/269517100954034176/photo/1)
Title: IETF Opus codec now ready for testing
Post by: The Sheep of DEATH on 2012-11-19 05:40:12
kamedo2 has finished ABXing 75kbps/100kbps Opus/AAC-LC tests:
http://twitter.com/kamedo2/status/269517100954034176/photo/1 (http://twitter.com/kamedo2/status/269517100954034176/photo/1)


Short verdict: opus (in both its 0.9.11 "opus" and 0.11.2 "CELT" form) wins against Apple AAC-LC (presumably 1.7.1, in both "true" and "constrained" VBR) at 75kbps, raking significantly above "3.0" with AAC-LC ranking significantly below 3.0. All codecs tie between 3.5 and 4.0 at 100kbps.

This is a somewhat expected result. However, the standard error (distribution deviation) of Opus quality appears much greater than with Apple AAC-LC, which has relatively small error margins, especially at the higher bitrate. I'm curious about some features of the statistic distribution; is there a spreadsheet of the results anywhere?

Also, latest HEAD/master for libopus (1.1.14454c4 2012-11-14) and opus-tools (0.15git d71e574 2012-11-14).
Title: IETF Opus codec now ready for testing
Post by: Seren on 2012-11-19 11:12:12
This is a somewhat expected result. However, the standard error (distribution deviation) of Opus quality appears much greater than with Apple AAC-LC, which has relatively small error margins, especially at the higher bitrate. I'm curious about some features of the statistic distribution; is there a spreadsheet of the results anywhere?

I was going to post this earlier but I assumed everyone had noticed it already (it's Kamedo2's thread for his listening test):
http://www.hydrogenaudio.org/forums/index....showtopic=97913 (http://www.hydrogenaudio.org/forums/index.php?showtopic=97913)

Oh and thx for the newer build 
Title: IETF Opus codec now ready for testing
Post by: LoRd_MuldeR on 2012-11-20 21:05:32
Got a question regarding the Opus repository:

The website says "Branch exp_analysis7 has experimental encoder perceptual tuning", but recently a lot of activity is in the exp_analysis branch (without any number in the name), while the exp_analysis7 seems to be abandoned (last change many weeks ago). So if I want to get the latest perceptual tuning, which branch is the "right" one? Has active development moved to exp_analysis or should I still stick with exp_analysis7?

Thanks 
Title: IETF Opus codec now ready for testing
Post by: Nekit1234007 on 2012-11-20 21:14:54
Got a question regarding the Opus repository:

The website says "Branch exp_analysis7 has experimental encoder perceptual tuning", but recently a lot of activity is in the exp_analysis branch (without any number in the name), while the exp_analysis7 seems to be abandoned (last change many weeks ago). So if I want to get the latest perceptual tuning, which branch is the "right" one? Has active development moved to exp_analysis or should I still stick with exp_analysis7?

Thanks 

ea7 was merged into the master more than a month ago (commit (https://git.xiph.org/?p=opus.git;a=commit;h=7315b35e13a3a7c504ed6b1fe2d28ad500eb2701)), recent “exp_analysis” branch was created yesterday from the master. From that, I would assume that “active development moved to exp_analysis”.
Title: IETF Opus codec now ready for testing
Post by: jmvalin on 2012-11-20 21:34:58
ea7 was merged into the master more than a month ago (commit (https://git.xiph.org/?p=opus.git;a=commit;h=7315b35e13a3a7c504ed6b1fe2d28ad500eb2701)), recent “exp_analysis” branch was created yesterday from the master. From that, I would assume that “active development moved to exp_analysis”.


At this point, I think you probably want to track master. The stuff in exp_analysis isn't really interesting yet, and when it is, it'll soon get merged back into master. For the time being, I'm not expecting long-lived work to be done on a branch like happened with exp_analysis7 (and the previous versions).
Title: IETF Opus codec now ready for testing
Post by: LoRd_MuldeR on 2012-11-20 21:40:04
ea7 was merged into the master more than a month ago (commit (https://git.xiph.org/?p=opus.git;a=commit;h=7315b35e13a3a7c504ed6b1fe2d28ad500eb2701)), recent “exp_analysis” branch was created yesterday from the master. From that, I would assume that “active development moved to exp_analysis”.


At this point, I think you probably want to track master. The stuff in exp_analysis isn't really interesting yet, and when it is, it'll soon get merged back into master. For the time being, I'm not expecting long-lived work to be done on a branch like happened with exp_analysis7 (and the previous versions).


Thanks for the info!

(Maybe the web-site should be updated then)
Title: IETF Opus codec now ready for testing
Post by: foxyshadis on 2012-11-22 17:05:01
PLEASE STOP POSTING BINARIES THAT GIVE INCORRECT VERSION NUMBERS

I just downloaded "opus_tools_11_8_2012_sse.zip" from up-thread.  The commandline and the files it writes _claims_  that it is "libopus 1.0.1" but I decompiled the code and see that it's some random snapshot of our still fairly experimental 1.1 development branch.

This stinks. It make it hard to deal with quality reports.  You should not be running the pre-1.1. development code unless you're planning on performing some listening tests and reporting back your results.  You certainly shouldn't be posting binaries that create files that claim to be 1.0.1 that aren't.

This is actually unexpectedly difficult for me, because even if a Windows developer modifies version.mk, /win32/genversion.bat will ignore that in favor of the results of
Code: [Select]
git describe --tags --match "v*"
; only if that fails does it fall back to version.mk, but if it works, it actually overwrites version.mk. Problem is, git HEAD is currently tagged as v1.0.1-151-gf92c87a, so you can see the difficulty for someone who actually uses git rather than downloading tarballs.

If the git HEAD is retagged as 1.1 (-pre or whatever) that problem should be fixed. I'm going to temporarily remove genversion.sh and update manually instead.
Title: IETF Opus codec now ready for testing
Post by: LoRd_MuldeR on 2012-11-23 22:02:53
So, Opus will resample 44.1 kHz input to 48 kHz and also everything above 48 kHz gets down-sampled to 48 kHz, because "this simplifies the algorithm". According to the F.A.Q. the Opus decoder will output 48 KHz in that case. The F.A.Q. also says that it is recommended to keep the decoder's output at 48 kHz in order to avoid yet another resampling and because "many inexpensive audio interfaces have poor quality output for 44.1 kHz". Okay. But now I noticed that "opusdec" from the Opus Tools will automatically invoke the resampler to restore the original input rate (e.g. 44.1 kHz). Indeed there is a "--rate" switch to resample to a user-define sample rate, but I'm missing a "--no-resample" switch to avoid re-sampling altogether, ignore the original input rate and just output at the internal Opus sample rate (as the F.A.Q. suggests). Wouldn't adding such a switch to "opusdec" be desirable?

Thanks.
Title: IETF Opus codec now ready for testing
Post by: lvqcl on 2012-11-24 02:30:04
Probably --rate 48000 will do  the trick.
Title: IETF Opus codec now ready for testing
Post by: LoRd_MuldeR on 2012-11-24 13:07:27
Probably --rate 48000 will do  the trick.


Does Opus really always use exactly 48.000 Hz internally, even for "speech" footage with input rates as low as 8.000 Hz? 

And, if so, does "--rate 48000" really ensure, under all circumstances, that the resampler won't get invoked? If so, maybe just make "--no-resample" and alias for "--rate 48000", for clarity.

Regards.

Title: IETF Opus codec now ready for testing
Post by: Caroliano on 2012-11-24 13:31:40
As opus AWAYS resample to 48kHz, a "--no-resample" switch will certainly cause confusion for those who don't know that. I think there may be a better name. Maybe "--native-rate", "--rate internal", "--encoded-rate", or something like that.
Title: IETF Opus codec now ready for testing
Post by: LoRd_MuldeR on 2012-11-24 15:58:27
As opus AWAYS resample to 48kHz


Thanks for confirming.


a "--no-resample" switch will certainly cause confusion for those who don't know that. I think there may be a better name. Maybe "--native-rate", "--rate internal", "--encoded-rate", or something like that.


Anything like that would be welcome.
Title: IETF Opus codec now ready for testing
Post by: lvqcl on 2012-11-28 19:24:24
Current git version -- v1.0.1-154-g07418d9
Title: IETF Opus codec now ready for testing
Post by: .alexander. on 2012-12-05 08:01:21
Hi, I just faced the fact that being mandatory to implement WebRTC codec Opus cannot encode 32KHz signals and WebRTC (some of its components) is designed to support just 8,16 and 32 - but not 48KHz sample rate. Could you clarify, is this a problem of reference implementation or you guys had any particular reason not allocate 2 more bits for 32 and 44.1KHz in bit syntax? Could this be related to transition between SILK and CELT modes? AAC syntax has very minor difference between 32 and 48KHz, basically it's all about mapping bark scale to scale factor bands. Header and side info overhead would be 1.5 times larger for up-sampled signal so it'd probably be better to encode 32KHz signal as 24KHz. What would you expect from OPUS in case it'd be configured for 24KHz to encode 32KHz?
Title: IETF Opus codec now ready for testing
Post by: Speckmade on 2012-12-05 13:24:26
Opus cannot encode 32KHz signals

Maybe this is the most frequent confusion with Opus. Try Google for more on this.
Short answer: Opus always works with 48 kHz internally, though it happily takes input and gives output of any rate you like through internal sampling rate conversion. Opus is a little different than other transform codecs and you should probably think of it as being rateless.
Title: IETF Opus codec now ready for testing
Post by: IgorC on 2012-12-05 13:40:56
Hi, I just faced the fact that being mandatory to implement WebRTC codec Opus cannot ...

http://lmgtfy.com/?q=opus+32+kHz+%20webrtc (http://lmgtfy.com/?q=opus+32+kHz+%20webrtc)
Title: IETF Opus codec now ready for testing
Post by: NullC on 2012-12-05 15:31:52
Hi, I just faced the fact that being mandatory to implement WebRTC codec Opus cannot encode 32KHz signals and WebRTC (some of its components) is designed to support just 8,16 and 32 - but not 48KHz
Don't confuse the WebRTC standard and Google's legacy codebase. In the codebase IIRC existing usage of opus there just hooks up a resampler to front end it, but ultimately I presume their code will be fixed.  I've prodded some people who are more involved with WebRTC to get an update on whats going on with the google codebase, as I haven't been following it.

Quote
sample rate. Could you clarify, is this a problem of reference implementation or you guys had any particular reason not allocate 2 more bits for 32 and 44.1KHz in bit syntax? Could this be related to transition between SILK and CELT modes?
It's related to a couple things, primarily the ability to seamlessly switch between all supported modes and having no possibility of negotiation failure (e.g. remote end only supports 48kHz and your end only supports 32kHz) and also rom and ram size (no separate tables needed for other modes) and what works for computationally cheap internal resampling. It has the benefit that if you're playing a stream from one opus source and the source changes you can just switch to it without upsetting your audio pipeline... or if the network bandwidth changes the codec can make optimal use of whatever is available without a glitchful pipeline interruption.

If an application needs a specific rate for the codec it can always resample, and a reasonably well constructed resampler is perceptually lossless and also quite fast. If opus "supported" more rates thats all it would be doing in any case (and thats effectively what it does for the current supported rates— though they are chosen so that some especially inexpensive handling can be done internally)— as the codec itself doesn't really have a rate in the encoded form (except for the _frame rate_ of 25/50/100/200/400Hz). As far as bitstream bits go... There aren't any bits in the payload for any sampling rates _at all_, though are bits that signal the signals bandpass, which line up with the supported rates, though these can change on a frame by frame basis depending on the content.  Bits aren't free, you know— especially when you can emit 400 frames per second in lower latency modes.
Title: IETF Opus codec now ready for testing
Post by: derf_ on 2012-12-05 16:24:45
Hi, I just faced the fact that being mandatory to implement WebRTC codec Opus cannot encode 32KHz signals and WebRTC (some of its components) is designed to support just 8,16 and 32 - but not 48KHz sample rate.


Right, this is a limitation of the webrtc.org code. It's slowly being addressed, and eventually the whole stack should support 48 kHz.

Could you clarify, is this a problem of reference implementation or you guys had any particular reason not allocate 2 more bits for 32 and 44.1KHz in bit syntax?


As speckmade alluded to, Opus works somewhat differently than most codecs. Because of its focus on communications, it's designed to have no "negotiation failure", i.e., any encoded Opus packet can be decoded without having to know the settings the encoder was configured with. This includes sampling rate. In order to have this work in a relatively simple way, all of the rates it does support evenly divide 48 kHz (consider what would have to be done to make things work if one packet wanted 48 kHz and the next wanted 44.1 kHz, in a codec with MDCT's windowed overlap-adding).

We evaluated supporting 32 kHz very carefully, but in addition to the complexity a) it doesn't match the band layout of the MDCT layer very well (the cutoff lies in the middle of the highest band), and changing that band structure would have hurt the other audio bandwidths, and b) it doesn't save very many bits over just using fullband. Opus spends so few bits on the high bands at typical super-wideband bitrates that the savings is actually comparable to the overhead needed to signal it. Each packet must be independently decodable, so those "2 more bits" you ask for would have to be included in every one. Even if you omitted the highest band completely, at these rates we are usually only encoding its energy, and that is predicted from past frames and lower bands, so it typically only needs 1 to 1.5 bits/channel per packet to begin with.

AAC syntax has very minor difference between 32 and 48KHz, basically it's all about mapping bark scale to scale factor bands.


Yes, and this is how Opus Custom (the old, more configurable CELT layer) works, but it gives up many of the other properties we wanted, and makes the implementation more complex (for example, the Rockbox people have started contributing decoder optimizations which simply wouldn't work with Opus Custom). For these and many other reasons, we don't recommend people actually use Opus Custom unless they have very specialized hardware that requires particular frame sizes or sampling rates, and don't have to interoperate with anyone else.

Header and side info overhead would be 1.5 times larger for up-sampled signal so it'd probably be better to encode 32KHz signal as 24KHz. What would you expect from OPUS in case it'd be configured for 24KHz to encode 32KHz?


Given what I said above, I would recommend encoding a 32 kHz signal as fullband. I don't know what you mean by "header overhead"... the header sizes are independent of the audio bandwidth. Opus also does not include any per-sample side information and, as I said above, the actual extra rate required to go from 32 kHz to 48 kHz is pretty small. This is the approach taken to supporting Opus in the webrtc.org code until it gets full support for 48 kHz sampling rates. You can see that in the patch that is currently the first result of IgorC's link.
Title: IETF Opus codec now ready for testing
Post by: .alexander. on 2012-12-10 09:50:08
Thanks! Opus design really benefits from lack of 32 KHz support. Though solutions that have jitter buffer as primary source of latency may not need 400 packets per second. Upsampling by 3 and 1.5 is almost the same, I looked into your code and gave up with impression that there is no explicit upsampling and inventing pruned MDCT to avoid some resampling latency is overkill. Do you have any expectations of change in average call duration with switch from ISAC to Opus? Design goals and subjective tests are good, but what if call duration would drop on a very big sample?
Title: IETF Opus codec now ready for testing
Post by: bawjaws on 2012-12-11 11:53:39
Design goals and subjective tests are good, but what if call duration would drop on a very big sample?


I can't find the link right now but I think Skype (who were involved in creating Opus) did this exact test and found it was a positive change (at least compared with previous codec, which might have been Silk alone, or their previous codec, not sure)
Title: IETF Opus codec now ready for testing
Post by: jossilint on 2012-12-17 20:58:57
I tested and at least to me ffmpeg FDK-AAC(he-v2) 40Kbps vbr sounds better than opus(0.1.6) 40Kbps vbr ? any thoughts? can opus defeat aac-he-v2 at low bitrates, i even found one internet radio with opus test, if admins allow i post link here.
Title: IETF Opus codec now ready for testing
Post by: saratoga on 2012-12-17 21:08:26
I tested and at least to me ffmpeg FDK-AAC(he-v2) 40Kbps vbr sounds better than opus(0.1.6) 40Kbps vbr ? any thoughts?


How did you compare?
Title: IETF Opus codec now ready for testing
Post by: Seren on 2012-12-17 21:22:23
I find you need to be over 48kb/s for opus for stereo music. HE seems to sound better just below that, though you can always drop the opus encode to mono and it'd sound better than the HE-AAC below 48kb/s. Well these are my findings based on a few listens, no real ABX'ing so it may be different for others.
Title: IETF Opus codec now ready for testing
Post by: Gainless on 2012-12-22 11:36:50
New alpha version has been released:
Link (http://downloads.xiph.org/releases/opus/opus-1.1-alpha.tar.gz)

Can someone compile it?
Title: IETF Opus codec now ready for testing
Post by: Nekit1234007 on 2012-12-22 11:49:55
Here is a build I made for myself with some crazy gcc parameters, might not work for many people, should work with i7s, x64 only.

http://www.mediafire.com/?onut3ba3ygz9493 (http://www.mediafire.com/?onut3ba3ygz9493)
Title: IETF Opus codec now ready for testing
Post by: Seren on 2012-12-22 14:00:23
Here is a build I made for myself with some crazy gcc parameters, might not work for many people, should work with i7s, x64 only.

http://www.mediafire.com/?onut3ba3ygz9493 (http://www.mediafire.com/?onut3ba3ygz9493)

Doesn't work on AMD Athlon x2. "opusenc has stopped working"
Title: IETF Opus codec now ready for testing
Post by: lvqcl on 2012-12-22 14:31:41
MSVC compile; requires WinXP and SSE processor.

[obsolete; removed]
Title: IETF Opus codec now ready for testing
Post by: jmvalin on 2012-12-22 16:24:52
For those interested, here's a blog post (http://jmspeex.livejournal.com/11737.html) that describes what's in this alpha in more details.
Title: IETF Opus codec now ready for testing
Post by: Nick.C on 2012-12-22 18:21:47
From the blog regarding the revised VBR constraints - does this mean that the output is tending towards constant quality rather than constant bitrate?

btw: I've been listening to 96kbit/s OPUS output on my RockBoxed Sansa Fuze and am very pleased with what I hear....
Title: IETF Opus codec now ready for testing
Post by: jmvalin on 2012-12-22 18:55:16
From the blog regarding the revised VBR constraints - does this mean that the output is tending towards constant quality rather than constant bitrate?


Correct.
Title: IETF Opus codec now ready for testing
Post by: ErectX on 2012-12-23 00:57:28
Here is a build I made for myself with some crazy gcc parameters, might not work for many people, should work with i7s, x64 only.

http://www.mediafire.com/?onut3ba3ygz9493 (http://www.mediafire.com/?onut3ba3ygz9493)

Doesn't work on AMD Athlon x2. "opusenc has stopped working"

Works for me on a Core2. Do you have a 64-bit OS?

1st Athlon x2 - Manchester:
MMX, Extended 3DNow!, SSE, SSE2, SSE3, AMD64, Cool'n'Quiet, NX Bit

Core2 Quad Kentsfield:
MMX, SSE, SSE2, SSE3, SSSE3, Enhanced Intel SpeedStep Technology (EIST), Intel 64, XD bit (an NX bit implementation), iAMT2 (Intel Active Management), Intel VT-x

I have noticed a glitchiness in otherwise stellar 32kbps stereo 24KHz on this build. With radio (voice plus occasional music behind talking), sometimes there will be pronounced audio glitches or popping in one channel, they stand out using headphones because of easy localization vs center voice (they appear to be in the audio stream as repeating the audio gives the same glitches, but I haven't extensively researched yet to verify it's not player-specific to Rockbox Clip+). Also transitions from mono to stereo with a bit of background stereo music in this mode are less then transparent.

I also noted in 1.0.1 (but haven't re-evaluated for improvement with 1.1A yet), that the stream predictor means that you don't get the same audio twice, not at all. Encoding a file with the same two minutes repeated gets you different encoding results two minutes later in the stream. Using 21kbps with -6dB voice there was about one minute of lowpass at 8KHz at the start of the file, when the audio repeated it had 12KHz bandwidth, very visible and audible. Increasing to 22kbps or increasing the source audio level altered the bandwidth allocations but still was quite different on repeated encoding depending on where in the file it was. Perhaps a two-pass encoding or a very large pre-skip, preloading the first minute to train the encoder, would help this.
Title: IETF Opus codec now ready for testing
Post by: Seren on 2012-12-23 02:09:00
Here is a build I made for myself with some crazy gcc parameters, might not work for many people, should work with i7s, x64 only.

http://www.mediafire.com/?onut3ba3ygz9493 (http://www.mediafire.com/?onut3ba3ygz9493)

Doesn't work on AMD Athlon x2. "opusenc has stopped working"

Works for me on a Core2. Do you have a 64-bit OS?

1st Athlon x2 - Manchester:
MMX, Extended 3DNow!, SSE, SSE2, SSE3, AMD64, Cool'n'Quiet, NX Bit

Core2 Quad Kentsfield:
MMX, SSE, SSE2, SSE3, SSSE3, Enhanced Intel SpeedStep Technology (EIST), Intel 64, XD bit (an NX bit implementation), iAMT2 (Intel Active Management), Intel VT-x


Sorry, I kinda screwed that up, I meant "Athlon II" (x2 245 using MMX(+), 3DNow!(+), SSE(1,2,3,4A), x86-64, AMD-V)
Win7 x64.
Title: IETF Opus codec now ready for testing
Post by: Gainless on 2012-12-23 10:23:55
MSVC compile; requires WinXP and SSE processor.

Thanks!

It seems like the new alpha version performs worse on certain stuff than Opus tools 0.1.6, e.g on the Muse Breaks and Sycho Active samples (can be found here (http://www.mediafire.com/download.php?r9wt1g24d7cx9lu) and here (http://www.hydrogenaudio.org/forums/index.php?act=attach&type=post&id=7217)), obvious glitches at 192 kbps, while OT is pretty much transparent there.
Title: IETF Opus codec now ready for testing
Post by: ErectX on 2012-12-23 17:02:30
Here is a build I made for myself with some crazy gcc parameters, might not work for many people, should work with i7s, x64 only.

http://www.mediafire.com/?onut3ba3ygz9493 (http://www.mediafire.com/?onut3ba3ygz9493)

Doesn't work on AMD Athlon x2. "opusenc has stopped working"

It looks like the one instruction set missing is SSSE3 (http://en.wikipedia.org/wiki/SSSE3#CPUs_with_SSSE3) which is only on AMD Bulldozer+/Core2+. I don't have 64bit OS on my non-SSSE3 Intel (P4 Prescott MMX, SSE, SSE2, SSE3, Hyper-Threading, Intel 64, XD bit) to check this binary. Perhaps Nekit1234007 can detail what the "crazy parameters" were.

This build runs about 5% faster than Mozilla opus-tools, so no complaints.
Title: IETF Opus codec now ready for testing
Post by: Nekit1234007 on 2012-12-23 17:06:36
Perhaps Nekit1234007 can detail what the "crazy parameters" were.

Code: [Select]
 -mfpmath=both -Ofast -flto -march=native
I have Core i5-450M. I think they’re crazy, but I might be wrong here, I’m not very experienced in configuring/building stuff.
Title: IETF Opus codec now ready for testing
Post by: IgorC on 2012-12-24 17:29:12
Finally Google will support Opus in its new WebM. It will add new video and audio codecs VP9+Opus to previous VP8+Vorbis.
http://peter.sh/2012/12/vp9-and-opus-backg...by-positioning/ (http://peter.sh/2012/12/vp9-and-opus-background-position-offset-and-ruby-positioning/)
Title: IETF Opus codec now ready for testing
Post by: kode54 on 2012-12-24 19:08:27
-march=native means it will optimize for your build machine's processor. It's probably better to go for something more generic than that.
Title: IETF Opus codec now ready for testing
Post by: Nekit1234007 on 2012-12-24 19:36:33
-march=native means it will optimize for your build machine's processor. It's probably better to go for something more generic than that.
I know. And that’s why I said:

a build I made for myself

Just wanted to share, and thought it might be usable/useful for someone besides me!
Title: IETF Opus codec now ready for testing
Post by: polemon on 2012-12-25 19:45:52
Finally Google will support Opus in its new WebM. It will add new video and audio codecs VP9+Opus to previous VP8+Vorbis.
http://peter.sh/2012/12/vp9-and-opus-backg...by-positioning/ (http://peter.sh/2012/12/vp9-and-opus-background-position-offset-and-ruby-positioning/)

I've enabled the flag and relaunched the browser. When I do the HTML5 test at html5test.com, I still see the browser as not having Opus support. Can anybody confirm that?
Title: IETF Opus codec now ready for testing
Post by: Seren on 2012-12-25 21:00:52
Finally Google will support Opus in its new WebM. It will add new video and audio codecs VP9+Opus to previous VP8+Vorbis.
http://peter.sh/2012/12/vp9-and-opus-backg...by-positioning/ (http://peter.sh/2012/12/vp9-and-opus-background-position-offset-and-ruby-positioning/)

I've enabled the flag and relaunched the browser. When I do the HTML5 test at html5test.com, I still see the browser as not having Opus support. Can anybody confirm that?

I managed to play Opus in Chrome Dev, but it crashes Chrome on a few songs for some reason...
Doesn't really bother me since I use Firefox as my main.
EDIT: OH yeah forgot to mention html5test is also reporting no opus support.
Title: IETF Opus codec now ready for testing
Post by: Atak_Snajpera on 2012-12-26 23:04:05
since webm is nothing but matroska container i wonder how do they mux vp9 and opus. from what i know matroska team has not yet figure out how to propelly support .opus in .mkv. mainly issues with accurate seeking.
Title: IETF Opus codec now ready for testing
Post by: Funkstar De Luxe on 2012-12-27 09:34:16
MSVC compile; requires WinXP and SSE processor.


Thanks for this.  Little slower than RC3, with slightly higher bit rates on some samples (although 96kbps still averages on 95Kbps in 1000 sample tracks).  ABXable quality jump though.  Heading in the right direction, I think.  Now, if only I could find a player for Android.
Title: IETF Opus codec now ready for testing
Post by: Bostedclog on 2012-12-27 20:49:54
MSVC compile; requires WinXP and SSE processor.


Thanks for this.  Little slower than RC3, with slightly higher bit rates on some samples (although 96kbps still averages on 95Kbps in 1000 sample tracks).  ABXable quality jump though.  Heading in the right direction, I think.  Now, if only I could find a player for Android.


Could someone explain to me what MSVC compile means. Ive bee using the op link to the latest alpha version and found it superb. Flac to Opus at 64kbs.Thanks
Title: IETF Opus codec now ready for testing
Post by: LigH on 2012-12-27 20:58:46
Could someone explain to me what MSVC compile means.


It was compiled with the Microsoft Visual C++ compiler.
Title: IETF Opus codec now ready for testing
Post by: polemon on 2012-12-27 22:20:32
MSVC compile; requires WinXP and SSE processor.


Thanks for this.  Little slower than RC3, with slightly higher bit rates on some samples (although 96kbps still averages on 95Kbps in 1000 sample tracks).  ABXable quality jump though.  Heading in the right direction, I think.  Now, if only I could find a player for Android.


Could someone explain to me what MSVC compile means. Ive bee using the op link to the latest alpha version and found it superb. Flac to Opus at 64kbs.Thanks


MSVC is the Microsoft C compiler that comes with Visual Studio. MSVCPP is the C++ compiler. The MSVC is considered to be sub-par to things like GCC, so many use MinGW. MSVC just supports C89. MSVCPP is pretty much standard on Windows though...
Title: IETF Opus codec now ready for testing
Post by: Bostedclog on 2012-12-28 02:31:37
MSVC compile; requires WinXP and SSE processor.


Thanks for this.  Little slower than RC3, with slightly higher bit rates on some samples (although 96kbps still averages on 95Kbps in 1000 sample tracks).  ABXable quality jump though.  Heading in the right direction, I think.  Now, if only I could find a player for Android.


Could someone explain to me what MSVC compile means. Ive bee using the op link to the latest alpha version and found it superb. Flac to Opus at 64kbs.Thanks


MSVC is the Microsoft C compiler that comes with Visual Studio. MSVCPP is the C++ compiler. The MSVC is considered to be sub-par to things like GCC, so many use MinGW. MSVC just supports C89. MSVCPP is pretty much standard on Windows though...

Many thanks for your detailed answer mate.When you say its sub par do you mean the quality of the encoding (sound quality)? If so would you recommend for me to wait for  a different compile to convert my music library  to opus ? Again thank you.
Title: IETF Opus codec now ready for testing
Post by: saratoga on 2012-12-28 02:38:57
Many thanks for your detailed answer mate.When you say its sub par do you mean the quality of the encoding (sound quality)?


He means that it might be slower.
Title: IETF Opus codec now ready for testing
Post by: Bostedclog on 2012-12-28 14:16:52
Many thanks for your detailed answer mate.When you say its sub par do you mean the quality of the encoding (sound quality)?


He means that it might be slower.

Bottom of the class I go lol. Many thanks Saratoga.I have many things to learn.
Title: IETF Opus codec now ready for testing
Post by: softrunner on 2012-12-29 02:50:31
Here (http://www.hydrogenaudio.org/forums/index.php?showtopic=96108&view=findpost&p=818688) I have passed ABX test for git version of Opus from 10.11.2012 at 256 kbps.
-----------------------
If new Opus 1.2 "is tending towards constant quality rather than constant bitrate" then why it uses almost the same bitrate for mono? Musepack uses twice lower bitrate for mono. Why Opus can't do this?
For my opinion constant quality means that there shound not be any mention of bitrate at all. Encoder should have presets like "Low quality", "Good quality" and "High quality" and use an appropriate bitrate for every separate sample. Quality here is tied for audibility of distortions produced by encoder. For example, for simple piano music Vorbis q4 gives high quality (very difficult if possible to hear distortions), for rock-pop music Vorbis q4 gives good quality (distortions can be heard due to cutoff etc.), and for complex electronic music it gives low quality (sounds far from the original). So, Vorbis does not have true VBR mode. For true VBR mode user should not think about bitrate at all. I don't know weather it is possible for encoder to do such an analysis of a source audio, but it would be great it yes.
Title: IETF Opus codec now ready for testing
Post by: vinnie97 on 2012-12-29 21:45:10
MSVC compile; requires WinXP and SSE processor.


Thanks for this.  Little slower than RC3, with slightly higher bit rates on some samples (although 96kbps still averages on 95Kbps in 1000 sample tracks).  ABXable quality jump though.  Heading in the right direction, I think.  Now, if only I could find a player for Android.

If you can tolerate betas and/or alphas/daily builds, VLC and Rockbox will do what you seek (mentioned several pages back).
Title: IETF Opus codec now ready for testing
Post by: saratoga on 2013-01-01 03:53:53
I found some free time this afternoon and looked into the Opus decoder.  I think it can be optimized quite a lot for portable devices by improving the FFT it uses.  If anyone is interested, I started by first writing an ARMv5 complex multiplication routine:

http://gerrit.rockbox.org/r/#/c/377/ (http://gerrit.rockbox.org/r/#/c/377/)

This gives a nice speed up.  The next thing to do logically would be to go through and rewrite the butterflies in Opus's FFT (specifically it uses kissfft).  The 4 prime and 5 prime butterflies are quite small but use 30% of the runtime on ARM.  With some effort a lot of savings should be possible.
Title: IETF Opus codec now ready for testing
Post by: Martel on 2013-01-01 10:46:21
I don't know weather it is possible for encoder to do such an analysis of a source audio, but it would be great it yes.
It's only a matter of finding the right formula/algorithm.
There may be another reason why it's not done the way you described and that reason may be bitrate predictability. Personally, I would find it unnerving if I was encoding my collection for a portable device and would get a totally random bitrate for each song. I would have no idea how much I could fit onto the device and I could even end up in a situation where I would have to re-encode everything at a lower setting so it fits in there.
Title: IETF Opus codec now ready for testing
Post by: LigH on 2013-01-01 10:56:23
Well, that's just the purpose of a true quality based mode: You want to be certain that the loss of quality stays below a given threshold. Usually that's just opposite to respecting a target bitrate.

__


^ your avatar: Caleb was chosen!
Title: IETF Opus codec now ready for testing
Post by: vinnie97 on 2013-01-02 17:48:31
I found some free time this afternoon and looked into the Opus decoder.  I think it can be optimized quite a lot for portable devices by improving the FFT it uses.  If anyone is interested, I started by first writing an ARMv5 complex multiplication routine:

http://gerrit.rockbox.org/r/#/c/377/ (http://gerrit.rockbox.org/r/#/c/377/)

This gives a nice speed up.  The next thing to do logically would be to go through and rewrite the butterflies in Opus's FFT (specifically it uses kissfft).  The 4 prime and 5 prime butterflies are quite small but use 30% of the runtime on ARM.  With some effort a lot of savings should be possible.

Thanks for your work.  Does this effort get added to the daily builds?
Title: IETF Opus codec now ready for testing
Post by: darkbyte on 2013-01-09 18:28:58
Are there any prebuilt 1.1-alpha Windows binaries available to download? I like to try out the new unconstrained VBR encoding and i've tried to build it with VS 2012 Express but i can't compile the opustools because it's say all the projects are incompatbile in the solution. However i can compile the 1.1-alpha libopus just fine.
Title: IETF Opus codec now ready for testing
Post by: Nekit1234007 on 2013-01-09 19:24:25
Are there any prebuilt 1.1-alpha Windows binaries available to download?

Yes, earlier in this thread, starting here (http://www.hydrogenaudio.org/forums/index.php?showtopic=86580&view=findpost&p=817958).
Title: IETF Opus codec now ready for testing
Post by: darkbyte on 2013-01-09 21:26:20
Are there any prebuilt 1.1-alpha Windows binaries available to download?

Yes, earlier in this thread, starting here (http://www.hydrogenaudio.org/forums/index.php?showtopic=86580&view=findpost&p=817958).

Thanks and sorry for being blind.
Title: IETF Opus codec now ready for testing
Post by: saratoga on 2013-01-21 00:57:01
I found some free time this afternoon and looked into the Opus decoder.  I think it can be optimized quite a lot for portable devices by improving the FFT it uses.  If anyone is interested, I started by first writing an ARMv5 complex multiplication routine:

http://gerrit.rockbox.org/r/#/c/377/ (http://gerrit.rockbox.org/r/#/c/377/)

This gives a nice speed up.  The next thing to do logically would be to go through and rewrite the butterflies in Opus's FFT (specifically it uses kissfft).  The 4 prime and 5 prime butterflies are quite small but use 30% of the runtime on ARM.  With some effort a lot of savings should be possible.

Thanks for your work.  Does this effort get added to the daily builds?


They are now, but the first changes are very minor. Much more work is needed.
Title: IETF Opus codec now ready for testing
Post by: saratoga on 2013-01-21 01:07:56
Some fun benchmarking on ARMv5 (AMS3525v2, Clipv2, 240MHz w/ 24MHz DRAM):

opus64k, 5ms delay:    102 MHz
opus64k, 20ms delay:  65 MHz
opus128k, 20ms delay:  75 MHz

A lot more work to do, but almost all the time is in the FFTs, so at least it should be possible.
Title: IETF Opus codec now ready for testing
Post by: Gainless on 2013-02-10 15:14:51
Has there been any look on fixing up killer samples btw? The unconstrained VBR has definately flaws in some cases, which makes it still safer to use older versions/constrained VBR at high bitrates.
Title: IETF Opus codec now ready for testing
Post by: Garf on 2013-02-10 16:32:32
If somebody hasn't seen there is an official Opus 1.1 alpha.

https://ftp.mozilla.org/pub/mozilla.org/opu...alpha-win32.zip (https://ftp.mozilla.org/pub/mozilla.org/opus/win32/opus-tools-0.1.6-opus-1.1-alpha-win32.zip)

Also some kinda settings to play with
https://wiki.xiph.org/Opus_tuning (https://wiki.xiph.org/Opus_tuning)


Imo official opus binaries should be stickied in a thread of it's own. As posting on a topic like this could likely cause it to be buried.


Maybe a sticky with the latest binaries etc...
Title: IETF Opus codec now ready for testing
Post by: IgorC on 2013-02-10 17:35:31
It would be really handy. Like "Nero AAC Recommended Settings" http://www.hydrogenaudio.org/forums/index....showtopic=44310 (http://www.hydrogenaudio.org/forums/index.php?showtopic=44310)
Title: IETF Opus codec now ready for testing
Post by: DonP on 2013-02-13 16:19:47
I encoded a bunch of various music at bitrate=100 using the "babyeater" release.  The majority showed in foobar properties as between 100 and 110 kb/s, some much higher, and none below target rate.  Then I did the math using the whole file size (including metadata and whatever else besides the audio data) and play time on 2 of the files and found in both foobar was reporting the bitrate higher than it should by a few kb/s.

With the case below, that would be (4 969 864 bytes) * (8 bits/byte) / (1024 bit/kbit) / (374.7 seconds) = 103.6 kb/s

(http://i12.photobucket.com/albums/a226/w1uw/misc/foobarproperties_zpsbe00492a.jpg)
Title: IETF Opus codec now ready for testing
Post by: nu774 on 2013-02-13 16:27:31
http://en.wikipedia.org/wiki/Bit_rate (http://en.wikipedia.org/wiki/Bit_rate)
Title: IETF Opus codec now ready for testing
Post by: Jplus on 2013-02-13 16:56:55
Thanks for pointing that out, nu774. So then it becomes 4969864B * 8b/B / 1000b/kb / 374.7s = 106.1kb/s and Foobar2000 turns out to do it right. Now I'm starting to wonder whether my bitrate numbers from opusinfo were calculated using base 10 or base 2.

After checking: opusinfo does it in base 10, too. Note that I used the "without overhead" bitrates from opusinfo in the post that I linked to above. With overhead the numbers are 0.5-2kbps greater.
Title: IETF Opus codec now ready for testing
Post by: db1989 on 2013-02-15 15:35:26
Done:

I propose that new posts in this thread which do not continue existing discussion here be split off, as Opus has it own subforum.
Opus 1.1 alpha version (not BABYEATER) (http://hydrogenaudio.org/forums/?showtopic=99495), including softrunner’s post about this version and spectrograms.

Mods, could we get a threadsplit for these quality level posts? I really think this deserves its own thread.
Can audio encoders target quality w/o caring about bit rate/file size? (http://hydrogenaudio.org/forums/?showtopic=99494)

Some replies somewhat spanned over both topics, as evidenced by my having to begin the latter with another post that (handily!) quoted softrunner’s initial message – if only we could split single posts, too  – but I think this works pretty well.

I agree with the sentiment that things should be posted to separate threads if at all possible since there’s a dedicated subforum for Opus now. I’ll see if anything from the past couple of pages here stands out as being split-worthy, but you’ll excuse me if I don’t look too far back.
SimplePortal 1.0.0 RC1 © 2008-2021