similar to: Info OPUS encoder

Hello, I just started into the world of OPUS. I would like to know what is the best way to build the Opus library and Opus tools on a Windows 7 pc. I see that the Opus library and the Opus tools packages have a few Makefiles. It also mentions mingw as an option for building. Is it somewhere explained what are the steps needed, or does anyone have some tips? Thanks, Met vriendelijke

Hello, I am interested in porting OPUS to an embedded platform. The idea is that the encoder and decoder will run on different processors. In order to choose the proper platform, I need an estimate of the resources which are needed for OPUS. I read the following in the OPUS wiki: "The Opus code base is written in C89 and should run on the vast majority of recent (and not so recent) CPUs.

Hi all, I am interested in using the OPUS codec for real-time application on an (preferable low-profile) platform. In order to choose the optimal processor (memory size, speed,...) I have the following questions: - We have compiled OPUS on a PC with Linux OS and on a dual-core Cortex A9 with Linux Kernel. Can OPUS run on a processor with no specific OS, or are there

The e-mail sent to you contained an attachment with a not allowed filetype. Please inform the sender to pack this type of attachment into a password protected ZIP-archive. Eine an Sie gesendete E-Mail enthielt einen nicht erlaubten Dateianhang. Bitte informieren Sie den Absender, diese Art von Anhang kann nur als Passwort gesch?tztes ZIP-Archiv versendet werden. Details: Sender:

Hello All, We have been doing an optimised port of OPUS to a ARM Cortex A9. We are currently measuring between 20 and 90 MCPS for our code running on a Panda board (single core), this covers all bit-rates,sample rates for stereo coding (encode + decode) under normal operation. As Marc says complexity can be controlled via the API with our higher figure corresponding to the default setting of

Dear Christian van Bijleveld, You can use any of the below DSPs of Texas Instruments 1. TMS320C674x - This supports floating point implementation of opus 2. TMS320C66x - This supports both floating and fixed point implementations 3. TMS320C64x - This supports only fixed point implementation Regards, Mahantesh On Mon, May 13, 2013 at 10:12 PM, <opus-request at xiph.org> wrote: >

I have just started trying Opus with a view to using it in a project. I am interested in embedded hardware and tried it on the Raspberry Pi using the raspbian distro. The version of libopus in the repos is 0.9.14. I installed this and tried encoding 2 minutes of speech from a librevox recording. It managed this at a respectable pace for complexity 10: Skipping chunk of type "LIST",

Christian, I will give 64kbit/s a try and post the figures. My own project is voice only and requires low bitrate so was hoping that it was just the way I was compiling and not an actual regression in speed for SILK. The raspberry PI is quite a cheap and handy reference platform though the ARM side is fairly underpowered but has a great GPU. It also has no audio in which is a pain for playing

Hi Stuart, you are compressing it at 6kbit/s. Then, then SILK mode is probability used and the Silk mode is much faster than CELT. Do you also some figures at 64kbit/s? It is strange that Opus 1.1 got slower in the Silk mode - may the speech/voice selection adds some overhead. I would be interested in seeing the performance of the 64 kbit/s in both Opus 1.0 and Opus 1.1. With best

I had expected that the default bitrate for the encoder would be the same as setting it to OPUS_AUTO, but I'm getting difference results: >opusenc --comp 4 sample.wav sample.opus Encoding using libopus 1.3-rc2 (audio) ----------------------------------------------------- Input: 8 kHz, 1 channel Output: 1 channel (1 uncoupled) 20ms packets, 25 kbit/s VBR Preskip: 312

Resampling to 48khz speeds them both up but the disparity is about the same: 2.609 to 3.69. Best Regards, Stuart Marsden On 17 December 2013 17:04, Stuart Marsden <stuartmarsden at finmars.co.uk>wrote: > Christian, > > Complexity 0, 6kbps: > > 0.9.14 Speed 5.204 > 1.1 Speed 5.218 > > A slight win on that run but they vary enough to say about the same. At >

I've a matrix like this: 1985 1.38 1.27 1.84 2.10 0.59 3.47 1986 1.05 1.13 1.21 1.54 0.21 2.14 1987 1.33 1.21 1.77 1.44 0.27 2.85 1988 1.86 1.06 2.33 2.14 0.55 1.40 1989 2.10 0.65 2.74 2.43 1.19 1.45 1990 1.55 0.00 1.59 1.94 0.99 2.14 1991 0.92

Hi, I'm playing around using Opus in a 'chunked' streaming context, where chunks of media are served in separate HTTP responses. I am trying to hunt down the source of some clicks-and-pops during playback, and while it is very likely that these glitches are due to the low quality of my code, I wanted to ask if the admonition in the API docs[1] that "encoder state *must*

On Wed, Oct 07, 2015 at 05:35:36PM +0200, Geert Stappers via Syslinux wrote: > On Wed, Oct 07, 2015 at 08:55:53AM -0500, Clements, James wrote: > > On Wed, Oct 07, 2015 Geert Stappers wrote > > > 13:36:47.964636 IP 192.168.205.1.47973 > 192.168.205.50.1938: UDP, length 30 > > > 13:36:47.964685 IP 192.168.205.50.1938 > 192.168.205.1.47973: UDP, length 4 > >

Hi! Playing with Opus 1.3 I converted a tone sweep with a sample rate of 96kHz (just for fun). Before I had converted that from WAV to FLAC, and to Vorbis without problems. With Opus I noticed that the file size for 48kHz and 48 kbps compared to 96kHz Vorbis at 31kbps is about double the size and it sounds even worse (than Vorbis) (there is a lot of noise in the lower frequencies when a low

David Holroyd wrote: > My code does not recreate encoder state per-frame, but it does create > new state at the start of each 'chunk' (where a chunk is 1 second of > consecutive Opus frames, right now). Is this an unsupported use of the > codec (and therefore a potential source of my issue), or should this > have little impact on the output other than reduced efficiency?

Hello!, i've just compared the 1.0.3 release with the master branch on a BeagleBone Black (AM335x 1GHz ARM Cortex-A8 with NEON floating-point accelerator) and Arch Linux ARM. At the moment I dont no why, but I see that 1.1 is much slower in encoding. Are there any default changes, that I missed and could explain this? Normaly I suggested a better performance with 1.1 and the ARM

On 07/13/2014 10:54 AM, syslinux-bot for Gene Cumm wrote: > Commit-ID: 3741886cb700e1017d70f1753f013fa10f4d9272 > Gitweb: http://www.syslinux.org/commit/3741886cb700e1017d70f1753f013fa10f4d9272 > Author: Gene Cumm <gene.cumm at gmail.com> > AuthorDate: Sun, 13 Jul 2014 11:18:50 -0400 > Committer: Gene Cumm <gene.cumm at gmail.com> > CommitDate: Sun, 13 Jul

On Aug 07 08:30:31, hans at stare.cz wrote: > On Aug 07 00:41:52, petrparizek2000 at yahoo.com wrote: > > ????#1. To test encoding at low bitrates, I encoded a sine sweep at 12 kbps > > with Opusenc and then decoded the resulting file with Opusdec. > 1) Opusenc --bitrate 12 --downmix-mono Sweep50.wav Sweep50.opus Why are you using a stereo file containing the same sweep in both

On 13-08-14 10:09 PM, Bob Estes wrote: > I've been studying the Opus code and documentation for a while and have > seen it mentioned several times that Opus uses pre-skip to allow the > codec to converge. What convergence are they referring to? Rate > control? Energy envelope prediction after seeking? Not rate control, but there are a number of predictors running in the