When I convert audio sample from here 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.

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)

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 LibetI don't have an idea how relevant this one is - but support seems around the corner given that it uses GStreamer as backend.

Quod LibetI 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.

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).

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 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 was closed 15 days ago as "rejected" and on the mailing list the most recent message asks for G.729 because of increased efficiency. There's another, older ticket 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..?

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.

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.

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.

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?

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.

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.

I'm happy to be posting a new update to the experimental encoder: 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.

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.