similar to: CVS RC4 -q0 too good!

Caleb wrote: > i dont understand you people. >-q0 should be poor quality, only that in vorbis, the poor quality is > actually good! :) Another advantage I see in reducing the nominal bitrate for q0 to 48kb/s with a ~13khz lowpass is a smoother transition in average bitrate and frequency resolution from 22khz to 44khz sampling. Currently there is a jump from 11khz (at 22khz

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.

As a matter of interest I tested the quality at -1 which has a nominal bitrate of 45 but the 2 tracks I encoded both averaged out to exactly 48kb/s. I noticed the lowpass defaulted to 15.1khz like -q0 so that may need addressing at some stage. I used a lowpass of 13khz which overall sounded better with less artifacts. I found it sharper & clearer than a lame encoded mp3 encoded with

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

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

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 Thu, 9 Sep 2004 20:16:37 -0700 Jeff Cohen <jeffc at jolt-lang.org> wrote: > On Thu, 9 Sep 2004 08:52:10 -0700 > Jeff Cohen <jeffc at jolt-lang.org> wrote: > > > > I haven't got around to this yet but I will. The odds are good the > > > problem is in a BSD system header file so I need to capture the > > > preprocessed source. > > >

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

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

Will oggenc have a lowpass switch? I would prefer to lowpass at 15-16khz at -q3 for use with FM broadcasting. The additional frequencies would be chopped off anyway by the transmiters hardware lowpass filter so the encoder could use the addition bits for other purposes. It could be enforced that the lowpass can only be reduced and not increased from the default. This would stop people

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.

can someone email me a list of special spots in quality settings, or point me to a website that tells these settings? i know i may be confusing, i'm talking about like the jump between -q4.99 and -q5 because of the whole lossy/lossless channel coupling, and filesize jump...i also know somewhere above there there is different high and low frequency cutoffs, and a point where there IS NO

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

Hi I want to encode at 64kbps at a 22050 rate ... this is not possible ... why? For me it seems a waste of cpu to encode at 64kbps with 44100 sample rate (of course I might be wrong :). I saw in the vorbisenc.c that aprox_bitrate_to_vbr returns -1 to every sample rate that is not > 42000 ... is this safe to change ? Thanks, Nicu. <p>--- >8 ---- List archives:

Dear R Help, I read through the archives pretty extensively before sending this email, as it seemed there were several threads on using predict with GLM. However, while my issue is similar to previous posts (cannot get it to predict using new data), none of the suggested fixes are working. The important bits of my code: set.seed(644) n0=200 #number of observations

Does anyone know exactly what ComposerIndices in Target.td is all about? I see just one place where it's used in X86 but it's not clear from the comments in Target.td and it's one usage, exactly what this feature is about. Tia. Reed

I would very much like a lowpass option because for FM radio broadcasting I don't want to encode frequencies above 15khz. I'm waiting for this option before switching to ogg from mp3(lame). Ross. > -----Original Message----- > From: owner-vorbis@xiph.org [mailto:owner-vorbis@xiph.org]On Behalf Of > Gian-Carlo Pascutto > Sent: Tuesday, 4 September 2001 01:46 > To:

On Wed, Oct 19, 2016 at 4:52 AM Nuno Lopes <nuno.lopes at ist.utl.pt> wrote: > > I'm still digesting the proposal in its entirety, but one point I want > to call out here: > > > >> On Tue, Oct 18, 2016 at 1:39 PM Friedman, Eli via llvm-dev wrote: > >> Instcombine currently transforms "memcpy(dst, src, 4)" to "load i32 src; > >>

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

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