"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."
Full announcement at xiph.org/press/2012/rfc-6716 (http://www.xiph.org/press/2012/rfc-6716/)
Yay!
https://hacks.mozilla.org/2012/09/its-opus-...codec-standard/ (https://hacks.mozilla.org/2012/09/its-opus-it-rocks-and-now-its-an-audio-codec-standard/)
In a great victory for open standards, the Internet Engineering Task Force (IETF) has just standardized Opus as RFC 6716.
Opus is the first state of the art, free audio codec to be standardized. We think this will help us achieve wider adoption than prior royalty-free codecs like Speex and Vorbis. This spells the beginning of the end for proprietary formats, and we are now working on doing the same thing for video.
Great news!
The 0.1.5 binary is 1.0.1 RC3, when will we see 0.1.6? Sorry no rush, I am just impatient to have it and test the latest.
Congratulations, Guys, Great job!
The 0.1.5 binary is 1.0.1 RC3, when will we see 0.1.6? Sorry no rush, I am just impatient to have it and test the latest.
1.0.1 isn't the latest. If You want the latest then try an experimental branch.
P.S. Waiting for native Android support .
The 0.1.5 binary is 1.0.1 RC3, when will we see 0.1.6? Sorry no rush, I am just impatient to have it and test the latest.
1.0.1 isn't the latest. If You want the latest then try an experimental branch.
No. When you say latest you mean latest stable.
Congrats and great work guys!
PARTY TIME!
Is storage in the Ogg container format intended to be the go-forward standard for encoding of local files with the Opus codec?
Is storage in the Ogg container format intended to be the go-forward standard for encoding of local files with the Opus codec?
From the link through from the Opus homepage to the Ogg-Opus page, it appears so, and it's quite highly developed, including integration with EBU-R128 loudness normalization specified.
Congratulations to all involved including indeed all the corporate interests who have seen fit to ensure it is an open standard to prevent fragmentation and those such as Mozilla who have contributed employees to work on it.
Hopefully the Mandatory status in WebRTC and the IETF standardization and the number of organisations behind Opus will encourage a wide range of others to implement it as a well-backed standard and very much an open door to numerous use-cases, which need implementing only once for them all.
Is storage in the Ogg container format intended to be the go-forward standard for encoding of local files with the Opus codec?
Well, you could ask Monty about TransOgg
Fire up the cloning vats! (http://lists.xiph.org/pipermail/opus/2012-September/001701.html)
Well, it would be nice if Apple adopts it for iTunes and mobile players, but I have some doubts about that...
Congratulations to the developers - Opus is a real credit to them.
I've just got a question about Opus and low latency applications.
Pardon my ignorance, but I had always been led to believe that in order to be able to use software at low latencies that it was necessary for your operating system to be running a low latency kernel.
I have experimented with audio a fair bit on Linux and what musicians tend to do is to replace the Linux kernel that comes by default with their distribution with a low latency one.
They then tend to install the Jack audio server, which is designed for low latency work.
They also tend to use a dedicated soundcard.
My question is - it is great that Opus offers low latency, but will most users be able to benefit from this functionality if their operating system does not have a low latency kernel?
Also, given the benefits that a low latency kernel can offer why is the standard Linux kernel shipped by major distributions not low latency by default?
Are there any downsides to having a low latency kernel?
Is low latency not enabled by default because the integrated sound modules of a lot of motherboards are not powerful enough to run at low latency?
Do you tend to need a dedicated soundcard to do low latency recording?
I noticed that when recording using Jack at low latency with my motherboard sound I kept getting X runs, but once I started using a dedicated soundcard this problem vanished, so it was as if the integrated sound module was struggling to cope at low latency and the more powerful dedicated card was necessary for such work.
If this is the case could the usefulness of opus as low latency software be hampered somewhat by the kernels that many folks use being compiled without low latency enabled?
Similarly could the usefulness of opus as low latency software be hampered by hardware shortcomings? Dedicated soundcards are very much an item for the enthusiast - the average computer user will rely upon less powerful integrated sound.
If I was to jam with a friend over the internet what prerequisites would we both need?
Fast internet connection?
Low latency kernels?
Dedicated soundcards?
Sorry if I am coming across as a bit negative - just trying to get my head around this low latency stuff as it is confusing me a bit.
I have transcoded my flac files to opus at the default bitrate of 96kbps and am astounded by the quality.
Thank you again to Opus devs for this tremendous piece of software.
My question is - it is great that Opus offers low latency, but will most users be able to benefit from this functionality if their operating system does not have a low latency kernel?
Yes, because latencies add, reducing latency in any component reduces overall latency.
Is storage in the Ogg container format intended to be the go-forward standard for encoding of local files with the Opus codec?
From the link through from the Opus homepage to the Ogg-Opus page, it appears so, and it's quite highly developed, including integration with EBU-R128 loudness normalization specified.
Congratulations to all involved including indeed all the corporate interests who have seen fit to ensure it is an open standard to prevent fragmentation and those such as Mozilla who have contributed employees to work on it.
Hopefully the Mandatory status in WebRTC and the IETF standardization and the number of organisations behind Opus will encourage a wide range of others to implement it as a well-backed standard and very much an open door to numerous use-cases, which need implementing only once for them all.
Ogg and not Matroska ( WebM )?
The 0.1.5 binary is 1.0.1 RC3, when will we see 0.1.6? Sorry no rush, I am just impatient to have it and test the latest.
1.0.1 isn't the latest. If You want the latest then try an experimental branch.
No. When you say latest you mean latest stable.
+1. Where could we get win32 (or win64 if it exists) compile of Opus Encoder 1.0.1 stable?
Ogg and not Matroska ( WebM )?
Opus in Matroska is also being worked on within Xiph.org, but isn't ready today, from what I've read. I suspect that .opus files (i.e. opus in ogg container) will be the typical form of file-based Opus audio-only playback, just as .ogg is the typical form of file-based Vorbis audio-only playback.
+1. Where could we get win32 (or win64 if it exists) compile of Opus Encoder 1.0.1 stable?
The version of 0.1.5 for the opus-tools bundle might be misleading a few people.
It includes an encoder which reports version libopus 1.0.1-rc3 library, which being a release candidate should be pretty stable.
C:\Users\Me>opusenc -V
opusenc opus-tools 0.1.5 (using libopus 1.0.1-rc3)
Copyright (C) 2008-2012 Xiph.Org Foundation
Essentially, little changed except removal of the -voice and -music modes which weren't useful and other things that simply made building the binary easier, AFAICT.
Recent versions including the free reference implementation have all been tuned to a very good performance, though moderate improvements on music and probably problem sample performance will doubtless be made over time. The days of naive reference encoders (like early mp3 encoders) seem to have passed.
If I understand correctly, these are the problems (https://wiki.xiph.org/MatroskaOpus) they're still facing with Matroska.
If I understand correctly, these are the problems (https://wiki.xiph.org/MatroskaOpus) they're still facing with Matroska.
This thread (http://lists.matroska.org/pipermail/matroska-devel/2011-December/004153.html) could be also of interest. IIUC, Limitations in the Matroska container itself is what blocked Opus support.
I guess this is the time and place for the big "Thank You!". –
I'm particularly grateful for everyone involved in pushing Opus through the standardisation process.
I hope it is now going to be as successful as it deserves. – To world domination! ;-)
Lets hope that projects like Daala can reach something similar in the future.
I just noticed, the homepage of Opus (http://opus-codec.org/) says "Bit-rates from 6 kb/s to 510 kb/s", shouldn't it be 6 - 512?
I just noticed, the homepage of Opus (http://opus-codec.org/) says "Bit-rates from 6 kb/s to 510 kb/s", shouldn't it be 6 - 512?
Nope, it's really 510Kbps, thanks to how Opus represent the frame length. You can read more on here (http://tools.ietf.org/html/rfc6716#section-3.2.1).
I just noticed, the homepage of Opus (http://opus-codec.org/) says "Bit-rates from 6 kb/s to 510 kb/s", shouldn't it be 6 - 512?
Nope, it's really 510Kbps, thanks to how Opus represent the frame length. You can read more on here (http://tools.ietf.org/html/rfc6716#section-3.2.1).
Thank you, so then everyone else must fix this, starting from Mozilla https://hacks.mozilla.org/2012/09/its-opus-...codec-standard/ (https://hacks.mozilla.org/2012/09/its-opus-it-rocks-and-now-its-an-audio-codec-standard/). Come on, partner and supporter.
Those who'd like to see Opus being supported on Windows Phone, please vote (http://www.vault-tec.info/2012/09/opus-codec-support-in-windows-phone.html) for it!
If I understand correctly, these are the problems (https://wiki.xiph.org/MatroskaOpus) they're still facing with Matroska.
From that link:
Seeking in Opus files requires a pre-roll (recommended to be at least 80 ms). However, currently Matroska requires its index entries to point directly to the data whose timestamp matches the corresponding seek point, not some place arbitrarily before that timestamp. These two requirements are incompatible, and mean that seeking in Opus will be broken in all existing Matroska software. In particularly unlucky cases (e.g., around a transient), playing back audio decoded without any pre-roll can produce extremely loud (possibly equipment-damaging) results. We need a new element to signal this, e.g. Track::TrackEntry::PreRoll.
I believe the pre-roll is essential because of the SILK layer's predictors needing time to converge based on previous samples, but wouldn't matter in CELT-only (MDCT only) mode. Without this, excessive volume bursts may occur if SILK is active, so the BEST solution is a PreRoll (decoding but not playing 80 ms of audio or more to make it converge). Presumably if the PreRoll isn't accessible it should be acceptable (and mandatory) to mute the audio for 80ms (or follow a suitable fade-in curve).
I believe the pre-roll is essential because of the SILK layer's predictors needing time to converge based on previous samples, but wouldn't matter in CELT-only (MDCT only) mode. Without this, excessive volume bursts may occur if SILK is active, so the BEST solution is a PreRoll (decoding but not playing 80 ms of audio or more to make it converge). Presumably if the PreRoll isn't accessible it should be acceptable (and mandatory) to mute the audio for 80ms (or follow a suitable fade-in curve).
MDCT needs pre-roll too. Somewhat less in the insane worse case because the maximum inter-frame predictive gain is lower, but 80ms doesn't get you convergence in the insane worse case anyways, it gets you convergence that should be quite good on average, and at least not break speakers (or the listener) in the worst case. There is also the matter of initial skip.
These sorts of issues aren't entirely unique to Opus. Video codecs with rolling intra have this problem too (e.g. h264 can be encoded this way). The solution of the mkv container and common applications is to get it wrong and display corrupted output, both for cropped files and seeking. This is even less acceptable for Opus because the corruption could potentially damage equipment or hurt the users hearing (at least for some insane inputs) and because it will be at least a small issue on almost all files. The Matroska developers seemed uninterested before in doing anything about it. There also appears to be no general mechanism for making sample accurate files with Matroska, or at no tools I can find implement it with Vorbis, so it seems true gaplessness would require cross-fades.
Between those concerns, the general lack of Matroska support in audio tools (as opposed to A+V) and devices (for a long time the only complete MKV libraries had lots of dependencies and were C++ only, both contraindicated for embedded devices), and the lack of any substantial material benefit otherwise... it hasn't really been a priority, at least not mine. Google has already nixed using Opus with "WEBM' because they, rightfully, don't want to complicate compatibility. Though people interested in muxing opus with VP8— e.g. to seralize webrtc streams— will surely get it worked out eventually.
Thanks for the information & correction, NullC. I think I've had the equivalent video problem a few times. I think I need to look over the Opus/CELT info again.
I don't know how long ago they started but Absolute Radio streams in Opus (Trial):
http://www.absoluteradio.co.uk/listen/labs.html#opus (http://www.absoluteradio.co.uk/listen/labs.html#opus)
I wish they had 48kbps and 64kbps instead of 128kbps though. I'll email them.
Are they going to release the 1.0.1 binaries for Windows so we can do more testing? If not, can at least anyone say it's not going to be any different than 1.0.1 RC3?
Thanks.
I don't know how long ago they started but Absolute Radio streams in Opus (Trial):
http://www.absoluteradio.co.uk/listen/labs.html#opus (http://www.absoluteradio.co.uk/listen/labs.html#opus)
I wish they had 48kbps and 64kbps instead of 128kbps though. I'll email them.
Also: the ar24 stream reports
Encoded with libopus 1.0.1-rc2
ENCODER=opusenc from opus-tools 0.1.4
I would assume they may get better results with one of the experimental psychoacoustic tunings discussed here.
I have to admit I was a little stunned by the bitrate options they provide.. 24Kbps or 128Kbps.. At 128Kbps they can pretty much use any modern codec and no one could really tell.. I figured they would shoot for at least 32kbps or 48kbps.. They're trying to encode full band music at 24kbps, and while I was impressed with what opus accomplishes there, to the non-technically inclined they'll just think it sounds bad and not appreciate how good it sounds in relation to how low that bitrate is. We're talking about piping it over a 28.8kbps modem connection in real time here!!
I would assume they may get better results with one of the experimental psychoacoustic tunings discussed here.
If they were to use 48 to 64 kbps (or maybe 80 to 96 kbps), possibly the experimental psy tunings would help, as I believe they're focused on the CELT mode, and the full-range bass would also be welcome.
It seems likely that 128 kbps is going to be pretty excellent / near transparent in either mode and hard to distinguish between main or experimental branch in normal listening.
The 24 kbps stream (Super Wideband at 24 kHz sampling rate, I think) is below the level where CELT dominates (I think most of the experimental psychoacoustic tunings have been developed for the CELT layer) and instead I believe Opus always uses Hybrid mode with SILK encoding the signal up to 8kHz and CELT encoding the spectrum between 8-12 kHz, I believe, so I don't expect there would be much difference between main and experimental there either.
I guess the modes chosen are based on use-cases. Unlikely to include a PSTN modem, but maybe includes cellular streaming to mobile devices at sporadic and variable rates of GPRS, which is often about 28 kbps in rural areas of the UK on some networks.
Absolute Radio labs' 128kbps Opus stream sounds excellent but at times the 24 kbps Opus was really lacking in bass, I believe - I compared to their AAC+SBR 24kbps stream. On the other hand, at times Opus sounded like it had less high-frequency harshness than the AAC+SBR version but also at times it had less HF sparkle due to its presumably 12kHz lowpass. For a speech-oriented encoder setting, Opus24 is very music-friendly. I'd probably pick the AAC+SBR at 24kbps, but the artificial-sounding nature of it might grate with me eventually and I might choose Opus instead. I know there's an adaptable HF filter in the SILK layer, so presumably its effect will vary with the audio source.
It would be lovely if bass could be preserved by Opus when music is detected at 24 kbps without losing too much fidelity due to the bits used there.
As Opus is defined by the decoder, which seems to simply add the SILK and CELT decodes, I'm not sure if there might be scope in hybrid mode to choose to use CELT to encode the area below the high-pass filter that removes non-speech background noise from the SILK layer but might be amenable to encoding using longish blocks.
I would assume they may get better results with one of the experimental psychoacoustic tunings discussed here.
If they were to use 48 to 64 kbps (or maybe 80 to 96 kbps), possibly the experimental psy tunings would help, as I believe they're focused on the CELT mode, and the full-range bass would also be welcome.
It seems likely that 128 kbps is going to be pretty excellent / near transparent in either mode and hard to distinguish between main or experimental branch in normal listening.
The 24 kbps stream (Super Wideband at 24 kHz sampling rate, I think) is below the level where CELT dominates (I think most of the experimental psychoacoustic tunings have been developed for the CELT layer) and instead I believe Opus always uses Hybrid mode with SILK encoding the signal up to 8kHz and CELT encoding the spectrum between 8-12 kHz, I believe, so I don't expect there would be much difference between main and experimental there either.
I guess the modes chosen are based on use-cases. Unlikely to include a PSTN modem, but maybe includes cellular streaming to mobile devices at sporadic and variable rates of GPRS, which is often about 28 kbps in rural areas of the UK on some networks.
Absolute Radio labs' 128kbps Opus stream sounds excellent but at times the 24 kbps Opus was really lacking in bass, I believe - I compared to their AAC+SBR 24kbps stream. On the other hand, at times Opus sounded like it had less high-frequency harshness than the AAC+SBR version but also at times it had less HF sparkle due to its presumably 12kHz lowpass. For a speech-oriented encoder setting, Opus24 is very music-friendly. I'd probably pick the AAC+SBR at 24kbps, but the artificial-sounding nature of it might grate with me eventually and I might choose Opus instead. I know there's an adaptable HF filter in the SILK layer, so presumably its effect will vary with the audio source.
It would be lovely if bass could be preserved by Opus when music is detected at 24 kbps without losing too much fidelity due to the bits used there.
As Opus is defined by the decoder, which seems to simply add the SILK and CELT decodes, I'm not sure if there might be scope in hybrid mode to choose to use CELT to encode the area below the high-pass filter that removes non-speech background noise from the SILK layer but might be amenable to encoding using longish blocks.
I think the only way to Opus be competitive on HE-AACv2 with less than 32Kbps is using either mono or intesity stereo. Opus has something similar to Spectral Band Replication from AAC (it's called Band Folding and it's more efficient since it uses the unique design of the codec to reconstructed higher frequencies; see more here: http://people.xiph.org/~xiphmont/demo/celt/demo.html) (http://people.xiph.org/~xiphmont/demo/celt/demo.html)), so the bitrate range where HE-AAC sounds good (32~64Kbps) Opus will probably sound even better (a.k.a. less artifacts), but Opus doesn't have anything special on spatial encoding to compete with Parametrical Stereo, except maybe the intensity stereo mode. I don't know if Opus automatically switch to intensity stereo on such low bitrates, so maybe mono will be better.
Anyway, we shouldn't forget that HE-AAC and HE-AACv2 (well, even AAC-LC) has much more delay than Opus (it's orders of magnitude), so it still has it's on merits unless USAC comes with a low delay mode that still uses SBR+PS.
There is also a commercial competitor named AAC-ELD (http://www.full-hd-voice.com/en/technologies.html) (Enhanced Low Delay) to Opus.
AAC-ELD uses a low delay modifications of SBR (LD SBR) and Parametric Stereo which is derived from MPEG Surround (LD MS).
LD SBR has delay of 33.7 ms and LD SBR + LD MS - 37.7 ms which is actually 1.5x higher than LD-AAC (no SBR, no MS) or Opus with 20-25 ms of delay.
Not sure about USAC. It uses SBR and MS too. USAC's speech encoder is AMR-WB+ which also has a high delay.
Add to it that low delay comes at high cost of a quality drop. http://www.hydrogenaudio.org/forums/index....st&p=772068 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=90824&view=findpost&p=772068)
I think they did read my email, they took off 128kbps and add 64kbps and 96kbps
http://www.absoluteradio.co.uk/listen/labs.html#opus (http://www.absoluteradio.co.uk/listen/labs.html#opus)
Here you can compare it with the other codecs: http://www.absoluteradio.co.uk/listen/on-other-devices.html (http://www.absoluteradio.co.uk/listen/on-other-devices.html)
I think they did read my email, they took off 128kbps and add 64kbps and 96kbps
Just installed Firefox 15 on my Mum's PC and noticed the same thing. Absolute describe 24 kbps (mono) as Low Bitrate, 64kbps as Standard Bitrate and 96 kbps as High Bitrate, which in the context of Opus seems appropriate.
Both 64 and 96 kbps streams sound great, though I'd love to be able to listen through fb2k as well because the Classic Rock station there in particular plays a few songs with hard-panned instruments that sound like they're inside my ears on headphones so a crossfeed or speakers simulation plugin would help.
BTW, I also notice that the Examples (http://opus-codec.org/examples/) pages of opus-codec.org now includes a cool demo of
bitrate-scalability, with visual dials & readouts to show the changing bitrate, stereo mode and audio bandwidth of the seamlessly changing Opus stream (and I checked the source, it is playing Opus, and uses scripting to coordinate the readouts). I believe this was the
8-64kbps bitrate sweep demo of the Dave Matthews Band codec killer excerpt played part-way through Jean-Marc Valin's Linuxconf Australia presentation (http://opus-codec.org/presentations/) "The Swiss Army Knife of audio codecs", but now you can hear it in native Opus, being handled properly by Firefox.
Both 64 and 96 kbps streams sound great, though I'd love to be able to listen through fb2k as well
???
File > Add location > http://icecast-beta.timlradio.co.uk:8000/ac96.opus (http://icecast-beta.timlradio.co.uk:8000/ac96.opus) > OK
Thanks. Had been getting unsupported format or corrupt error. Must have somehow got two version of fb2k installed, and was using wrong one (v1.1.12), possibly on different User Accounts. Works perfectly now.
Hi all
Today foobar2k released the free encoder pack containing opusenc already which made me try out this.
As I don't understand too much spectral graphs I see the high cutoff range is set to 20kHz by 96kbps which makes me think the codec's ambitions are really high, and I'm really impressed about the sound
I have several more questions:
Is the average vbr mode fixed to 96kbps or can it be increased yet higher?
What does the complexity option affect when not the bitrate (what's the advantage of complexity <10)?
What bitrates of Vorbis, AAC and MP3 (all in VBR modes) are counterparts to Opus at complexity 10 (approximately) as for sound quality?
Are Opus's chances to become more standard supported by wide range of hardware players higher than Voirbis's?
Keep on developing this great codec
Today foobar2k released the free encoder pack containing opusenc already which made me try out this.
TWIMC: this pack contains
opusenc opus-tools 0.1.5 (using libopus 1.0.1-rc3) The same exe is available here: https://ftp.mozilla.org/pub/mozilla.org/opu...0.1.5-win32.zip (https://ftp.mozilla.org/pub/mozilla.org/opus/win32/opus-tools-0.1.5-win32.zip)
Is there a binary of Opus Tools using libopus 1.0.1 final?
@Anakunda:
Opus is designed with realtime communications in mind. The main targets are VoIP (http://en.wikipedia.org/wiki/Voip) (phone calls, player communication in multiplayer games) and even realtime networked audio over internet (if there is enough low latency).
But due to the way it is designed, it scales very well from very low bitrate for voice communication, to full bandwith music, at bitrates that compete and even surpass Vorbis (http://www.opus-codec.org/comparison/). As such, it is also interesting to use it for audio storage.
As for the specific questions you make about the encoder binary/settings, the opusenc help page (https://mf4.xiph.org/jenkins/view/opus/job/opus-tools/ws/man/opusenc.html) might help.
Finally, being an RFC (http://en.wikipedia.org/wiki/Request_For_Comments) means that it is in a position to become an internet standard (and, for example, Mozilla Firefox already supports it)
[JAZ], What are you talking about?
Is there a binary of Opus Tools using libopus 1.0.1 final?
No there isn't yet, last one for Windows is RC3.
Is there a binary of Opus Tools using libopus 1.0.1 final?
https://code.google.com/p/mulder/downloads/....2012-09-22.zip (https://code.google.com/p/mulder/downloads/detail?name=opus-tools.2012-09-22.zip)
Both 64 and 96 kbps streams sound great, though I'd love to be able to listen through fb2k as well
???
File > Add location > http://icecast-beta.timlradio.co.uk:8000/ac96.opus (http://icecast-beta.timlradio.co.uk:8000/ac96.opus) > OK
It's worth to try an experimental branch as it has an unconstrained VBR and quality improvements. https://people.xiph.org/~greg/opus-tools_exp_tfsel5.zip (https://people.xiph.org/~greg/opus-tools_exp_tfsel5.zip)
Probably 1.1 beta will be realesed in a near future.
Is there a binary of Opus Tools using libopus 1.0.1 final?
https://code.google.com/p/mulder/downloads/....2012-09-22.zip (https://code.google.com/p/mulder/downloads/detail?name=opus-tools.2012-09-22.zip)
These builds are based on 1.0.1 from 0.1.5 binaries...so, 1.0.1 RC3, not the final 1.0.1
Again, can anyone confirm there are no changes between 1.0.1 RC3 and 1.0.1?
Thank U for the updated encoder
[JAZ], What are you talking about?
If it wasn't obvious, I was replying to the first anakunda's post , i .e post 40 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=96954&view=findpost&p=810169).
As I don't understand too much spectral graphs I see the high cutoff range is set to 20kHz by 96kbps which makes me think the codec's ambitions are really high, and I'm really impressed about the sound
About opus and lowpass. (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=96571&view=findpost&p=805338)
Is the average vbr mode fixed to 96kbps or can it be increased yet higher?
VBR goes up to ~510-513 kbps if You wish.
What does the complexity option affect when not the bitrate (what's the advantage of complexity <10)?
Less complexity, higher speed, lower quality.
What bitrates of Vorbis, AAC and MP3 (all in VBR modes) are counterparts to Opus at complexity 10 (approximately) as for sound quality?
Opus is clearly superior at 64kbps. It's hard to judge which is better between AAC, Vorbis and Opus at 96 kbps and higher as quality is already pretty good. A future public tests should clear this.
I tried to compile 64bit version of the encoder . Can anybody benchmark it for sppeed please?
http://www.datafilehost.com/download-7c7892b0.html
VBR goes up to ~510-513 kbps if You wish.
I have overlooked the options syntax but didnot find the quality factor option, which one is that?
(unconstrained) VBR is a default mode.
--bitrate 128 is unconstrained VBR that yields 128 kbps on a big amount of files.
Is there a binary of Opus Tools using libopus 1.0.1 final?
https://code.google.com/p/mulder/downloads/....2012-09-22.zip (https://code.google.com/p/mulder/downloads/detail?name=opus-tools.2012-09-22.zip)
These builds are based on 1.0.1 from 0.1.5 binaries...so, 1.0.1 RC3, not the final 1.0.1 Again, can anyone confirm there are no changes between 1.0.1 RC3 and 1.0.1?
BUILD_INFO.txt says it's 1.0.1 final.
I can't tell precisely with this build because the Tool line shows "libopus 2012-09-22: (std) and "libopus 2012-09-22-exp_analysis" (ea7) but the one they took the source from, 0.1.5 from the official website, shows "libopus 1.0.1-rc3".
0.1.5 is the version of Opus_Tools (opusenc, opusdec, ...), not version of the Opus codec library.
I've got this wish if some developer could write a directshow filter for opus...I find this ideal codec and bitrates for secondary tracks (commentary and similar)....
http://www.xiph.org/dshow/ (http://www.xiph.org/dshow/)
What is the higest input bit depth?
(http://content.screencast.com/users/nobody5/folders/Snagit/media/dd13aa73-30fc-4ce3-9b70-c2902ba822ea/Opus.png)
I've got this wish if some developer could write a directshow filter for opus...I find this ideal codec and bitrates for secondary tracks (commentary and similar)....
AFAIK recent ffmpeg can be built with libopus support enabled, and so does LAVFilters.
Try http://xhmikosr.1f0.de/lavfilters/ (http://xhmikosr.1f0.de/lavfilters/) or something.
Official binary at http://code.google.com/p/lavfilters/ (http://code.google.com/p/lavfilters/downloads/list) is using a bit older version of ffmpeg which doesn't support opus yet.
What is the higest input bit depth?
foobar2000 already has built-in preset for Opus.
The highest input bit depth is 32 bits for Opus.
Anakunda, from your screenshot, you're asking for a .ogg filename extension. The Ogg Opus mapping (http://wiki.xiph.org/OggOpus) page recommends use of the .opus extensions
Content Type
The recommended mime-type for Ogg Opus files is audio/ogg, defined in RFC 5334.
If more specificity is desired, one can distinguish Opus files as 'audio/ogg; codecs=opus'.
The recommended filename extension for Ogg Opus files is .opus.
For future compatibility, especially under Windows, it looks inadvisable to use .ogg, which tends to invoke Vorbis-compatible decoders that might not be upgraded to include Opus support. fb2k's built in Opus preset seems like the best option unless you're doing anything fancy or testing experimental encoders.
(edit: this is still the recommendation in the IETF Draft (http://tools.ietf.org/html/draft-terriberry-oggopus-01#section-8)that supercedes the page quoted above)
Also, --vbr and --comp 10 are the default settings. There's no need to add them.
The highest input bit depth is 32 bits for Opus.
AFAIK, While Opus can technically take 32 bitdepth as input (after all, it's all float internally), opusenc only accepts up to 24 integer bitdepth.
Here is the error message to confirm:
ERROR: Wav file is unsupported subformat (must be 8,16, or 24 bit PCM
or floating point PCM
Interesting, but foobar2000 sends either 8, 16, 24 bit integer or (32-bit) floating point PCM to encoders.
BTW, I also notice that the Examples (http://opus-codec.org/examples/) pages of opus-codec.org now includes a cool demo of bitrate-scalability, with visual dials & readouts to show the changing bitrate, stereo mode and audio bandwidth of the seamlessly changing Opus stream (and I checked the source, it is playing Opus, and uses scripting to coordinate the readouts). I believe this was the 8-64kbps bitrate sweep demo of the Dave Matthews Band codec killer excerpt played part-way through Jean-Marc Valin's Linuxconf Australia presentation (http://opus-codec.org/presentations/) "The Swiss Army Knife of audio codecs", but now you can hear it in native Opus, being handled properly by Firefox.
I found that this played in Opera (without the required gstreamer plugins to play Opus) so I looked at the source again, and I was either mistaken, or they changed it for compatibility. The file is sweep.ogg and it's an OGG file containing Vorbis at 330kbps, clearly transcoded to very high quality Vorbis for compatibility with browsers that don't support opus yet who would like to heard the demo. This is a mere technical point, as the sound quality is bound to be essentially identical to opus directly in the 8-64kbps range. Of course, this page does not at present provide you with an opus file to test seamless bitrate and mode-changing in your opus decoder. I think there's one provided in the test vectors (http://opus-codec.org/docs/) for that purpose.
I found that this played in Opera (without the required gstreamer plugins to play Opus) so I looked at the source again, and I was either mistaken, or they changed it for compatibility. The file is sweep.ogg and it's an OGG file containing Vorbis at 330kbps, clearly transcoded to very high quality Vorbis for compatibility with browsers that don't support opus yet who would like to heard the demo. This is a mere technical point, as the sound quality is bound to be essentially identical to opus directly in the 8-64kbps range. Of course, this page does not at present provide you with an opus file to test seamless bitrate and mode-changing in your opus decoder. I think there's one provided in the test vectors (http://opus-codec.org/docs/) for that purpose.
Yeah, it's Vorbis encoded, I simply demuxed http://people.xiph.org/~tterribe/tmp/sweep.ogv (http://people.xiph.org/~tterribe/tmp/sweep.ogv) and quickly threw together the demo. For compatibility reasons it would also need an AAC or MP3 version for the Ogg impaired browsers, but I'm not sure the original Opus file is still around somewhere and it smells fishy to transcode Opus to Ogg to MP3 ;-)
[quote name='Anakunda' date='Sep 30 2012, 20:02' post='810211']
I tried to compile 64bit version of the encoder . Can anybody benchmark it for sppeed please?
http://www.datafilehost.com/download-7c7892b0.html
Just a quick bench with 32-bit vs 64-bit. Source file is .WAV,
Ram Records Drum & Bass Annual 2011 CD2, runtime 45min 12sec:
32-bit:D:\work\00_audio_work\TEMP>opusenc.exe test.wav test32.opus
Encoding using libopus 1.0.1-rc3 (audio)
-----------------------------------------------------
Input: 44.1kHz 2 channels
Output: 2 channels (2 coupled)
20ms packets, 96kbit/sec VBR
Preskip: 356
[/] 00:45:08.11 52.1x realtime, 94.17kbit/s
Encoding complete
-----------------------------------------------------
Encoded: 45 minutes and 12.36 seconds
Runtime: 52 seconds
(
52.16x realtime)
Wrote: 32157157 bytes, 135618 packets, 2715 pages
Bitrate: 94.1663kbit/s (without overhead)
Rate range: 1.2kbit/s to 166kbit/s
(3 to 415 bytes per packet)
Overhead: 0.717% (container+metadata)
64-bit:D:\work\00_audio_work\TEMP>opusenc.exe test.wav test64.opus
Encoding using libopus 1.0.1 (audio)
-----------------------------------------------------
Input: 44.1kHz 2 channels
Output: 2 channels (2 coupled)
20ms packets, 96kbit/sec VBR
Preskip: 356
[/] 00:44:56.84 64.2x realtime, 94.17kbit/s
Encoding complete
-----------------------------------------------------
Encoded: 45 minutes and 12.36 seconds
Runtime: 42 seconds
(
64.58x realtime)
Wrote: 32157152 bytes, 135618 packets, 2715 pages
Bitrate: 94.1663kbit/s (without overhead)
Rate range: 1.2kbit/s to 166kbit/s
(3 to 415 bytes per packet)
Overhead: 0.717% (container+metadata)
EDIT: My system is Win7 x64, Core i5-750@stock clocks
Just a quick bench with 32-bit vs 64-bit. Source file is .WAV,
Ram Records Drum & Bass Annual 2011 CD2, runtime 45min 12sec:
Thanks for the feedback
The 0.1.5 binary is 1.0.1 RC3, when will we see 0.1.6? Sorry no rush, I am just impatient to have it and test the latest.
1.0.1 isn't the latest. If You want the latest then try an experimental branch.
No. When you say latest you mean latest stable.
+1. Where could we get win32 (or win64 if it exists) compile of Opus Encoder 1.0.1 stable?
Here's a build of opus-tools built against 1.01
https://www.dropbox.com/s/kkv7qiug2szcowf/opus-tools-x64.zip (https://www.dropbox.com/s/kkv7qiug2szcowf/opus-tools-x64.zip)
https://www.dropbox.com/s/ccrxcqh3i5rlhzl/opus-tools.zip (https://www.dropbox.com/s/ccrxcqh3i5rlhzl/opus-tools.zip)
RareWares added an SSE optimized 1.0.1 build as well:
http://www.rarewares.org/opus.php (http://www.rarewares.org/opus.php)
My god!
opusinfo.exe - 63488b (non-SSE), 559616b (SSE)
opusenc.exe - 351744b (non-SSE), 721408b (SSE)
opusdec.exe - 333312b (non-SSE), 738816b (SSE)
It requires that much code to optimize for SSE?!
[edit]The opus-tools version number is missing upon opus***.exe -V[/edit]
My god!
opusinfo.exe - 63488b (non-SSE), 559616b (SSE)
opusenc.exe - 351744b (non-SSE), 721408b (SSE)
opusdec.exe - 333312b (non-SSE), 738816b (SSE)
It requires that much code to optimize for SSE?!
Such a sizes is normal, when you link static Microsoft(or other) C runtime libraries and possibly other runtimes. The tools code self is only a fragment of the overall binaries.
Well, it would be nice if Apple adopts it for iTunes and mobile players, but I have some doubts about that...
Apple already has HE-AAC as their version of an efficient codec. They are not very welcoming to outsider codecs like this one. I would be happy to adopt Opus when it has more native support though.
What is the higest input bit depth?
foobar2000 already has built-in preset for Opus.
When encoding with Opus in foobar2000, what is the default export sampling rate? opusenc.exe defaults to 48 KHz so I assume it uses this. If the input is 24-bit 96 KHz is that would I'd end up with? How would I change bit depth and sampling rates in foobar?
What is the higest input bit depth?
foobar2000 already has built-in preset for Opus.
When encoding with Opus in foobar2000, what is the default export sampling rate? opusenc.exe defaults to 48 KHz so I assume it uses this. If the input is 24-bit 96 KHz is that would I'd end up with? How would I change bit depth and sampling rates in foobar?
It should use whatever sample rate you feed it. IIRC opusenc does this as well.
When encoding with Opus in foobar2000, what is the default export sampling rate? opusenc.exe defaults to 48 KHz so I assume it uses this. If the input is 24-bit 96 KHz is that would I'd end up with? How would I change bit depth and sampling rates in foobar?
[/quote]
It should use whatever sample rate you feed it. IIRC opusenc does this as well.
[/quote]
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.?
Aw, I messed up the quoting didn't I? How do I not do that?
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.
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.
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).
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://www.datafilehost.com/download-a36da263.html)
http://www22.zippyshare.com/v/12534750/file.html (http://www22.zippyshare.com/v/12534750/file.html)
opusenc file.wav:
(http://i50.tinypic.com/2vtctip.png)
and with foobar2000:
(http://i48.tinypic.com/mtm1c8.png)
Also getting ^this^
You are right eahm, seren. there's missing dll, please redownload
http://www13.zippyshare.com/v/63740765/file.html (http://www13.zippyshare.com/v/63740765/file.html)
You are right eahm, seren. there's missing dll, please redownload
http://www13.zippyshare.com/v/63740765/file.html (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).
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 (http://www15.zippyshare.com/v/77085748/file.html)
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 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.
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 (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!
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 (http://www15.zippyshare.com/v/77085748/file.html)
"Not a valid Win32 application" here with my Windows XP.
Anakunda, the last one works thank you.
"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.
Probably it was compiled with MSVC 2012 and so it requires at least MS Vista.
Yes it was
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.
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 (http://www.hydrogenaudio.org/forums/index.php?showtopic=86580&st=475&p=814565&#entry814565) plus the DLLs from opusfile-0.2-win32.zip (http://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
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.
"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 (http://wiki.xiph.org/OpusFAQ)
Question ^^^ possibly missing:
Do you now deprecate Vorbis in favor of Opus ?
http://opus-codec.org/downloads/ (http://opus-codec.org/downloads/) <- binary seems to work
http://code.google.com/p/mulder/downloads/list (http://code.google.com/p/mulder/downloads/list) <- binary is broken: runs but outputs garbage
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
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?
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.
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.
Please give it a try 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.
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.
Just encode a few tracks and see how bitrate goes down and up.