Opus 1.1 Released 62
New submitter rvalles writes "Xiph.org just released a major update to their Opus audio codec. Opus 1.1 offers major improvements over last year's 1.0.2 release. Opus is a general-purpose, very flexible, open and royalty-free audio codec that offers low-latency and high quality/bitrate, incorporating technology from Skype's SILK codec and Xiph.Org's CELT codec. Its first release beat everything else last year at 64kbit/s in a listening test held at HydrogenAudio."
Nice, impressive achievement (Score:1)
A quick question: Is this supported in hardware (to prolong battery life) in mobile devices that can play audio?
I expect more generalised hardware (i.e., programmable DSPs) can be made to support it on the DSP that is present in the audio/video decode functional blocks of the SoC.
Re:Nice, impressive achievement (Score:5, Informative)
Depends on what mobile device? The reference code has extensive ARM optimizations, that's in fact one of the main improvements in 1.1 And yes, it can be accelerated with a programmable DSP if present, IIRC there's some support for C55x in the same reference code.
Audio decoding is fast enough on modern ARM SoC that dedicated hardware isn't strictly needed to get good battery life.
Re:Nice, impressive achievement (Score:5, Informative)
The thing about audio encode/decode is that its relatively low MIPS - with todays mobile CPUs its almost not worth the complexity to offload it to DSP. During a call your CPU has to stay awake anyway and drain battery, there is very little wattage saving moving it to DSP. It would only make sense if you are dealing with multiple, and i mean more than 2 simultaneous encoded streams ( decode is cheap ). The story was different a few years ago when the dominant CPU was ARM9 running in a 150-200 mhz range, where audio codec easily chewed up 50% or more available MIPS.
Video encoding is a whole different matter of course.
Re:Nice, impressive achievement (Score:4, Informative)
Also note - any sort of offload will add some latency, because you have to have a buffer between DSP and main CPU for them to run asynchronously. That latency is often undesireable.
Re:Nice, impressive achievement (Score:4, Informative)
You didnt get it - the speech codecs encode data at 10 millisecond or 20 millisecond intervals, depending. Sometimes 50-60 millisecond multiframe packets. For the two cores to work asynchronously, you have to hand over the minimum of one frame, for efficiency's sake preferrably more. So minimum incurred latency is at least one frame or 10 milliseconds - normally more in offloads.
Compatibility (Score:5, Funny)
So is this backwards compatible with my existing Monster Cables or do I have to buy new ones?
Re:Compatibility (Score:5, Funny)
So is this backwards compatible with my existing Monster Cables or do I have to buy new ones?
You will just need to update the firmware on your cables if you want to maintain optimal RDF (reality distortion field).
Re: (Score:2)
Re:Oh lookie (Score:5, Informative)
AMR is pretty widely used as a voice codec, Ogg is used in most major AAA games, and as for Opus/SILK, you might have used Skype before...
Re: (Score:2)
>I.e. Apple and Microsoft shitheads
Microsoft was a major contributor to Opus through Skype, both with code and by providing their patents royalty free.
Re:Oh lookie (Score:5, Informative)
Sure, this was originally Skype, but Microsoft has continued to work with us even after acquiring Skype.
Re: (Score:2)
INFO: Even BlackBerry Z10 phones (and up) supports MP3, Ogg and FLAC natively.
Re: (Score:1)
No it will be ignored by all those that like being fucked with closed ecosystems.
I.e. Apple and Microsoft shitheads. Everybody else will do fine.
Aww...ain't you a cute Linuxboy. ;)
Already has good adoption (Score:5, Informative)
Opus wasn't designed for audio files, but for streaming audio. In that realm it's adoption looks very promising. It has already been integrated into the Skype codebase and will likely be used in the next major release of Skype. It is also one of two mandatory audio codecs for in the draft for WebRTC, which is a new standard for browser-based chatting.
Re: (Score:2)
Why would browser-based chat need audio streaming?
Re: (Score:1)
So you can have a voice chat?
Re: (Score:2)
Then use a VOIP solution.
Re: (Score:1)
WebRTC is a VOIP solution. You seem to be the only one pigeonholing it as a text-only chat.
Re: (Score:2)
I apologize. I was going off of:
"WebRTC, which is a new standard for browser-based chatting."
Blame pavon. [slashdot.org]
Web chatting is just that - chat. Thus my confusion.
Re: (Score:1)
"Web chatting" has included voice and video for more than a decade.
Re: (Score:3)
Because not all of us can read lips?
Re: (Score:2)
What does lip reading have anything to do with chat (ie, text communication)?
Re: (Score:1)
Since when is WebRTC text-only? From Google's original announcement [w3.org]:
Today, Google made available WebRTC, an open source software package for real-time voice and video on the web that we will be integrating in Chrome.
Re: (Score:2)
First time I've seen that, I apologize. I was going off of:
"WebRTC, which is a new standard for browser-based chatting."
Web chatting is just that - chat. Thus my confusion.
Re: (Score:2)
What does lip reading have anything to do with chat (ie, text communication)?
Somehow you seem to have come to the conclusion that "chat" means "digital communication using text." It doesn't. The verb "chat" predates digital text communication by a very, very long time.
Re: (Score:2)
But it's usage on computers has, for the 20 or so years before VOIP was common, been text-only. Witness items such as IRC, ICQ, AIM, etc.
Anyway I did not realize WebRTC was not actually one of these kinds of things, pavon incorrectly described "real-time audio and video" as "web chat."
Re: (Score:1)
Skype has been a "voice chat" program for going on 10 years. And, yes, it was called as such back in 2003.
Re: (Score:1)
pavon did not "incorrectly describe" anything. You formed an incorrect definition of what "chat" means, which led you to misinterpret what he said. The fact that most "chat" via computers used to be text-only communication is an artifact of the technology that was available, nothing more.
(Note that he didn't even say "web chat", but that's beside the point.)
Re: (Score:3)
It may not have been designed for audio files, but it's pretty damn good at them anyway - the hydrogen audio chaps rate is as equivalent to AAC and vorbis at the same bitrate, as well as having excellent quality at low bitrates along with low algorithmic delay. It appears to be a "cake and eat it" codec at present.
See here for their take on this very promising codec: http://wiki.hydrogenaudio.org/index.php?title=Opus [hydrogenaudio.org]
Now the problem that#s always plagued vorbis... will we see widespread hardware support for
Re: (Score:2)
It may not have been designed for audio files, but it's pretty damn good at them anyway - the hydrogen audio chaps rate is as equivalent to AAC and vorbis at the same bitrate, as well as having excellent quality at low bitrates along with low algorithmic delay. It appears to be a "cake and eat it" codec at present.
Not quite. It's true that for the majority of western music it performs just as well as AAC and Vorbis, however there are certain classes of audio that it does poorly with, in particular polyphonic music. This is an inherent limitation (steming from the pre/post comb filter), that cannot be overcome in future encoders.
For streaming audio, this isn't a big deal as it is somewhat of a corner case and people don't hold streaming audio to flawless standards. However, for a music library, you want an audio form
Re: (Score:2)
Not quite. It's true that for the majority of western music it performs just as well as AAC and Vorbis, however there are certain classes of audio that it does poorly with, in particular polyphonic music. This is an inherent limitation (steming from the pre/post comb filter), that cannot be overcome in future encoders.
This is not actually "true" now. I remember reading a while back that this was one of the major goals of the 1.1 release, and it looks like they largely met that goal.
Look for the section labeled "Tonality Estimation".
http://xiph.org/~xiphmont/demo/opus/demo3.shtml [xiph.org]
The short of it is that they have additional code to detect when there are many tones, and when "we consider the frame to be tonal and increase its bitrate." The samples they have of the page seem to show a 25-50% increase in bitrate when it doe
Re: (Score:1)
The RIAA has nothing to do with audio formats or their creation/standardization. Also, MP3, AAC, etc. are open formats. One can implement them from publicly-accessible format specs.
Props to the authors of TFA (Score:5, Interesting)
As someone who has previously written outwardly facing articles on complex technology, I have to give props to "Monty" and Jean-Marc Valin for TFA. It takes a lot of skill to communicate good information about some very complex topics in a short amount of space, and they pull it off pretty well. I think it really helps sell the product and keep your enthusiasts more engaged when you can see how much work and thoughtfulness has gone into the guts of it - work that is often unseen, hidden within a dev team, or buried throughout a mailing list somewhere.
Re:Props to the authors of TFA (Score:5, Interesting)
Yeah, Monty's writing on these topics is exceptionally clear. His series on the Daala video codec [xiph.org] introduces modern video encoding in a way that's amazingly accessible. Maybe he should write a textbook.
Re: (Score:2)
I love this section from the Opus 1.1 release notes:
1.1 also adds temporal VBR, an accidental discovery from a bug in an earlier pre-release. Temporal VBR is new heuristic that adds bits to loud frames and steals them from quiet frames. This runs counter to classic psychoacoustics; critical band energies matter, not the broadband frame energy. In addition, TVBR does not appear to be exploiting temporal postecho effects.
Nevertheless, listening tests show a substantial advantage on a number of samples. I'll be the first to admit we haven't completely determined why, but my best theory is that strong, early reverberant reflections are better coded by the temporary allocation boost, stabilizing the stereo image after transients especially at low bitrates.
Re: (Score:2)
Re: Props to the authors of TFA (Score:1)
It really depends on the buffer size, which tends to be brain specific.
Opus flawed test results (Score:1)
" Its first release beat everything else last year at 64kbit/s in a listening test held at HydrogenAudio."
No offence, but this test was solely based on "user preference". .wav, using the above data as comparison?
- Wheres the Spectrum analysis of each codec?
- Which codec is more true to the original
- Which codec cuts below 50hz?
- Which codec emphasizes certain frequencies (8-10khz, typical LAME mp3)?
- I'll automatically assume, your Opus codec (which is based on a voice codec) prioritizes bitrate quality bet
Re: (Score:1)
Looking at the waveform of a compressed piece of audio is really not a "scientific test".
As long as the ear can't hear the difference between the original file and the compressed one it doesn't matter a bit if they look very different.
- Peder
Re: (Score:2)
>No offence, but this test was solely based on "user preference".
Offense taken.
That's how testing works in the audio industry. Mainly because it's the only thing that makes sense.
>- Wheres the Spectrum analysis of each codec?
A spectrum tells you almost nothing about how a codec sounds. Thus listening tests.
>- Which codec is more true to the original .wav, using the above data as comparison?
That's what a listening test answers. I know very few people who listen to music by unplugging their speakers,
Re: (Score:1)
Offense taken.
That's how testing works in the audio industry. Mainly because it's the only thing that makes sense.
Fair comment and i see your reasoning, however, if you want to appeal to more "knowledgeable" users in your tests, you should supply the following info:
- What hardware playback device were you using for the tests?
- What speakers/headphone devices were tested (DT 990 pro's / Ipod standard)
- Were you tests consistent across the board of devices used?
A spectrum tells you almost nothing about how a codec sounds. Thus listening tests.
A spectrum analysis tells you everything regarding a codecs compression/quality ratio.
If your aiming for your codec to simply "sound good" but actually "be comple
Re: (Score:1)
>- What hardware playback device were you using for the tests?
>- What speakers/headphone devices were tested (DT 990 pro's / Ipod standard)
In this style of test, that's mostly irrelevant. One wants testing on a wide range of equipment, and no, the list of equipment is not documented. I can say though it encompasses the range from earbuds to electrostats.
>- Were you tests consistent across the board of devices used?
Oh right. You didn't read anything about it. You're just commenting.
>A spectru
Re: (Score:1)
Interesting, the comment system removed several lines of text right smack in the middle of the comment.
Re: (Score:1)
The text that got mangled:
>You could increase that to 20hz for improved quality/compression ratio. .1Hz, at least in the codec. The goal is only to remove DC.
>20hz is generally regarded as the cut off point for all audio production,
No, 50Hz is usually the default cutoff (to control power draw and excursion) unless it's an audiophile or 'classy' production, then it's less than 1Hz often as low as
>Pretty pictures might work on most people, but a page full of "hear say" does nothing to help Opus.
Hi,
Re: (Score:2)
>Pretty pictures might work on most people, but a page full of "hear say" does nothing to help Opus.
Hi, I'm one of the authors of the codec. I wrote detailed pages explaining how aspects of the codec work, which you could not be bothered to read before lecturing us on what's supposedly wrong with Opus. Which one of us is indulging in 'hearsay' again?
Oh, snap! That was awesome.