Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: IETF Opus codec now ready for testing (Read 392775 times) previous topic - next topic
0 Members and 3 Guests are viewing this topic.

IETF Opus codec now ready for testing

Reply #200
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.

IETF Opus codec now ready for testing

Reply #201
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)
Sorry for my English.

IETF Opus codec now ready for testing

Reply #202
- 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.

IETF Opus codec now ready for testing

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

IETF Opus codec now ready for testing

Reply #204
Quod Libet
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/mutagen/issues/detail?id=115

IETF Opus codec now ready for testing

Reply #205
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).

IETF Opus codec now ready for testing

Reply #206
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.

IETF Opus codec now ready for testing

Reply #207
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..?


IETF Opus codec now ready for testing

Reply #209
LameXP supports Opus. LameXP v4.05 Alpha-9 even adds Unicode support.


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.

IETF Opus codec now ready for testing

Reply #210
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.


IETF Opus codec now ready for testing

Reply #212
I've put up  a new build of the experimental encoder.

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.

 

IETF Opus codec now ready for testing

Reply #213
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?

IETF Opus codec now ready for testing

Reply #214
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.

IETF Opus codec now ready for testing

Reply #215
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.

IETF Opus codec now ready for testing

Reply #216
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.

IETF Opus codec now ready for testing

Reply #217
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.

IETF Opus codec now ready for testing

Reply #218
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.

IETF Opus codec now ready for testing

Reply #219

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.

IETF Opus codec now ready for testing

Reply #220
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".

IETF Opus codec now ready for testing

Reply #221
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.

IETF Opus codec now ready for testing

Reply #222
- 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?
Sorry for my English.


IETF Opus codec now ready for testing

Reply #224
Is 'native' gapless support (like in Vorbis) planned for Opus?

I did a quick test with some problematic samples 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.)