similar to: How frequently should Opus Control Parameters be modified?

On 13/05/14 01:36 AM, Amit Chowdhary wrote: > 1) Any suggestions on how often I should change the bit-rate and > expected packet loss, (maybe even lower the audio bandwidth if the > bit-rate available is below the sweet-spot for WB)? > > 2) How is the codec's performance affected every time a control parameter > such as bit-rate or audio bandwidth is changed? > Would

Hi guys, as MP3 and Opus have very similar objectives, I think the original poster's question was a valid one: Why does Opus have more artefacts in the lower frequency ranges than MP3 has? The spontaneous suspect that lower frequency artefacts may be more noticeably than higher frequency artefacts seems plausible, also. Is it a matter of energy (which is higher for higher frequencies)? When

Jean-Mark sarkasm. Jean-Markasm. (Bonus points for providing an actual noisy WAV! ^_^) On 30/10/2017 20:28, Jean-Marc Valin wrote: Hi, Before I comment on the graphics you posted to visualize the difference between two audio signals, I'd like to ask for your help in evaluating my JPEG encoder. I've encoded an image with JPEG and then computed the difference with the original. I then

Hello Daniele It would be worthwhile to attach an external serial flash or USB thumb drive, if the intent is store data. This allows for far more flexibility in storage Regards Amit On Fri, Aug 26, 2016 at 11:02 AM, Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: > On 26/08/16 11:40 AM, Daniele Barzotti wrote: > > You're right! I forgot to say that I need only the encoder

Hello. Me again. Have you tried to encode piano solo? Noticed high bitrate Opus gave? And there's also artefact at 15kHz which wasn't in the original audio. Visible with Spek program. Download FLAC and Opus both files, new link: http://www.filedropper.com/example_3 FLAC full: 1084 kbps; FLAC solo: 465 kbps. with --bitrate 160: Opus full: 158 kbps; Opus solo: 190 kbps. Included also Spek

On Sep 20, 2013, at 1:19 PM, Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: >> I wasn't sure what bit rate was appropriate for "Very high quality" >> with opus, i.e. something that was "commonly indistinguishable from a >> WAV file". Any advice on that is appreciated. > > I would tend to recommend using around the same bitrate for Opus as

Hi Jean-Marc, thanks a lot for your reply. > Well, the first question is whether you want encoding, decoding, or > both. If there's one you don't need then you can remove that > (unfortunately, there's no easy way right now). You're right! I forgot to say that I need only the encoder side (and only for voice). My application have to acquire a 16bit 8KHz PCM stream and

Hello Jean-Marc, As an example, I am using the output of opus encoder to store the file as the following format and read back the same during decode process, without having much overhead. (Thought it would be useful to put a picture rather than running text) [image: Inline image 2] Regards Amit On Thu, May 12, 2016 at 10:47 AM, Amit Ashara <ashara.amit at gmail.com> wrote: > Hello

On 05/12/2016 10:35 AM, Amit Ashara wrote: > For HMI panels, except for the capture pattern and a single page segment > entry, other fields are not important, and which results in almost 7% > overhead for a 20ms raw frame encoded with Opus. I'm not sure how you get a 7% overhead. In most uses I've seen, the overhead is more around 1%. > At the same time the > file

The overhead of Ogg (in file size) is pretty small and it's efficient enough for most applications (and uses far less CPU than the codec anyway). If anything, you might want to look at optimizing the existing Ogg implementation (e.g. like Tremor did in the context of Vorbis). Of course, you're always free to design a new container, but I doubt it's worth it and it's a lot of work

On 05/11/2016 12:35 PM, Amit Ashara wrote: > I ran the opusenc.exe on a wave file and checked the OpusTag section. My > concern is on Total Segment Size being >> than the actual data being > put. Is this just an example of implementation or does a size of 764 > BYTES kept as a place holder for putting more data? Yes, opusenc does reserve some space in the header so that tags can

Hi Jean Marc, please find attached the audio file (mono 16khz). I shortened it to about 10 seconds. I also add 2 patches that worked for me. Further info that might help: - The problem seems to be related to silk_burg_modified not reaching the maximum gain, so the actual filter order is 16 rather than 2 (which is what would be expected with a sine wave). - The problem seems to happen when

Hello Thomas and Amit, Thanks for your notice and the detailed decode performance report. I describe the details of my encode/decode test on STM32F407ZG. A. opus version: latest 1.2.1 (TI: opus 1.1.2) B. KEIL 5.23 (TI: ARM compiler tool chain 5.2.7) C. setup the encoder as the below (fs is the sampling frequency) enc = opus_encoder_create(fs, chans, OPUS_APPLICATION_AUDIO, &opus_err);

Hi Amit, I'm not sure what you're trying to ask, but the reserved space in the header is an optional thing. Encoders are free to do it, but are not required to do so. Jean-Marc On 05/11/2016 01:32 PM, Amit Ashara wrote: > Hello Jean-Marc, > > So for the moment we can assume that this method is also OK to use? > > On Embedded Systems, both SRAM and Flash can be a

>>> Amit Ashara <ashara.amit at gmail.com> schrieb am 11.05.2016 um 19:32 in Nachricht <CAEyg9sjvTWMBMMCJ8HQcYmbv1BtNt54CgpqWaGNm02MWrKcxaQ at mail.gmail.com>: > Hello Jean-Marc, > > So for the moment we can assume that this method is also OK to use? > > On Embedded Systems, both SRAM and Flash can be a restricting factor > besides the compute time. To

Hi All. I have an application where the sample rate of the sender and receiver can vary by a small margin and the latency needs to be maintained within bounds and can't drift significantly and the system has to be able to cope with clock mismatches up to 0.5%. For example, the sender may have a clock rate of 48.1kHz and the receiver may have a clock rate of 47.9kHz. Unfortunately the clock

Hello Giovanni, I am running both Opus Encoder and Decoder on a TI Cortex M4 core without any issues. What is the specific issue that you are facing? Can you explain? Regards Amit -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/opus/attachments/20160105/0bc0bc2c/attachment.htm

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

I wonder if anybody try to compress a pure sine wave using OPUS codec. When I compressed the mono 1KHz, 16bits 48000 samples per sec. audio stream using the 'opus_demo' utility: opus_demo -e audio 48000 1 2min_1kHz_Sine_16bit_48kHz.wave 2min_1kHz_Sine_16bit_48kHz.opus_raw I had the output stream that is shown below. 00 00 00 01 00 00 00 00 78 00 00 00 01 00 00 00 00 78 00 00 00 01 00

Hi, Apologies if this is a known issues, but I have found what I believe is a bug in the fixed point implementation of the Silk codec and could not find any mention on this in the archives. The bug can be easily reproduced with the fixed point demo program (./configure ?enable-fixed-point ?disable-float-api && make) using the following command: ./opus_demo voip 16000 1 23000