similar to: Opus Codec Documentation

Hello All, Turned out to be a coding error. The modified buffer was not being allocated to write back to the File System. After correction the mono 8 and 16 bit for 8K-48K works well now. Regards Amit On Mon, Jan 11, 2016 at 11:05 AM, Amit Ashara <ashara.amit at gmail.com> wrote: > Hello Mark, > > The resulting 8 bit file has a lot of squelching noise compared to the 16 > bit

Hello Benjamin, The original WAV file I have is linear 8-bit PCM. I want to ensure that original linear formats are kept as is. Later I will add support for ulaw. Regards Amit On Fri, Jan 8, 2016 at 5:34 PM, Benjamin Schwartz < benjamin.m.schwartz at gmail.com> wrote: > Do you really need linear 8-bit PCM or do you want ulaw? Linear 8-bit is > ... pretty rare. > > On Thu,

Hello Mark, The resulting 8 bit file has a lot of squelching noise compared to the 16 bit output from OPUS decoder. During encode I am using popi16fmtBuffer[ui32Loop] = (opus_int16)pcRdBuf[ui32Loop]; And during decode since the data is in the lower 8 bit I use pc8bitSamples[ui32Loop] = ((unsigned short)pcop16OutBuf[ui32Loop] ^ 0x80); Regards Amit On Sat, Jan 9, 2016 at 2:39 PM, Amit Ashara

Hi all, thanks a lot for your replies! Sorry for my typo, the flash size is 8MB (Byte) :-) Unfortunately I cannot use another flash because I'm working on a proprietary board. Jean-Marc, thanks for your suggestions. I thought to use fixed point for convenience, but I can work on floating point too, so I will take in account the codec2 (I didn't know it). Moreover, if you all have

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

The format you're describing here actually has *more* overhead than Ogg, not less. It's also unseakable, not robust errors, and without support for metadata. I'm not sure why you would want that. It's not like you're forced to include much data in the Ogg metadata (which seems to be the source of all the overhead you're seeing). Jean-Marc On 05/12/2016 11:51 AM, Amit

>>> Amit Ashara <ashara.amit at gmail.com> schrieb am 12.05.2016 um 17:47 in Nachricht <CAEyg9sgjbsxQY-=VnhQrKiGeTcFSRr1wxOPUhNyCQF8Piuahow at mail.gmail.com>: > Hello Jean-Marc, > > Assuming that a 48KHz, 20ms 8-bit linear PCM data which is 960 bytes is > compressed to 64 bytes (for assumption). The with the Oggs header (4 byte) Actually what I don't

Hello Jean-Marc, Assuming that a 48KHz, 20ms 8-bit linear PCM data which is 960 bytes is compressed to 64 bytes (for assumption). The with the Oggs header (4 byte) + 1 segment entry (which is the size of the segment itself) + 64 bytes will amount to (4+1)/(4+1+64) = ~7.2%. This when compared with the original Oggs container itself for the same data payload size (26+1)/(26+1+64) = ~29.6%. Even if

Hello Ulrich 20ms is the size of each frame. The overall sound clips may be 0.25 - 0.75 secs each. Regards Amit On Fri, May 13, 2016 at 2:15 AM, Ulrich Windl < Ulrich.Windl at rz.uni-regensburg.de> wrote: > >>> Amit Ashara <ashara.amit at gmail.com> schrieb am 12.05.2016 um 17:47 in > Nachricht > <CAEyg9sgjbsxQY-=VnhQrKiGeTcFSRr1wxOPUhNyCQF8Piuahow at

Hello Ralph, > Likewise opus_encode() takes 16 bit samples, so you need to extend each > sample from an 8 bit source before encoding. Two questions 1. In opusenc.c which API does the extending the 8-bit to 16-bit? 2. If that is the case then how will 24 bit PCM sample work? Regards Amit On Thu, Jan 7, 2016 at 12:21 PM, Ralph Giles <giles at thaumas.net> wrote: > On 07/01/16

Hi Amit, issues I'm facing now are int overflow and memory management. I'm working on it. I'm working on the tms320c5515 evm board. Best regards, Giovanni. On 5 January 2016 at 18:40, Amit Ashara <ashara.amit at gmail.com> wrote: > Hello Giovanni, > > I am running both Opus Encoder and Decoder on a TI Cortex M4 core without > any issues. What is the specific issue

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

Hello everyone. I would like to use the opus codec in the following scenario: the PCM audio signal, coming from bluetooth module is captured by STM32F446 MCU and then decoded by opus codec. However, I don't know where to start to build the opuslib for ARM Cortex-M4. Could someone provide any hints or give any brief guide on this? WBR, Aleksandr -------------- next part -------------- An

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

Hello everyone. I would like to use the opus codec in the following scenario: the PCM audio signal, coming from bluetooth module is captured by STM32F446 MCU and then decoded by opus codec. However, I don't know where to start to build the opuslib for ARM Cortex-M4. Could someone provide any hints or give any brief guide on this? WBR, Aleksandr -------------- next part -------------- An

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

Hello All When sending the Opus Packet in RTP Payload, the compressed frame is the output of the encoder? Also the config value as given in the RFC6716, 16...19 | CELT-only | NB | 2.5, 5, 10, 20 ms 16 corresponds to 2.5 ms 17 corresponds to 5 ms 18 corresponds to 10 ms 19 corresponds to 20 ms Is this correct representation of the data? Also in the RFC3551 the payload

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);

Hello Jean-Marc, I suspected the answer to be No. 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. At the same time the file processing complexity is way too less considering that CRC's do not not need to be considered (programmer pods ensure that)

Hello All I have successfully run the Opus Decoder for 16-bit WAV files. However when doing the same on 8-bit, the decoder produces noise, but on 16 bit data the output is working. Both the 8 and 16 bit files are from the same source and hence except for some loss of quality on 8 bit, they are identical in total play back duration. For both 8 and 16 bit data I have used the following parameters