Opus is now RFC6716, version 1.0.1 released! Options

[saratoga]

Really? I don't think that 3mb was 24-bit 96 KHz. Is there a way to find out what an opus file is, in terms of bit rate, bit depth, sampling rate, etc.?

Internally sampling rate is always 48k, but I believe it will be resampled back to 96k in foobar (haven't tested this though so I might be wrong). Bitrate depends on your settings, you can check the result in foobar.

Only PCM files have a bit depth, not lossy formats like Opus.

Edit: Just tested and doing 44.1k Wav > Opus results in an opus file with SAMPLERATE_ORGINAL set to 44.1k as expected. Decoding that file in foobar without specifying a resampler does output a 48k WAV file however.

This post has been edited by saratoga: Oct 11 2012, 05:10

[Dynamic]

Edit: Just tested and doing 44.1k Wav > Opus results in an opus file with SAMPLERATE_ORGINAL set to 44.1k as expected. Decoding that file in foobar without specifying a resampler does output a 48k WAV file however.

Yup, this came up in a thread about fb2k Opus behaviour before. fb2k's internal architecture is geared to playback, where 48kHz is the sensible choice for Opus (and the incoming sample rate may get changed mid-stream quite legitimately, especially for streaming).

I don't think fb2k's Converter dialog yet includes an option to automatically resample Opus back to original sample rate by passing that data forward, but it's feasible in future.

In the mean time, you need to manually resample to the required rate.

I don't think there's any user option for conditional DSP use in the Converter based on values in the file or stream properties (e.g. set Resampler (PPHS) to SAMPLERATE_ORIGINAL when that value is present in the current file)


P.S. With quoting, you need to delete after the tag that looks a bit like
[ quote name='blahblah' date='Oct 11 2012, 09:45 post='987654']
to keep it inside a quote box, and don't delete the [ /quote] tag at the end either. A quote needs a starting tag and a closing tag with a forward slash.

If the person you're quoting had quoted someone else and you don't need the quote-within-a-quote, you can select from the start of the second [ quote] to the end of the first [ /quote] and delete it.

[NullC]

Really? I don't think that 3mb was 24-bit 96 KHz. Is there a way to find out what an opus file is, in terms of bit rate, bit depth, sampling rate, etc.?

An opusfile doesn't have a single bitrate (though you can get an average from opusinfo), nor does it have a depth, or a sampling rate (Unless you want to be pedantic and call the frame rate a sample rate— but that can be anywhere from 16 to 400hz and change on the fly). The header used in oggopus stores the 'input' sampling rate so a file decode tool can preserve the rate to avoid surprising people, but there is no record of the input depth (since none of the other lossy tools bother perserving it I didn't think there was a surprise concern there).

[Anakunda]

It looks like libOpus 1.0.2 was released:

Opus 1.0.2 fixes an out-of-bounds read that could be triggered by a malicious Opus packet causing an integer wrap-around in the padding code. Considering that the packet would have to be at least 16 MB in size and that no out-of-bounds write is possible, the severity is very low. Other changes include fixes and improvements to the PLC and hybrid mode quality improvements. As usual, this release is fully compliant with the Opus specification.

Try how it works please:
http://www.datafilehost.com/download-a36da263.html
http://www22.zippyshare.com/v/12534750/file.html

This post has been edited by Anakunda: Dec 7 2012, 08:05

[eahm]

opusenc file.wav:




and with foobar2000:



This post has been edited by eahm: Dec 7 2012, 09:15

[Seren]

Also getting ^this^

[Anakunda]

You are right eahm, seren. there's missing dll, please redownload

http://www13.zippyshare.com/v/63740765/file.html

[Seren]

You are right eahm, seren. there's missing dll, please redownload

http://www13.zippyshare.com/v/63740765/file.html

Well it seems that it works now... for 80% or so of people

Didn't know this happened with version 12
"Fatal Error: This program was not built to run on the processor in your system.
The allowed processors are: Intel® processors with Swing New Instructions supp
ort."

EDIT: Maybe I should just wait for an official build or one from The_Sheep (who does the fastest builds for me, providing he has the time).

This post has been edited by Seren: Dec 7 2012, 12:03

[Anakunda]

I apologize for the inconvenience, it as built with all the optimizations so it is likely it won't work on some CPUs. I might make a non-optimized generic encoder too if this is a problem

Generic version here :
http://www15.zippyshare.com/v/77085748/file.html

This post has been edited by Anakunda: Dec 7 2012, 12:44

[Garf]

I don't think fb2k's Converter dialog yet includes an option to automatically resample Opus back to original sample rate by passing that data forward, but it's feasible in future.

What would a valid use case for that be?

Sounds like an option that mostly would allow people to shoot themselves in the foot.

[Garf]

I apologize for the inconvenience, it as built with all the optimizations so it is likely it won't work on some CPUs. I might make a non-optimized generic encoder too if this is a problem

Intel's compiler inserts some code in the binary that detects which CPU you have and refuses to run or disables all optimizations if it's an AMD CPU. It also miscompiles lots of code. You're better off not using it. I think gcc 4.7/mingw generate faster binaries now that run on all CPUs too.

Additionally, the changes in this encoder aren't very relevant to HA usage unless you're encoding an audiobook at < 48kbps.

Basically, you probably want to wait for a mingw compile or not update at all as it's likely not needed.

[Seren]

I apologize for the inconvenience, it as built with all the optimizations so it is likely it won't work on some CPUs. I might make a non-optimized generic encoder too if this is a problem
Generic version here :
http://www15.zippyshare.com/v/77085748/file.html

No need to apologize
Surprisingly it seems to be quite fast for me 51x... That's pretty weird for ICC... Maybe it's improvements in libopus that made it faster? Anyways will find out later, for now thanks!

[Gainless]

I apologize for the inconvenience, it as built with all the optimizations so it is likely it won't work on some CPUs. I might make a non-optimized generic encoder too if this is a problem

Generic version here :
http://www15.zippyshare.com/v/77085748/file.html

"Not a valid Win32 application" here with my Windows XP.

This post has been edited by Gainless: Dec 7 2012, 17:31

[eahm]

Anakunda, the last one works thank you.

This post has been edited by eahm: Dec 7 2012, 18:05

[lvqcl]

"Not a valid Win32 application" here with my Windows XP.

Probably it was compiled with MSVC 2012 and so it requires at least MS Vista.

[Anakunda]

Probably it was compiled with MSVC 2012 and so it requires at least MS Vista.

Yes it was

[Gainless]

Probably it was compiled with MSVC 2012 and so it requires at least MS Vista.

Yes it was

Well, then I'll just wait for someone else to recompile it. From what I could read there aren't real quality improvements anyway.

[eahm]

Well, then I'll just wait for someone else to recompile it. From what I could read there aren't real quality improvements anyway.

You can use this one plus the DLLs from opusfile-0.2-win32.zip.


The Anakunda one is really fast encoding.

Pink Floyd - The Wall = Total encoding time: 0:18.047, 269.80x realtime

This post has been edited by eahm: Dec 7 2012, 20:48

[Dynamic]

I don't think fb2k's Converter dialog yet includes an option to automatically resample Opus back to original sample rate by passing that data forward, but it's feasible in future.

What would a valid use case for that be?

Sounds like an option that mostly would allow people to shoot themselves in the foot.

I'm not really claiming a good use case, and it's not worth any major programming time to add a feature, I'm sure, though I think fb2k does already pass on some metadata (at least a flag) to indicate when a lossy operation has occurred so it can 'dither only lossy sources' in the Convert dialogue. I think it also passes on the original bit depth when known.

As an intellectual exercise, of little merit, the only performance-enhancing use-case I've thought of is suboptimal already, but knowledge of the source rate could plausibly reduce the degradation somewhat:

• Imagine it is absolutely necessary to transcode from opus (as our only available source) into, let's say, mp3 for compatibility with a particular device.
• As an aside, I own one for background music purposes in a café, where it sounds pretty good to be fair, though it's about to seem like a pile of $#!† in the words that follow: It's a DAB-One FM/DAB radio with mp3-on-SD-card playback that will play only mp3 files (or mp2 renamed as mp3), but never lossless, and it misbehaves by dipping the volume for a few seconds sporadically if it's fed with an AUX input on the 3.5mm stereo jack, even when it doesn't seem to peak as high as normal mp3 loudness (which I usually set to about 84.5 dB SPL Replay Gain, so not that high).
• If the audio is known to contain nothing above the original sampling rate's Nyquist limit, resampling back to the original sampling rate will usually allow mp3 encoders to be more bitrate-efficient and thus produce lower bitrates for a given VBR quality, or higher quality for a given ABR/CBR bitrate target, thus reducing the transcoding degradation that might occur. I'm not sure whether such inefficiency is common to AAC or Vorbis, however.

I could do that manually, and it's such a rare use case it's not worth any effort to implement just for that. Having opus-incompatible devices, where you might want to play back an opus podcast, say, might be a considerably larger use case, but still not enormous, and easy enough to over-ride manually, unless mass-converting podcasts from numerous sources with varied source sampling rates. The commandline using opusdec fed into LAME then becomes an option to automate the idea.


I'm not suggesting it's an especially useful idea in general, but it would simply mirror the behaviour of the Opusdec commandline decoder (and only in Convert mode, not playback) which will decode to the exact same sample rate as the original, which is naively the 'expected behaviour' of a decoder, sometimes considered a principle of good intuitive software design to make this intuitive behaviour the default (i.e. returning the same number of samples and same file duration) unless it's noticeably harmful (the only harm is a little extra processor load). There is a population even among fb2k users that will expect the naive behaviour when converting and may cause enough annoyance on the forums to encourage its adoption in fb2k, but I somehow doubt it'll be seen as worthwhile.

A non-naive user who understands what's inside the black box will happily over-ride the default if it's unnecessary to resample or deselect any pass-forward option in the Convert dialogue of fb2k. Opusdec's choice is pretty good as a defensive measure against spurious bug reports for 'unexpected behaviour' when you have a good resampler built in.

It's fairly harmless as the resampler has far less distortion than a lossy codec and resampling will mostly happen for CD-sourced material with plenty of bandwidth between 20kHz and 22.05kHz, so in terms of shooting oneself in the foot, I'd argue that it's pretty much a blank round (to take the metaphor too far!). They'll find plenty of ways to hurt their feet, regardless! Xiph.org were also fairly clever about cut-off choices in the antialias filter, IIRC from reading the speex resampler source code they used in libopus, limiting bandwidth degradation from multiple lowpass filters.

This post has been edited by Dynamic: Dec 7 2012, 23:02

[DOS386]

"Mozilla and the Xiph.Org Foundation are pleased to announce the Internet Engineering Task Force (IETF) has standardized Opus as RFC 6716. Opus is the first state-of-the-art, fully Free and Open audio codec ratified by a major standards organization."

Congrats and thanks. :-)

http://wiki.xiph.org/OpusFAQ

Question ^^^ possibly missing:

Do you now deprecate Vorbis in favor of Opus ?

http://opus-codec.org/downloads/ <- binary seems to work

http://code.google.com/p/mulder/downloads/list <- binary is broken: runs but outputs garbage

[Anakunda]

Here is a new opus library version 1.1 alpha announced:

This is an alpha release for the upcoming 1.1 version. Compared to 1.0.2, it includes quality improvements, optimizations, bug fixes, as well as an experimental speech/music detector for mode decisions. All the fixes and improvements from 1.0.2 are also in this release. Quality improvements include unconstrained VBR, a bitrate boost for tonal frames, and improvements to tf estimation, transient detection and dynamic allocation.

Please give it a try

CODE

http://www54.zippyshare.com/v/27314730/file.html

The question is: what's unconstrained VBR. Is it a way closer to true VBR mode like on other encoders?

This post has been edited by Anakunda: Dec 23 2012, 01:55

[saratoga]

The question is: what's unconstrained VBR. Is it a way closer to true VBR mode like on other encoders?

Its another word for quality based VBR basically.

[Anakunda]

The question is: what's unconstrained VBR. Is it a way closer to true VBR mode like on other encoders?

Its another word for quality based VBR basically.

Yup then now to find a way to control the encoder in this mode. So far I've found only bitrate control since opus-tools 0.1.6 still doesnot support any quality-based parameters.

[Seren]

Please give it a try

CODE

http://www54.zippyshare.com/v/27314730/file.html

Thanks! Slightly faster than lvqcl's build (x36 vs x30) but nowhere near as fast as the 51x from your last build which was based on 1.0.2 so I'm assuming it's code changes from 1.0.2-1.1.

[Speckmade]

So far I've found only bitrate control since opus-tools 0.1.6 still doesnot support any quality-based parameters.

It does. For short: The bitrate control is quality-based - at least in this mode.
The encoder tries to keep quality constant and varies bitrate - even average bitrates even between files. So a target bitrate ideally corresponds to a fixed level of quality for a given encoder model.
Remember that the quality parameter of other codecs also (at least often?) translates to a target bitrate. The Opus encoder just saves you the hassle of having different control parameters for unconstrained, constrained VBR and CBR modes. It also hinders confusion from people comparing quality levels between different encoders and/or formats, like expecting Vorbis' q1 sounding competitive to Opus q1. Or, OTOH, it saves the work of trying to make it somehow fit in with the quality levels of other encoders and then having to extend the scale of quality levels far into the negative number range.