similar to: Opus frame size

Hi, I noticed that speex.org has a banner that mentions that Opus is better than Speex in all aspects. The supported bitrate range for Speex seems to be as low as 2kbps though but Opus can only go as low as 6kbps. Is this one aspect where Speex is still preferred? (I understand that it's not a very common scenario though). Thanks, Manpreet. -------------- next part -------------- An HTML

Hi Dragos, The issue is that not all packet loss maybe congestion related. Often, reducing bitrate seems to have no impact on improving packet loss. Thanks, Manpreet. On Tue, Dec 16, 2014 at 2:09 AM, Dragos Oancea <droancea at yahoo.com> wrote: > > Hi > > You can start a VOIP call with 50 kbps bitrate and reduce the bitrate if > there is packet loss. You know if

Hi, Although this maybe considered out of scope here, but I'll ask anyway. Opus has remarkable flexibility for changing encoder bitrate during a call. Are there any suggestions about how bandwidth/capacity between the two endpoints can be measured/estimated during a call so that the outgoing bitrate can be adjusted accordingly? Thanks, Manpreet. -------------- next part -------------- An

Hi You can start a VOIP call with 50 kbps bitrate and reduce the bitrate if there is packet loss. ?You know if there's packet loss if you receive RTCP .?Linphone does this . Regards,Dragos Oancea From: Manpreet Singh <manpreets7 at gmail.com> To: opus at xiph.org Sent: Tuesday, December 16, 2014 7:54 AM Subject: [opus] Estimating bitrate during a real-time voip call Hi,

Hi guys, I'm using Opus for speech in wide-band mode (sampling rate 16000) and 20ms frames with signal type set to SIGNAL_VOICE. I have a few questions here: 1. When I choose VBR mode, the codec seems to choose the bitrate on its own. However, that seems to be an issue on mobile devices. In some cases, when I configure the bitrate to say 20kbps, I see that the outgoing codec bitrate at

For anything below 6 kb/s, I would actually recommend using codec2 rather than Speex or Opus. Cheers, Jean-Marc On 04/11/14 05:55 PM, Manpreet Singh wrote: > Hi, > > I noticed that speex.org <http://speex.org> has a banner that mentions > that Opus is better than Speex in all aspects. The supported bitrate > range for Speex seems to be as low as 2kbps though but Opus can

Hello, > 2. I don't have a good source of wav data for testing. I've noticed that > introducing bugs into speex (even gross ones like returning completely > incorrect codebook entries) tends to, sometimes subtly, degrade quality > instead of blowing up. Is there an existing set of source data - and > maybe even a test harness that will do binary comparison, so I can avoid

On 01/21/2015 07:51 PM, Daniel K wrote: > Hi guys, > > I'm using Opus for speech in wide-band mode (sampling rate 16000) and > 20ms frames with signal type set to SIGNAL_VOICE. > > I have a few questions here: > > 1. > When I choose VBR mode, the codec seems to choose the bitrate on its own. > However, that seems to be an issue on mobile devices. In some cases,

I know the focus for Opus is low delay, but I've been watching its development with interest because of the potential for audiobook/podcast use, where latency is practically irrelevant. I hear the upcoming USAC codec will give good results for this niche (though listening test results don't seem to be available to the public yet), but I also hear it'll be extremely patent

Hi, ? Is there anybody out there who can tell me how to solve the following problem: ? An RTP payload of encoded speex data is received. The length of the payload is N bytes. The length corresponds to 20ms * K of encoded audio where K is an unknown integer. The audio was encoded by an encoder in wideband mode. ? How do I partition the payload when I don't know which bitrate mode of the

Jean-Marc Valin wrote: > Hi, > > I just released unstable version 1.1.2 that contains more fixed-point > work. Though it's still not 100% complete, enough have been done to make > it run in real-time on ARM. In order to do that, compile with > --enable-fixed-point --enable-arm-asm. All narrowband modes work in > real-time with complexity 1 (some work with higher

I use the Opus multistream encoder for both mono and stereo encodings and after updating from 1.1.3 to 1.3 I noticed the size of the produced Opus files had doubled for 1-channel encodings whereas switching to the standand Opus encoder gave me roughly the same sizes as before. In these tests, I'm encoding an 8kHz mono stream containing only speech with the following options set: frame length

I am specifically using Celt Wideband (48kHz) over WiFi multicast that naturally leads to lost packets and am trying to minimize the impact to the audio. I implemented PLC but the audio it produces is robotic. Have I implemented PLC correctly? Checking the waveform it is using the previous received waveform to fill in a missing packet but not the full waveform so it has to repeat. Basically,

On Wed, 16 May 2007, Jean-Marc Valin wrote: >>> The main idea is that Speex supports many bit-rates, but for one reason >>> or another, some modes may be left out in implementations (e.g. for RAM >>> or network reasons). What we're saying here is that you should make an >>> effoft to at least support (and offer) the 8 kbps mode to maximise >>>

What do you mean by "implement"? You're just using the Opus built-in PLC (passing NULL), right? The PLC generally attempts to find periodicity and replicate it. I guess if your signal isn't periodic it can lead to a repetition that isn't great. It's something that could probably be improved in the PLC. Cheers, Jean-Marc On 08/25/2015 01:21 PM, Scott Boekweg wrote:

Hi Tom Thanks, just at the feasibility phase right now, so this sort of info is really useful. Memory/MHz values for the Tremor/Vorbis code seem to vary wildly - at least I could not find a consistent set of numbers after trawling through the discussion groups... Thanks John -----Original Message----- From: tom abcd [mailto:tom.abcd@gmail.com] Sent: 28 March 2006 16:34 To: Anderton, John

On Thu, 17 May 2007, Jean-Marc Valin wrote: >>> Consider a device that only has enough ROM to store one set of >>> quantization tables (the limitation could also be about speed, network, >>> ...). If you specify MUST be able to decode, then it means that this >>> device simply *cannot* implement the spec *at all*. This is bad for >>> interoperability.

comment inline. On Wed, 16 May 2007, Jean-Marc Valin wrote: >> Page 3: >> >> To be compliant with this specification, implementations MUST support >> 8 kHz sampling rate (narrowband)" and SHOULD support 8 kbps bitrate. >> The sampling rate MUST be 8, 16 or 32 kHz. >> >> There is a type above after (narrowband), there is a " extra

Hi Mark, Jean-Marc, Thanks for your comments. On Sun, Jun 12, 2016 at 6:34 AM Mark Harris <mark.hsj at gmail.com> wrote: > Hi Felicia, > > A few comments: > > > - /* CELT can only support up to 20 ms */ > > subframe_size = st->Fs/50; > > - nb_subframes = frame_size > st->Fs/25 ? 3 : 2; > > + nb_subframes =

Hi I was just looking at your Opus quality vs bit rate graph.? Latency looks good.? ? Two questions: 1/ Wideband: How did you address channel separation (i.e. What is the interaural time difference (ITD) granularity/resolution in microseconds? ?- assuming two channels. ) ? 2/ Narrowband: I see AMR-NB.? How does Opus compare with modern speach coding and band excitation models? I.e.