similar to: quality scale 0-10

May I suggest that the up coming RC4 or 1.0 needs some quality selection adjustments. It has been said that if you are happy now with a particular quality setting, later releases will produce the same quality but reduce the average bitrate. This is not currently the case. IMHO -q4 in CVS is producing almost perfect results and features audio frequencies up to 21khz -- almost CD quality.

Hi all, I build successfully with speex-1.2rc2. And with speexdsp 1.2rc3, I build with i386, X86_64, armv7 and armv7s all passed. But when I build for ARM64 (for iPhone 6), it failed with: /Applications/Xcode.app/Contents/Developer/usr/bin/make all-recursive Making all in libspeexdsp CC preprocess.lo CC jitter.lo CC mdf.lo CC fftwrap.lo CC

From: Jyri Sarha <jsarha at ti.com> I optimized Speex resampler for NEON capable ARM CPUs. The first patch should speed up resampling on any platform that can spare the increased memory usage. It would be nice to have these merged to the master branch. Please let me know if there is anything I can do to help the the merge. The patches have been rebased on top of master branch in

Hi, On Sat, Mar 28, 2015 at 2:34 PM, Evan JIANG <firstfan at gmail.com> wrote: > Hi all, > > (Sorry that may be duplicated that I was not a mail-list member before, > so last mail sent failed) > > I build successfully with speex-1.2rc2. And with speexdsp 1.2rc3, I > build with i386, X86_64, armv7 and armv7s all passed. > But when I build for ARM64 (for

I am writing a long-run sound recording application using OggVorbis. The user can adjust sound quality parameter to make balance between storage space and sound quality. The input sound is 22050Hz, mono. To maximize the recording capability on a given storage volume, we want the result bitrate as low as possible. I use -q0 parameter and it produces a 32.0kbps stream. It is too high (our

I've filed a bug for aarch64 https://github.com/xiph/speexdsp/issues/7 and provided the port in a fork with a pull request. We need someone to review/merge in the pull request? It provides the source code, but my testing was under Android builds, so there would be some configure changes needed to build it stand alone. On Tue, Apr 19, 2016 at 4:32 PM, Frank Barchard <fbarchard at

On Fri, 6 Apr 2001, John Griffiths wrote: > ok so 24kbps for 56k modems... > > can i go any lower and get the 28 k modems? (still a lot of them about) or will 24 be good enough fo that? As others have said, 16kbps should do the trick. Keep in mind though that the quality of the sound will also depend on the sampling rate. MP3 will handle some higher sampling rates higher than some of

As the subject implies, my question is: is it possible to use the -b (or -M) flag at non-44K sample rates? I'm working with an application that is trying to optimize for very small audio filesize. I found that downsampling to 11K and then using q0 gives high compression, but won't seem to drop below 64kbps or so. It seems like the combination of downsampling, then reducing to 30kps

hi folks, in my (unlucky) first test of ogg vs other encoders, i found a case where wma and mp3pro sound much better than ogg at 64k. can anyone suggest a setting that i haven't tried yet that can rival the wma and mp3pro samples at 64k? it's the "gravel effect" that is troublesome. the part in question is the first 15 seconds of this wave file:

I brought this up 12 months ago or more. I believe the low-pass filter defaults too high with quality -1 in Vorbis 1.0. Is this going to change in the future? I think it should at least cut off at 15khz not 16khz and perhaps even 14khz. I believe it's important when streaming. Removing some of the higher frequencies compared to removing more of the audible sound makes more sense to me.

Boink wrote: > They're streaming only in 22050/11khz mono. > I'm doing my stream around 30 kbps/11khz in *stereo*. Just my opinion but I've found streaming with quality -1 22khz Mono produces the best sound quality for 32kb/s. 11khz stereo sounds like crap in comparison. I'm just waiting (impatiently) for OddCastDSP(v1) to support 22050 mono via the SQRSoft crossfader. If

Hi Nuno, Chandler, Nuno Lopes via llvm-dev wrote: > This program stores 8 bits, and leaves the remaining 24 bits > uninitialized. It then loads 16 bits, half initialized to %v, half > uninitialized. SROA transforms the above function to: > > define i16 @g(i8 %in) { > %v = add nsw i8 127, %in > %1 = zext i8 %v to i16 > %2 = shl i16 %1, 8 > %3 = and

ARGH! I am at a complete loss as to which OGG quality settings to use: 8? 10? 3? I'd like to be able to listen to my primarily Rock oriented music on a high-end system (though I don't own one - yet) without any noticeable sound degradation, but I don't want to go total overkill with -q 10. With LAME, I at least used to know 192 kbps with -q0 was a perfect size/quality proportion. I

>> Yes, I plan to use it in a VoIP environment if I can get latency reduced to >> an acceptable level :) >> The latency depends directly on the overlap parameter, which also controls >> the quality. Higher quality => higher latency. You could set the overlap to >> 0, but that would give you some nasty artifacts. >> You can also resample with smaller block

On Sat, 2004-09-11 at 12:49, Jeff Cohen wrote: > For the heck of it I tried upgrading to gcc 3.4.2 (from 3.3.3). It > didn't make a difference. So here are the failures for llvm-test. All > diffs are against the "native" output. > > ===================== MultiSource/Applications/sgefa > > cbe failed differently from jit/llc. First cbe: > > 84c84

On Sat, 11 Sep 2004 13:53:11 -0700 Reid Spencer <reid at x10sys.com> wrote: > On Sat, 2004-09-11 at 12:49, Jeff Cohen wrote: > > > > ===================== MultiSource/Applications/sgefa > > > sgefa is a known XFAIL. See the nightly test results over the last > several months. Actually, you should compare your test results with the > 1.3 release test results

For the heck of it I tried upgrading to gcc 3.4.2 (from 3.3.3). It didn't make a difference. So here are the failures for llvm-test. All diffs are against the "native" output. ===================== MultiSource/Applications/sgefa cbe failed differently from jit/llc. First cbe: 84c84 < One-Norm(A) ---------- 8.879153e+02. --- > One-Norm(A) ---------- 8.879156e+02.

> On 11/8/2016 3:32 PM, Sanjoy Das wrote: >> Hi Nuno, Chandler, >> >> Nuno Lopes via llvm-dev wrote: >> > This program stores 8 bits, and leaves the remaining 24 bits >> > uninitialized. It then loads 16 bits, half initialized to %v, half >> > uninitialized. SROA transforms the above function to: >> > >> > define i16 @g(i8 %in) {

From: Jyri Sarha <jsarha at ti.com> Semantics of inner_product_single have also been changed to contain the final right shift and saturation so it can also be implemented in the optimal way for the used platform. This change affects fixed point calculations only. I also added a new fixed point macro SATURATE32PSHR(x, shift, a). It does pretty much the same thing as SATURATE32(PSHR32(x,

From: Jyri Sarha <jsarha at ti.com> Also adds inline asm implementations of WORD2INT(x) macro for fixed and floating point. --- libspeex/resample_neon.h | 101 ++++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 101 insertions(+), 0 deletions(-) diff --git a/libspeex/resample_neon.h b/libspeex/resample_neon.h index ba93e41..e7e981e 100644 --- a/libspeex/resample_neon.h +++