similar to: Upsampling while decoding

Dear Nikos, thanks! But you use Opus only for resampling, not for entirely replacing Speex, don't you? Greetings! Hermie Am 07.05.2013 22:53, schrieb Nikos Chantziaras: > The Opus resampler is actually a bugfixed version of the Speex one. Same > interface/API, but with the bugs removed. It's why I recommended it :-) > Otherwise I would have recommended something entirely

Dear Nikos, thank you very much for your advice! I am not a little bit new to C++, and experiments (like using another third party library) always turn out to be days of work for me. That is why I would first like to try Speex's new internal resampling function. I am currently still using the old 1.0.4 version. I have now downloaded the new 1.2rc1 version. Unfortunately it does not want

I'm not using Opus at all. I'm just including its resampler in my own sources. It's not even a DLL; it's directly compiled together with the rest of my code. You need these sources from the opus-tools package (http://www.opus-codec.org/downloads/): arch.h resample.c resample_sse.h speex_resampler.h stack_alloc.h In your project file, define these macros: #define

The Opus resampler is actually a bugfixed version of the Speex one. Same interface/API, but with the bugs removed. It's why I recommended it :-) Otherwise I would have recommended something entirely different, like SoXR. On 07/05/13 22:12, Hermann Weber wrote: > Dear Nikos, > > thank you very much for your advice! > > I am not a little bit new to C++, and experiments

My file is 3 hours long, so decoding takes around 5 minutes on an average computer. That is a bit too long unfortunately... Am 23.12.2011 20:38, schrieb Steve Checkoway: > On Dec 23, 2011, at 10:54, Hermann Weber<hermie.weber at gmx.de> wrote: > >> And how many frames does Speex need to "recover"? >> Or is that not predictable? > No idea. My guess is not

Sorry, it seems I have only replied to Lakhdar, not to the newsgroup. Below is my reply to Lakhdar, and I would like to make it more clear now, using some pseudo values for simplicity: I read bytes 1 to 124 from my encoded spx file. I decode themt and get the values: ---Frame 1---- -293 -8234 2134 17 ---Frame 2---- -9323 -732 189 2329 Both frames are just perfect as I need them. But now when I

And how many frames does Speex need to "recover"? Or is that not predictable? Greetings, Hermann Am 23.12.2011 19:17, schrieb Steve Checkoway: > > On Dec 23, 2011, at 10:03 , Hermann Weber wrote: > >> I found out something: >> >> The more frames I decode before the frame that I actually want to >> decode, the better the quality becomes. >> For

Hello! I was using Speex all the time, and I am now moving to Opus. I had encapsulated the decoder a bit, I had the following cpp file: #include "StdAfx.h" #include "spxcodec.h" #define MAX_FRAME_SIZE 2000 #define MAX_FRAME_BYTES 2000 CSpxCodec::CSpxCodec() : enh(1), rate(8000) { } CSpxCodec::~CSpxCodec() { } void CSpxCodec::Init() { speex_bits_init(&bits);

Hello! I encoded a voice file (48kHz) with opusbin\opusenc.exe with the standard settings and decoded it. The output was amazing. I could not hear any loss at all. Then i encoded the same file with opus_demo.exe and standard settings and then decoded it. The output had a sizzling noise, even when I used full bandwidth. I think I have played around with any of the settings in opus_demo.exe,

I always assumed that ov_read_float() would get me samples in the range of [-1,1), and anything below or above that can be clamped (or clipped in the final conversion to an integer format.) However, I recently saw this: https://github.com/LaurentGomila/SFML/issues/310#issuecomment-9974550 Apparently, there are Vorbis streams that use float samples with values in the range of [-32768,

Your install dir has a whitespace. Have you tried quoting? e.g. <LLVMInstallDir>"C:\Program Files (x86)\LLVM"</LLVMInstallDir> Best regards, Rafael Auler On Mon, Sep 29, 2014 at 7:38 PM, Eric Mader <emader at gmx.us> wrote: > I changed tooset-vs2013.props to this: > > <Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003" >

Open the file toolset-vs2013.props and you'll understand what's happening and where the path is set. It tries to fetch the LLVM installation path from the Windows registry. Just fix this (maybe editing your registry or editing the .props file, whatever suits you best). On Mon, Sep 29, 2014 at 5:33 PM, Eric Mader <emader at gmx.us> wrote: > I copied the x64 toolsets by hand and

HI Hermann, I am not sure I understand exactly what you are trying to do. Let me try to describe what I understood (I assumed your byte array starts @ 1 and not 0 as it is supposed to be in C) : ############################## CASE 1: (output is good) ############################## - INITILIAZE_DECODER (reset state memory) - READ bytes 1 to 124 - SpxDecode(DinBuf, DoutBuf, unsigned int

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: >

Hello! I need to extract audio data at a certain position in respect to the original audio data. Is the "-cbr" switch meant to ensure that data can be found on a specific position? I want to be able to predict where certain audio can be found in the encoded data. An example: If you put 10 apples into a box and then compress the box, you will not be able to predict where apple C

I replaced all instances of "$(Platform)" with "x64" for the x64 .props file and it still fails, so it looks like that guess was wrong as well. Regards, Eric On 9/29/14, 2:11 PM, Eric Mader wrote: > Quoting doesn't seem to make a difference. Strangely, the Win32 > toolset seems to work. (Where "work" means that clang runs and > produces a bunch of

I was looking into adding support for FLAC in my audio library, but there's a problem. Simply adding the output of: pkg-config flac --cflags to the compiler flags so that FLAC's headers can be found will break my build with errors like: error: 'assert' was not declared in this scope The problem is that /usr/include/FLAC has an "assert.h" header. In my C++

Could someone please apply this patch to the Win32 support so that Morten and Jeff can handle the recent changes? I can't do it because I"m on the road with only email access. Thanks, Reid. -----Forwarded Message----- > From: Morten Ofstad <morten at hue.no> > To: Reid Spencer <reid at x10sys.com> > Subject: Updated LLVM Visual Studio project files > Date: Thu,

We inject a typedef for size_t here: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/Sema.cpp?revision=218230&view=markup#l206 The typedef type is determined by calling getSizeType(). SizeType is (relevantly) calculated in two places: X86_64 http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets.cpp?revision=218666&view=markup#l3512 X86_32

When I already decoded something, and the decstate is not erased or reset, shouldn't that be sufficient to decode other frames with a good quality? For example, when I have decoded 30 frames without decoding the previous frames, the sound quality may not be too good, but afterwards the decoder should (in my opinion) be in a "good" state. But when I decode other frames