similar to: Why LSP?

Hi, I'd like to contribute to Vorbis and I think this may be of some interest for low bitrate coding. I have been experimenting with low bit-rate coding for the high-band (11 kHz to 22 kHz) and, though I haven't yet started quantizing my coefficients (a gain and an LPC filter), I expect to be able to approximate the whole 11-22 kHz band with around 1000 bits/s per channel (maybe even 500

Hi, I need a psychoacoustics model for some experiments and would like to use the one included in vorbis. Is there any documentation about how to use it? Looks like the relevent code is in psy.c, but I can't go further. Also I would like to know whether I can be of any help in vorbis. I have some knowledge in speech coding (I doing my master at the University of Sherbrooke's speech

So, it turns out (and another implementation actually explicitly mentions it) that LSP->LPC computation using the FIR algorithm is very sensitive to noise (iterative algorithm) and really really requires doubles [we're not kidding]. This was complicating things for folks pursuing fixed point implementations, and also was a potential source for bugs if FP optimizations got out of hand. This

All, Am running asterisk on an Opteron 165 with 4GB RAM and 1x80GB and 1x320GB SATA for a call center application (running VICIDIAL). Asterisk CLI (accessed by screen logging asterisk on startup and entering the allocated screen) gives me 'Warning LSP Low' and the voice quality goes down when this message pops up! That is, to start, we use: `/usr/bin/screen -L -d -m -S asterisk

Jean-Marc, Last week I tried the SVN code (build 11700) on the TI C55x DSP, and found that operation was broken again. I traced this to build 11522, committed on 5 June. The problem is in lsp.c, function lsp_to_lpc(). The line (lsp.c line 461 in build 11700): xin = 1<<(QIMP-1); /* 0.5 in QIMP format */ evaluates to zero. The following change corrects the problem: xin =

Hi, I think that the introduction of the lsp_look lookup array isn't ideal and found a better change that can be applied. in floor0_map_lazy_init() you can replace look->linearmap[W][j]=val; by look->linearmap[W][j]=vorbis_coslook(M_PI*val/look->ln); and in vorbis_lsp_to_curve you then replace float w=vorbis_coslook(wdel*k); ... }while(map[i]==k); by float w=map[i]; ...

I saw from the interview on Slashdot that there is no support for channel coupling in Vorbis. I would like to help work on that. Has anything been started about that? I don't know yet whether if could work "in real life", but I have started to work on a way to do adaptative coupling between two channels (by finding the best transformation to predict one channel from the other). I

I have noticed may broken links in the vorbis documentation. For instances, none of the links in the "Vorbis analysis and synthesis" and "Vorbis coding and decoding" sections work. Where has that documentation been? Jean-Marc Valin -- Jean-Marc Valin Universite de Sherbrooke - Genie Electrique valj01@gel.usherb.ca --- >8 ---- List archives:

Why for white-pixel image, oc_enc_fdct8x8_c() returns the matrix with non-zero AC-coefficients? _x[64]: * 107 107 107 107 107 107 107 107 * 107 107 107 107 107 107 107 107 * 107 107 107 107 107 107 107 107 * 107 107 107 107 107 107 107 107 * 107 107 107 107 107 107 107 107 * 107 107 107 107 107 107 107 107 * 107 107 107 107 107 107 107 107 * 107 107 107 107 107 107 107 107 _y[64]: * 3426

Good day! I'm creating HDL IP CORE (for using in FPGA) for theora encoder (now only I-frames). I don't undestand one moment. Now i develop such stages: 1. From RBG(byer) to YCbCr converter 2. DCT processing (8x8 pixels blocks) 3. Quantizator of DCT coeff. 4. Zig-Zag of quantized DCT coeff. and now i have uresolved last stage of compression - how i must send 8x8 blocks to huffman

One other thing that may or may not illuminate the situation. When I run under gdb (on OS X 10.8.3 this is an ancient version of gdb 6.3.5 - but it works with clang compiled C++ code) I get the following error when I try to list a line in dwarf1.lsp: Dwarf Error: Cannot handle DW_FORM_<unknown> in DWARF reader [in module /Users/meister/Development/cando/src/tests/core/dwarf1.bundle] (gdb)

Good day! I create diagram of encoder process. Using it i create implementation of encoder in FPGA (Xilinx/Altera). Please critique it. Is there missing stages? Here is blog http://developer-fpga.blogspot.com/ Here is picture of encoding stage 1 https://lh4.googleusercontent.com/-NV8o9DG3jvE/TYjYXr-dYGI/AAAAAAAAAos/U06O-YvhSI0/s1600/stage1.jpg Here is picture of encoding stage 2

Here are two optimisations for LSP : in vorbis_lsp_to_lpc, Ae and Ao are filled with zero when i increase so you can reduce the j loop, and I replaced qsort in cacm (maybe there are better algorithms, but it's already much faster than qsort on my mac) void vorbis_lsp_to_lpc(double *lsp,double *lpc,int m){ int i,j,m2=m/2; double *O=alloca(sizeof(double)*m2); double

Okay, Not exactly the answer I was looking for. This sounds like a big change. I don't mind re-writing the LSP quantizer but re-training code books and breaking compatibility is not what I want to do. I am working on an optimization for an ARM cortex-A8. It is desirable to process things in 4 element blocks. Is there a simpler approach you could recommend? Vasant Shridhar

We are pleased to announce a new stable release of libtheora, the Xiph.org Foundation's reference implementation of the royalty-free Theora video format. This new release, version 1.1, codenamed Thusnelda, incorporates all of the recent encoder improvements we have been making over the past year, though some of the code had its genesis all the way back in 2003. It also brings substantial speed

We are pleased to announce a new stable release of libtheora, the Xiph.org Foundation's reference implementation of the royalty-free Theora video format. This new release, version 1.1, codenamed Thusnelda, incorporates all of the recent encoder improvements we have been making over the past year, though some of the code had its genesis all the way back in 2003. It also brings substantial speed

This has to do with your own timezone. If I run that code on my computer, both formats are correct. If I do this after Sys.setenv(TZ = "UTC") Then: > cbind(format(dlt), format(dct)) [,1] [,2] [1,] "2016-12-06 21:45:41" "2016-12-06 20:45:41" [2,] "2016-12-06 21:45:42" "2016-12-06 20:45:42" The reason for that, is that

Hello, Jean-Marc Valin schrieb: >>I am planning on creating a steganographic extension for speex/CELP. >>Since speex/CELP is lossy, there should be quite many bits that one >>can use for hiding data. > > Quite the opposite. Speex uses very few bits, so every bit you corrupt > is likely to be heard. You would need to use "fractions of bits" at a > time.

> On 18 May 2017, at 13:47 , Joris Meys <jorismeys at gmail.com> wrote: > > Correction: Also dlt uses the default timezone, but POSIXlt is not recalculated whereas POSIXct is. Reason for that is the different way values are stored (hours, minutes, seconds as opposed to minutes from origin, as explained in my previous mail) > I would suspect that there is something more subtle

After installing R-3.4.0 I ran 'make check' which halted here: $ > tail reg-tests-1d.Rout.fail -n 16 > ## format()ing invalid hand-constructed POSIXlt objects > d <- as.POSIXlt("2016-12-06"); d$zone <- 1 > tools::assertError(format(d)) > d$zone <- NULL > stopifnot(identical(format(d),"2016-12-06")) > d$zone <- "CET" # =