Displaying 6 results from an estimated 6 matches for "dschmidt2006".
2006 Dec 11
0
A question about speex_bits_write function
...--------------
>
> _______________________________________________
> Speex-dev mailing list
> Speex-dev@xiph.org
> http://lists.xiph.org/mailman/listinfo/speex-dev
------------------------------
Message: 4
Date: Sun, 10 Dec 2006 15:40:11 +0100
From: "Daniel Schmidt" <dschmidt2006@googlemail.com>
Subject: Re: [Speex-dev] Patch for sb_celp.c and a few questions
To: speex-dev@xiph.org
Message-ID:
<a525d69f0612100640v64ec89b6v9f9a634ff5e9ae28@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hello Jean-Marc,
thank you for your reply. I have...
2006 Dec 09
2
Patch for sb_celp.c and a few questions
Hello Jean-Marc.
First of all, thank you for your awesome work on speex!
In the current version in SVN the wideband encoder/decoder doesn't
correctly pass the parameter of SPEEX_SET_SUBMODE_ENCODING to the
underlying narrowband codec. My patch fixes this.
Then I have a question regarding the EPIC_48K mode. Should the
perceptual enhancer work with this mode? At the moment it is enabled
by
2007 Feb 01
1
Range of Speex input samples
Hello Jean-Marc.
A few weeks ago you wrote on this list:
> Samples should never reach saturation (+-32767) and should generally
> be less than 16384 to have good results.
I would like to use Speex in 8 kbps narrowband mode to compress an
audio signal (speech) with several peaks up to +-24000. Would it make
sense to reduce the volume by 3 dB before feeding it to Speex and
increasing it
2007 Mar 13
2
Resampler
Hello Jean-Marc,
I did some experiments with the fixed-point version of the resampler
in SVN. Basically it works very well, great work!
But I experienced a problem when upsampling audio data with slight
clipping. This seems to cause an overflow somewhere, resulting in
"cracks" in the output.
I'm aware that the resampler hasn't been released yet, but I wanted to
mention it. :-)
2008 Jan 01
0
Re: Problem with beta 3 jitter buffer
Hello Jean-Marc,
thank you for your reply.
> > I found the cause of the problem. The function shift_timings can
> > produce overflows in the timing array if the jitter is huge or the
> > time units are very short. After changing the timing values' type from
> > spx_int16_t to spx_int32_t it seems to work.
> Hmm, I always assumed there wouldn't be any overflows.
2007 Mar 14
2
Resampler
Hello Jean-Marc,
thank you for your answer!
> I'll look into this. There's basically no overflow prevention for now.
> I'll think about how to add that without affecting performance too much
> (on CPUs that don't have hardware saturation). I'm open to suggestions :-)
I'm not sure if I can really help, but I did a few more tests.
Reducing the volume of the input