This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.
I'd like to have a native speaker or similarly qualified person read the article and correct the language of translated parts.--Flugaal (talk) 19:25, 13 July 2012 (UTC)
I read and didn't notice language problems. Mike Linksvayer (talk) 18:25, 3 August 2012 (UTC)
merge the CELT article?
Should we merge the CELT article into this one? - I'm undecided:
Maybe because Opus is the current incarnation of CELT and we don't keep seperate articles on different versions of a piece of software... Or maybe because CELT may be seen as kind of vapourware. Or maybe because there is much overlap. Or maybe not because CELT was already functional without the SILK part and was and still is being used out there. And maybe it is significantly different because in contrast to Opus you can use the technology for whatever you want - in the true spirit of FLOSS...--Flugaal (talk) 15:47, 3 August 2012 (UTC)
I don't see any reason to merge, though it might be more clearly stated in the CELT article that it has been superseded by Opus (it does say so in the infobox). Mike Linksvayer (talk) 18:25, 3 August 2012 (UTC)
Some corrections
I'm an author of Opus, so I prefer not to edit myself. I just wanted to point out a few minor issues with the article:
"Opus was entered under the original name of Harmony[11] for a codec competition of the IETF, which was eventually accepted and granted the codec working group." -> After CELT and SILK were merged, the resulting codec existed for a while without having a real name (referred to as the "ietf codec", the "internet codec", or similar). Harmony only came in later and was quickly changed to Opus. The second point about this sentence is that there never was a "codec competition". We set out to collaborate right from the start because what we had were complementary codecs with virtually no overlap.
I might have picked the wrong word again.
As I understand there have been other proposals apart from SILK and CELT. At least BroadVoice16/BroadVoice32 was on offer and I think I also heard about Siren technology being (?considered to be?) offered and maybe more. How did they get sorted out? Weren't they competing offers?--Flugaal (talk) 19:45, 13 September 2012 (UTC)
"The working group finally formed in February 2010 and even the corresponding Study Group 16 from the ITU-T pledged to support its work." -> I'd have to look at the statements that were made, but I don't think ITU-T SG16 made any such pledge. At best they just said they would communicate or something like that.
This is mainly based on Yusuke Hiwasaki's statement in the WG meeting at IETF 76:
"Some members of ITU-T have expressed concerns towards this work item, but I believe they are not speaking as ITU-T persons. My understanding why I'm here would be to say... ITU-T wouldn't dare to get in the ways of other SDOs. But what we are trying to do would be to find a way to... - I'm sort of walking on a very thin line... - All the liaison statements says would be that we are willing and cooperate in that, we are willing to cooperate or help in that respect, that's what we are saying. Anything further I'm not in the position to clarify that."
The formulation gets it wrong and maybe especially the word "pledge" is just too strong here.--Flugaal (talk) 19:45, 13 September 2012 (UTC)
I just added that ffmpeg 1.0 also includes Opus support now, if someone wants to make that all nice and pretty I'm not bothered by it. I can't really use a source for it because it's on the mainpage of ffmpeg so it's subject to change with more recent news, and there's no article I can link to aside from the ffmpeg website, unless someone wants to look for a linkable changelog. Atomic1fire (talk) 05:22, 29 September 2012 (UTC)
Quality Comparison image is incomprehensible to color blind users
The quality comparision image uses (what I assume are) red and green lines to differentiate between licensing types. There are some guidelines for fixing it here:
I'd fix it myself, but I can't tell the difference between the colors. — Preceding unsigned comment added by 108.193.27.120 (talk) 15:19, 25 October 2012 (UTC)
I've made a colorblind fix to the original SVG file very easily using a Text editor (in my case WordPad under Windows) but I'm not aware of how to update the original on Wikimedia Commons. Perhaps somebody could do so. There are five colors in the original: Black #000000, Grey #808080, Blue: #0000FF, Green: #008000, Red: #d40000 and all references to them begin with a :#, so Red remains a good color for codecs with licensing fees, and out of Black or Yellow, the currently Blue items for Free License not open source I changed to black #000000 (although a mid gray such as #808080 might be acceptable too). Once the blue has been replaced, green can be changed to blue.
Replace... :#0000FF ...with :#000000 ...and hit Replace All
then Replace... :#008000 ...with :#0000FF ...and hit Replace All
then Save the file
then upload to Wikimedia Commons as a revision of the original, and do whatever you have to to get the PNG rendered versions.
If you've saved the file on your machine, you can upload over the original file on Commons like any other upload. Click through to the Commons version from the WP version of the file. Then, go to the "File history" section. Below the revision history there should be a line that says "upload new version". Then it proceeds more or less the same way as any other upload or change as the rest of the Internet. Leave another note here if you need more help with the image upload process.
The png version of the image displayed on the article is automagically rendered by a svg -> png image generator. --Izno (talk) 18:52, 29 October 2012 (UTC)
Thanks, Izno. I'll try to do that now. Dynamicimanyd (talk) 12:52, 30 October 2012 (UTC)
Colorblind version of Opus quality comparison.svgImmediate update - "You cannot overwrite this file." is what it says in Wikimedia Commons, even when I created an account there. If I were to replace the original, I'd prefer to make it revertible and include the current revision history rather than upload a new file. For simplicity, I've uploaded a version to Wikimedia Commons copying over the attribution on Jean-Marc Valin's original and have attached it to an earlier draft of the Opus page in my sandboxDynamicimanyd (talk) 13:28, 30 October 2012 (UTC)
Your account might be too new to overwrite existing images but not too new to upload new images. This is fine, that the images are separate, since the original is not "your" image, so-to-speak. I've tweaked the "other versions" parameter of the information template for the time being. --Izno (talk) 14:25, 30 October 2012 (UTC)
Thanks for your prompt guidance, Izno. I guess I'll go ahead and edit the main Opus article. Dynamicimanyd (talk) 14:35, 30 October 2012 (UTC)
Beat you to it! :) --Izno (talk) 15:07, 30 October 2012 (UTC)
That all done, is File:Opus bitrate+latency comparison.svg also red-green viewable? The different ovals closer to the top have a orange->green gradient, so I'm wondering if that gradient visible. --Izno (talk) 15:09, 30 October 2012 (UTC)
I found a website to render as if viewed with various forms of colorblindness at colorfiler.wickline.org where you can paste a JPG, GIF or PNG image's URL and select the filter (but doesn't seem to respond to the full URL of the Wiki image HTML page and perhaps not to the SVG image). Looks OK but not wonderful for Red/Green protanopia (no red cones), similar with no green, and fine with no blue cones. Rather poor but usable in grayscale. All in all, I think it will suffice unless somebody flags it up. With the color fades it might be more difficult to amend the SVG. P.S. Thanks for updating the main article - I got called away! Dynamicimanyd (talk) 16:08, 30 October 2012 (UTC)
Clarification of low latency in introductory section
In response to the clarification needed remark, I've worked on some rewording of the introductory section, using a notes section (hope people find this style acceptable and that the specifics are accurate - Jmvalin?) above the reference footnotes to provide fuller clarification / explanatory details elsewhere without over-complicating the introductory section, which is mainly about what Opus is and why Opus is notable (royalty free, open source, standardized, low latency/interactive, seamlessly adaptable bitrate & operating modes, music-compatible from small file size to transparency, best quality-per-bitrate or close at default delay over most of bitrate range)
I've put the whole article as I've edited it, in my sandbox to allow for comments or easy comparison if someone feels the main article edits I commit should be reverted. This also rewords 20 ms of latency to 20 ms frame size in the Overview section for accuracy and consistency with the intro.
This is great work, but it really belongs in the article body rather than in the footnotes. I've taken these notes and added them to the (somewhat short) performance section; in some cases, the assertions therein really need citations themselves as well. Chris Cunningham (user:thumperward) (talk) 10:42, 24 October 2012 (UTC)
Rather than rely on the links through to other Wiki articles and their sources for the specifics I mentioned, I'm going through the process of finding suitable references using Google Scholar and hope to include those shortly. Dynamicimanyd (talk) 16:30, 30 October 2012 (UTC)
Just completed digging out some suitable citations for the section renamed Quality comparison and low latency performance, particular with reference to audio latency targets from Google Scholar. Some of these provide further relevant background reading for those interested in the specific techniques. Removed the Citation Needed notifications, as I think they match the numbers quoted and support the claims made. Dynamicimanyd (talk) 20:45, 30 October 2012 (UTC)
Addition of radio stations with live Opus streaming trial
I noticed that although streaming software is mentioned, an Opus streaming radio trial of 7 channels, each at 3 bitrates, that has been running since Sept 2012 has gone unmentioned on opus-codec.org and this Wiki page (only know about it from HydrogenAudio.org), so thought I'd reference Absolute Radio's Listen Labs Opus Streaming Trial assuming nobody objects. Dynamicimanyd (talk) 20:55, 30 October 2012 (UTC)
Example files
Does Wikipedia/Wikicommons have any Ogg Opus files? Regards, Sun Creator(talk) 22:55, 23 December 2012 (UTC)
I don't believe it does, see http://commons.wikimedia.org/wiki/Category:Audio_files_by_type (all .ogg files, meaning Ogg Vorbis which was originally in accord with the philosophy of using only open codecs, which should be compatible with Opus too, though the Wikimedia Commons might not currently support Opus embedding).
The opus-codec.org/examples page has an embedded piano music sample from Ehren Starks which was released under some open license. It also includes a very neat bitrate-sweep, though to make it play in web browsers of the year 2012 other than Firefox/Seamonkey it was actually embedded as high-bitrate Vorbis, not Opus directly. The use of dials and indicators to visualize the settings being player was very neat, but needs HTML scripting, which I don't think Wikipedia permits. For any examples we have it might be worth providing a higher-rate Vorbis transcode for those browsing without native Opus support to allow users of non-supporting browsers to get the idea.
I don't know the Wikipedia stance on Fair Use arguments and which jurisdiction's legislation applies, but for codec testing, a place like hydrogenaudio.org allows clips up to 30 seconds long, so it might be possible to encode some commercial examples clips to demonstrate features.
It's possible that lossless sources of music/speech might be available on the web, e.g. archive.org has a number of authorized live show recordings, but presumably there is some form of license which might need comparing against Creative Commons. There might be some Creative Commons FLAC (or other lossless) sources that sufficiently demonstrate the use cases.
The use cases worth demonstrating include general cases, and cases where Opus offers notable advantages (such as seamless mode switching)
Speech - narrowband, mediumband, wideband, superwideband (hybrid), fullband, fullband stereo (CELT), packet loss concealment without FEC, with FEC - could sweep or switch modes within one stream.
Speech with background noise or background music or musical inserts (e.g. phonecall in a public place with music playing, typical podcast or radio theme & introduction excerpt, or audiobook excerpt with music or sound effects)
Automatic mode switching (speech/music detection and bandwidth, works quite well automatically around 30-48 kbps on latest encoder) - good for simple podcast encoding. Compare with manual mode switching - stitch 64k stereo music to 20 kbps mono speech segment, for example.
Capture interactive speech conversation (e.g. capture from a Mumble chat session - which I think is stored as FLAC, so requires transcoding into Vorbis or Opus)
Interactive music jam session (or synchronised singing - e.g. "Row Row Row Your Boat" or "London's Burning" as a round), possible to include examples of quality with 2.5ms frame size.
Music storage - mono, stereo and multichannel (e.g. 5.1) - requires CD or DVD quality source with suitable licensing. Demo of various bitrate settings, e.g. 32m, 48m, 64s, 96s, 128s, 160(5.1), 224(5.1). Also demonstrates playback on less capable equipment for most of us, who'll be listening to the 5.1 in stereo only.
Music streaming - changing bitrate. Possible to demonstrate bitrate switching or sweeping as if moving from WiFi to 3G to 2.5G data.
There are FLAC files at Wikimedia Commons, uploaded in Ogg container with the .oga or .ogg extension. Flugaal has uploaded some FLAC files demonstrating several codecs (like File:FSsongmetal2-Opus-exp7.20120823-158kbps.oga). It may still be possible to upload Opus-encoded audio with the .oga extension, too. Also bugzilla:40193 is worth checking. --AVRS (talk) 15:01, 25 December 2012 (UTC)
Large codebooks for each individual file
The intro claims:
"Its delay is good compared to well over 100 ms for popular music formats such as MP3, Ogg Vorbis and HE-AAC; yet Opus performs very competitively with these codecs in terms of quality per bitrate. Unlike these codecs, Opus does not require the definition of large codebooks for each individual file, making it preferable also for short clips of audio."
I am not aware of large codebooks required for each individual file, when it comes to MP3 and HE-AAC ... both codecs are used in streaming environments, afaik. — Preceding unsigned comment added by 188.98.1.131 (talk) 20:40, 7 March 2013 (UTC)
Streaming is not about numerous short sound clips typically, so large codebooks don't impose a significant penalty in streaming. Vorbis, being patent-free like Opus, is widely used in games today where numerous short clips (of the order of one second) are common, but does have large codebooks on each clip. Opus has potential to offer an improvement to Vorbis is this respect as well as quality per bitrate. The two sentences in that paragraph are not connected except as notable points of difference for Opus compared to today's commonly used formats. Dynamicimanyd (talk) 00:18, 9 March 2013 (UTC)
If I understand correctly, Ogg Vorbis comes with the penalty of large codebooks, right? On the other hand I am quite sure that this is not the case for mp3 and HE-AAC. Hence I suggest to rephrase the related sentence: "Unlike Ogg Vorbis, Opus does not require the definition of large codebooks for each individual file, making it as preferable as mp3 and HE-AAC for short clips of audio." — Preceding unsigned comment added by 88.67.171.227 (talk) 12:47, 10 March 2013 (UTC)
The move from "Opus (audio format)" to "Opus (audio codec)" doesn't make sense. Opus is a format, there may be several codecs that implement it. (Isn't there already?..) So, I guess I'll move it back.--Flugaal (talk) 19:53, 13 August 2013 (UTC)
From the first infobox, Website: opus-codec.org -> http://opus-codec.org/ -> Opus Interactive Audio Codec ... Overview ... Opus is a totally open, royalty-free, highly versatile audio codec. TeraCard (talk) 01:18, 14 August 2013 (UTC)
Operating systems and desktop multimedia frameworks
It mentions the Debian linux distribution and descendants - but it should not be so specific. For example, it also is in Fedora and has been for some time. I suspect the list of current distributions that do not have it in their repositories is a much smaller list than those that do not, and I don't think the page should be used to give the impression that someone needs to install a Debian based distribution to get Opus support natively in Linux.
Perhaps a better phrasing would be Most GNU/Linux distributions have Opus and related tools in their pre-configured package repositories or something along those lines. The page should be distribution agnostic given how open all the distributions are to Opus. 71.9.132.17 (talk) 23:40, 18 February 2014 (UTC)
Given that now Opus support is not uncommon in desktop applications, I wonder whether the list of multimedia players and streaming services is indeed needed. May be it would be better at this point to replace this info with a general note about Opus availability and only discuss communication hardware and software in detail? — Dmitrij D. Czarkoff (talk•track) 13:01, 28 May 2014 (UTC)
Looks like you've already done so, and I think it looks great. No need for an exhaustive bullet list of every piece of software that supports Opus here. --Bigpeteb (talk) 19:22, 29 May 2014 (UTC)
Codec delay values
I've been trying to do the math to understand the codec's delay, in particular separating the delay due to frame size from the algorithmic look-ahead delay. However, I can't get the numbers to add up.
"[The LP layer, based on SILK,] requires an additional 5 ms look-ahead for noise shaping estimation. A small additional delay (up to 1.5 ms) may be required for sampling rate conversion."
"A "Hybrid" mode allows the use of both layers simultaneously with a frame size of 10 or 20 ms"
"[The MDCT layer, based on CELT, supports] frame sizes from 2.5 ms to 20 ms, and requires an additional 2.5 ms look-ahead due to the overlapping MDCT windows."
"To compensate for the different look-ahead required by each layer, the CELT encoder input is delayed by an additional 2.7 ms. ... However, the base 2.5 ms look-ahead in the CELT layer cannot be reduced in the encoder because it is needed for the MDCT overlap"
"CELT's look-ahead is 2.5 ms, while SILK's look-ahead is 5 ms, plus 1.5 ms for the resampling (including both encoder and decoder resampling). For this reason, the CELT path in the encoder adds a 4 ms delay. However, an application can restrict the encoder to CELT and omit that delay. This reduces the total look-ahead to 2.5 ms."
"The listening tests in this were performed with a constant window length of 20 ms. With that frame length there is also 5 ms look ahead."
Like I said, I can't get these numbers to add up. Here's my math, and the problems with it:
In CELT-only mode, 2.5 ms of algorithmic delay + minimum frame size of 2.5 ms = 5 ms total delay (the minimum the codec can have)
In SILK-only mode, 5 ms of algorithmic delay + minimum frame size of 10 ms + no resampling delay (best case, in which no resampling is needed) = 15 ms total delay
In Hybrid mode, ??? algorithmic delay + frame size + ??? resampling delay = ??? total delay
Algorithmic delay seems like 5 ms due to SILK
Resampling delay seems like 1.5 ms, again due to SILK
This should give a sum of 6.5 ms, which agrees with Xiph's paper and most of the RFC
But it doesn't agree with the maximum delay mentioned in the RFC (65.2 ms)... why isn't this 66.5 ms?
CELT delays its output, but by how much? The RFC says 2.7 ms (which would sum to 5.2 ms), while Xiph's paper says 4 ms (which sums to 6.5 ms).
Can anyone shed some light on the disagreements between these figures? --Bigpeteb (talk) 17:13, 20 May 2014 (UTC)
I was quite careful to define what was meant by 'algorithmic delay' when rewording and improving the citations within the article in about December 2012 (from memory), with careful reading and interpretation of the reference that best defined it, which I cited. The current wording used in section Quality comparison and low latency performanceis much like what I used...
Total algorithmic delay for an audio format is the sum of delays that must be incurred in the encoder and the decoder of a live audio stream regardless of processing speed and transmission speed, such as buffering audio samples into blocks or frames, allowing for window overlap and possibly allowing for noise-shaping look-ahead in a decoder and any other forms of look-ahead, or for an MP3 encoder, the use of bit reservoir.
Your definition seems to be excluding frame size, which mine is including. However, a working definition used in another document might exclude some items that are included by the definition above. The term "algorithmic delay" is not very widely used and consistently defined in the literature, as frequently it's more important to report the actual latency of a specific physical implementation (with limitations on processor speed and hardware latency also contributing to that figure). Sometimes "latency" is lazily used instead, which is OK qualitatively (high or low) but not quantitatively. There are some items of optional delay such as the length of the FIR filter used in resampling or anti-aliasing, which might also get excluded. I don't have time to look into the specifics now, but I hope this help you narrow in on a definition that makes sense. If in doubt, remove algorithmic delay and replace it with all its component delays so that you can avoid double-counting. The block diagram of the codecs from xiph.org and their presentations such as Jean-Marc Valin's talk is quite helpful in showing where delay arises. Hope this helps a little. For a better discussion, likely to be viewed by some of the Opus developers, try joining the forums at Hydrogenaud.io [[1]] and asking on their Opus sub-forum. Dynamicimanyd (talk) 12:41, 3 July 2014 (UTC)
The numbers in the RFC are wrong :) The 2.7ms may apply to some old version, but it is currently 4ms in the reference implementation. This plus the 2.5ms inherent CELT delay matches the SILK 5ms delay plus 1.5ms required for resampling which is always performed in hybrid mode. Other implementations could differ. There is a specific low delay mode that operates without the extra 4ms, but obviously only with heavy restrictions in place.
The 65.2ms is wrong. That would presumably be 60+2.5+2.7 which we already deduced was wrong. 6.5ms would be correct with resampling (60+5+1.5), but resampling doesn't always have to be done. Lithopsian (talk) 20:39, 15 August 2014 (UTC)
I'm the author of Opus. I confirm that the 65.2 ms and the 2.7 ms figures in the RFC are wrong. SILK has 5 ms delay + 1.5 ms for resampling. On the CELT side, there's a 2.5 overlapping delay, and we add 4 ms to make it in sync with SILK (unless selecting restricted-lowdelay application). — Preceding unsigned comment added by Jmvalin (talk • contribs) 17:29, 17 August 2014 (UTC)
Thank you Lithopsian and Jmvalin for your comments here and Bigpeteb for your edit to the live article. As for a citation, the top paragraph in page 2, column 2 of the AES paper by Valin et al.[2] gives the correct figures of SILK 5.0ms + 1.5ms = 6.5ms = CELT 2.5ms + 4.0ms. It also mentions the restricted low-delay alternative with 2.5 ms delay and CELT only. I will insert that reference and remove the {citation needed} tag.Dynamicimanyd (talk) 16:47, 19 August 2014 (UTC)
My new revision includes that reference, a modicum of explanatory rewording and replaces the old, wrong, "opusdelay" named reference with the more recent and accurate "ValinAES135". Hopefully, this concludes the matter. Thanks to all for initial spot and the fruitful discussion.Dynamicimanyd (talk) 18:18, 19 August 2014 (UTC)
Spectrogram
I'm not going to edit this article myself since I'm one of the main authors of Opus, but I really think the spectrogram should go -- or at the very least be done properly. These spectrograms (the ones for Vorbis/MP3/AAC too) aren't showing anything interesting. To be more precise, they're showing two things:
the low-pass thresholds for the particular encoder they've been generated with
that when you have a signal close to the max PCM value, you get clipping all over the place when decoding (all of these vertical stripes going all the way to Nyquist are clipping)
In no way do any of these spectrograms represent anything meaningful about the formats. Jmvalin (talk) 19:45, 29 August 2014 (UTC)
I was pondering that same spectrogram when editing the article recently. It's the one diagram that shows little useful information. I imagine something like the bitrate sweep [3] audio-visual example would be more illustrative - and the whole site is Creative Commons licensed allowing remixing. While we can't used Javascript Dynamic HTML on Wikipedia, we could for the time being screen-capture it and encode it to WebM or Theora for use here. I believe those formats in Wikimedia only support Vorbis, but we could transcode the decoded sweep.wav into a highish-quality like -q 7 (~224kbps) or above to give a close approximation of sub 65 kbps Opus 1.0 with negligible transcoding artifacts and good enough for an illustrative example. Dynamicimanyd (talk) 16:38, 3 September 2014 (UTC)
RFC: References-at-End or References-throughout structure in this article
This article uses a single list of named reference/citation/footnote definitions that are located in the References section of the Wiki markup.
Using named references in itself allows the same source to be used to support different facts throughout the article.
Putting them all in the References section rather than adjacent to the text where they are cited has one advantage:
• they are easy to find, to look up the name when citing the same source again.
And some disadvantages:
• it's not widely used in Wikipedia, so causes mixed referencing style when people add citations, which can be confusing
• you cannot use un-named references without mixing the style
• you cannot use the per-Section Edit feature and cite new sources without mixing your style or saving a broken reference to an undefined name on live Wikipedia then editing the References section to fix it afterwards. This forces responsible editors to Cancel, go back and Edit the entire article instead.
This is the more common way of doing things and enables editing the article with new citations using the section Edit button instead of only via the main Edit button. Dynamicimanyd (talk) 09:06, 9 March 2015 (UTC)
So far I thought that using <ref name="foo" /> before or after the one and only definition just works as expected, did I miss a clue? Of course I have no objection to avoid forward references, but I also never tried to "fix" this, and long definitions within an infobox instead of later places could be clumsy… As always curious: Be..anyone (talk) 09:51, 9 March 2015 (UTC)
The named reference with forward-slash does work before or after, so feel free to tidy it up further. I've simply gone through and replaced the first instance. If the same reference is used elsewhere and you feel it would be neater to move it, feel free to switch the definition to another instance with a bit of cut-and-paste.
My main reason for the change is that editors are encouraged to stick to the format used elsewhere and it renders the Edit link in each section useless if you have to edit the whole article to cite your references. In fact, the old method caused more work, because you had to jump to full article edit to finish citing things consistently. Editing sections in this way also reduces the likelihood of edit conflicts since most often the conflicting editors would be editing different sections simultaneously. Dynamicimanyd (talk) 18:22, 9 March 2015 (UTC)
No problem, I was only curious, and as it happens I just stumbled over two cases on Creative Commons, where the other style seriously confused me (two named references, and the definition was neither there nor here, but elsewhere... ;-) –Be..anyone (talk) 19:09, 9 March 2015 (UTC)
CPU Bandwidth
Try as I might, NOBODY seems to have compared video-codecs in terms of quality (error-rate from original, uncompressed video) and of CPU power. NOWHERE gives a core-mark or Dhrystones value for this and all of the other codecs. — Preceding unsigned comment added by 213.106.56.145 (talk) 16:50, 21 October 2015 (UTC)
Opus is not a video codec; it is audio only. LiberatorG (talk) 18:19, 21 October 2015 (UTC)
Actually, it is an audio coding format, not an audio codec (the reference codec is implemented in opus-tools). You don´t compare audio (or video) coding formats in terms of quality and CPU power in a meaningful way, as there can be (and often are) multiple corresponding codecs for any given format made by different people, implemented in a number of different ways which can greatly affect quality and CPU usage. In fact, they do not have to be using the CPU at all (they can use other, specialized hardware).—J. M. (talk) 18:31, 21 October 2015 (UTC)
External links modified (January 2018)
Hello fellow Wikipedians,
I have just modified 2 external links on Opus (audio format). Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.
This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 18 January 2022).
If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
If you found an error with any archives or the URLs themselves, you can fix them with this tool.
@LiberatorG:Impressive edit comment! I agree with part and disagree with part, so a response is too big to possibly fit into an edit comment.
Re: UDP, I mentioned it because it's by far the most familiar packet-oriented network protocol, and didn't think about the rearrangement issue. You're absolutely right it's not actually suitable, and adding the necessary caveats complicates the whole explanation to the point it's useless. I was just trying to make the point "you don't need a container file format if you have a datagram-oriented transport layer" and messed it up. You need an ordered datagram transport like RTP, LAPB, 802.2, X.25, etc.
Thank you for catching that bit about switching parameters on a packet basis which I missed.
Re: Forcing SILK mode. What I was trying to convey is that 40 or 60 ms frames (not packets; the entire point of my edits was clarifying that distinction) are only available in pure-SILK mode. Pure-SILK mode implies a bandwidth restriction. The higher-level goal is to get the reader to understand that 40 or 60 ms frames are not commonly used. I may have phrased it awkwardly, but I believe what I wrote was correct: > 20 ms frames are only available with ≤ 8 kHz bandwidth.
Re: "not normally self-delimiting". I'd yank the word "normally" back out. The self-delimiting format is an optional alternate format whose contents are not standard Opus packets. Standard-compliant Opus packets are never self-delimiting.
Re: Output sample rate may be lower. I actually thought of and tried to include that possibility in the phrasing "as long as it is enough to represent the desired bandwidth". Not wanting frequency bands that are coded in the data stream is a strange application (why not tell the encoder to use the bits for higher fidelity in the bands the decoder wants?), but if you don't want the higher frequencies, you can throw them away on decode. (It might happen in some telephony bridge which is transcoding to a narrowband format.)
I don't understand your words about timestamps being measured at 48 kHz. Where in the Opus format do such timestamps exist?
(Thanks for fixing that "depends" stupidity, BTW.)
Ok. I had combined the "file" and "network" formats because many of them (especially MPEG-TS and Ogg) are both. However if you view it in terms of "stream" formats and "datagram" formats then I guess that separation works (especially now that SCTP is removed, since it could be both stream and datagram).
As for packet/frame overhead at low bitrates, it reduces both so I changed it to just "overhead".
The issue with the text about longer durations was that it sounded like requesting a longer duration forced a lower bandwidth. However what the application gets is a packet, not a frame; requesting a longer duration may result in multiple frames per packet, but there is no issue getting a higher bandwidth. The frame size is chosen based on the requested packet duration and bandwidth; it doesn't fix the frame size and then use that to pick the bandwidth. The current text seems ok.
Encoded Opus data is independent of the input or output sample rate. Your earlier edit added that "it is always as if it were operating on 48 kHz data". I don't know what you meant by that; if for example you encode 16 kHz sample rate speech with SILK, there is no point at which the samples are 48 kHz. The only things that I can think of that would use 48 kHz in that case are container-specific, such as timestamps in containers like Ogg or RTP that typically use a sample count for their audio timestamps; these timestamps are measured as if the sample rate was 48 kHz. So I was attempting to clarify what exactly was "as if it were 48 kHz". But you are correct that that is not part of Opus itself but the container mapping; the 48 kHz number is used to adapt to containers that were designed for sample-rate-specific codecs and does not seem to have any relevance in this container-independent section. Therefore it would probably be better to just state that encoded Opus data is independent of sample rate.
@LiberatorG: " I don't know what you meant by that" Huh! And I was pretty happy with that phrasing. I meant that (unlike mp3) the Opus-compressed data stream is independent of the input sample rate. The compressed form is always as if the input audio were resampled to 48 kHz before compression, although as an implementation efficiency detail the codec can deal with divisors of that sample rate.
"It is always as if it were operating on 48 kHz data" is somewhat imprecise; depending on the what "it" refers to this could mean that encoding data that's at a lower sample rate will cause it to play back faster and higher pitched, because the input data was treated as if it was 48 kHz. However my main concern is simply that it's misleading to state that it is treated as if it were a particular sample rate when the compressed data is actually independent of sample rate. It leads the reader to wonder what is significant about that rate or if they missed something important about how that rate is used. If the text is clear about what is significant about the 48 kHz rate, even if it is just that it's the rate used for container timestamps, then I see no issue mentioning it, but mentioning a specific sample rate without any mention of the significance of that rate just makes it more confusing. -LiberatorG (talk) 20:43, 9 January 2019 (UTC)
Poor choice of audio for spectrogram bitrate comparison image
The article makes use of File:FSsongmetal2-Opus-exp7.20120823-sweep.png to illustrate how a "Spectrogram of Opus-encoded audio as bitrate rises (~32 to ~160 kbit/s) clearly shows lowpass behavior and better preservation of the band energy with CELT (compare original, Vorbis, MP3, AAC)." However, the original audio is not only too inconsistent across sample segments to be a useful comparison, it further confuses the comparison by having sections of distinct musical traits which align to the bitrate segments. As a result, the differences in musical traits are far more visible than the differences in encoding bitrate that the comparison is supposed to illustrate.
For convenience, here is the original and the Opus encoding:
djr13 (talk) 00:32, 21 May 2020 (UTC)
Spectrogram again
Earlier comment from Opus author notes that the spectrogram does not actually show anything about quality, but just the low-pass behavior. It is even more useless after Opus 1.3 changed the low-pass thresholds.
I originally wanted to start a topic to request Flugaal to make some script available to generate a new version, but the earlier comment also makes sense. Maybe the picture wasn't very useful to start with. Artoria2e5🌉 13:00, 7 August 2023 (UTC)
/Archive 1#CPU bandwidth asks the question of CPU work vs quality attained. There is indeed a "complexity" knob in libopus that tunes for this sort of stuff, but documentation on how it affects quality is quite scant. We know what it does from the code, yes, but not quite how it sounds yet.
opus 1.2 page shows how the knob affects CPU time and describes a new improved stereo search code that turns on at higher complexity.
Complexity is still a big design consideration. That's how we got SBR and LC3 -- they may sound awful, but they are fast. Artoria2e5🌉 14:27, 7 August 2023 (UTC)
The opinion of the reference implementation can be found in compute_equiv_rate(). This function outputs an "equivalent" bitrate for a given configuration, so that the bandwidth / coder decisions can proceed without being too thrown off by frame sizes, CBR, & complexity settings. Here's what it says about complexity:
Each level adds 1% uniform bitrate cost for same quality
For SILK and Hybrid, complexity 0-1 adds 20% bitrate cost
djr13 (talk) 00:32, 21 May 2020 (UTC)