similar to: Dequantizing

Full_Name: Jerome Asselin Version: 1.6.2 OS: RedHat Linux 7.2 Submission from: (NULL) (142.103.173.179) In the following example, the line type lty=2 does not show properly across the entire line. x <- c(seq(0,.5,.001),seq(.6,1,.1)) y <- rep(1,length(x)) plot(x,y,type="s",lty=2) Sincerely, Jerome Asselin

Dear all, I have been trying to understand what runif() is telling me. I am generating lots of numbers (billions and billions (wow, I''ve dreamed about saying that for many years... :-) ), for a distribution that has the following quantile function: 1 / (2 * sqrt(1 - p)) (that is, the distribution has a lower cutoff) As you can imagine, this has rather heavy upper tail. I was

Hello, I wanted to know if there was way to convert a histogram of a data-set to a kernel density estimate directly in R ? Specifically, I have a histogram [bins, counts] of samples {X1 ... XN} of a quantized variable X where there is one bin for each level of X, and I'ld like to directly get a kde estimate of the pdf of X from the histogram. Therefore, there is no additional quantization of

Hi all, When trying to better understand the way LPC exactly works, I stumbled upon something which, after some digging, was already reported and (partly) fixed: https://sourceforge.net/p/flac/bugs/424/ Apparently, the FLAC specification has a LPC shift that can be both positive and negative, but the encoder specifically makes sure that only positive shifts are encoded and the decoder only

Refs http://sourceforge.net/p/flac/bugs/424/ --- doc/html/format.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/html/format.html b/doc/html/format.html index 8598941..2ce82c2 100644 --- a/doc/html/format.html +++ b/doc/html/format.html @@ -1578,7 +1578,7 @@ &lt;5&gt; </td> <td> - Quantized linear predictor coefficient shift needed

I am also philosophically opposed to changing the specification. That said, there's nothing wrong with adding a note to the specification about the common implementations, particularly the reference library. Then, future developers will know both the precise specification and still have the warning that they risk incompatibility by deviating from the reference implementation. I own devices

Yes, this is such a case. However, implementing this in a future encoder/decoder would break compatibility with most (likely all) existing decoders, and only in some very, very rare cases where the material is such that the encoder chooses to use negative shifts, which makes it even harder to troubleshoot. Furthermore, as this can only be used in very rare cases, there is no benefit from allowing

Thread-split from the vorbis-mailing list ("Vorbis determined to be as good as MPC at 128 kbps!") <p>On Sun, 30 May 2004, Segher Boessenkool wrote: [Steven So] SS>> If iTunes AAC can encode castanets with much less pre-echo at SS>> ABR 128 kbps, then hopefully there will be an imaginative SS>> (and non-patented) way of doing this in Vorbis without the SS>>

I've made a block diagram of the encoder because I tried to find out, how it works http://stoffke.freeshell.65535.net/ogg/block.html Although there are specifiation docs, that give very detailed information about single aspects of the encoding (or decoding) , I'm missing documenations that give a more general overview, about how the encoder works. (Vorbis Illuminated seems a bit

I am, as this question will make very obvious, not exactly a guru when it comes to audio under Linux. I'd like to record some prompts using a nice microphone and my Ensoniq sound card, and then convert them to gsm/wav for use with asterisk. What Linux command would I use to a) do the recordings, and then b) convert them to the appropriate formats? I know there are

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear Celts, I've become intrigued by the problem of spherical quantizers, so I decided to see if I could come up with something better than PVQ. What I wound up writing is something I call an "octagon quantizer. In two dimensions, PVQ uses a "diamond" (square) shape. An octagon code (OVQ) uses an octagon, which is a much better

On Thu, Jan 16, 2014 at 5:32 PM, Tobias Grosser <tobias at grosser.es> wrote: > On 01/17/2014 02:17 AM, David Blaikie wrote: > >> Right - you usually won't see a normal distribution in the noise of test >> results. You'll see results clustered around the lower bound with a long >> tail of slower and slower results. Depending on how many samples you do it

I'm trying to understand the residuevqtrain program, and I have some questions for Monty, Erik, or anyone that understands how it's supposed to work. I captured TRAIN_RES data from an encoding of a single track (about 4:43), producing two files, residue_0.vqd (3727 lines, = 3727 points?) and residue_1.vqd (huge). I then did a run with the parameters from the usage message

Hi all. I'm starting to study how speex works because I would like to understand in deep how a CELP coder/decoder works. I have some difficult understanding the vector quantization performed in the split_cb_search_shape_sign function. It's a bit hard to understand. Could you please explain me the algorithm step by step? I'm indagating the 5950 bps narrowband. Thank you. Gio.

I'm copying the flac-dev list to see if anyone has any feedback also... --- Juhana Sadeharju <kouhia@nic.funet.fi> wrote: > Hello again. I had time to check the paper out. I have filled the > steps given in the paper with formulae, and then written a piece of > C code. It is not complete code, but could be a reasonable start. > Maybe there is one typo in the paper -- I have

I have two vectors, a and b. b is a text file. I want to find in b those elements of a which occur at the beginning of the line in b. I have the following code, but it only returns a value for the first value in a, but I want both. Any ideas please. a = c(2,3) b = NULL b[1] = "aaa 2 aaa" b[2] = "2 aaa" b[3] = "3 aaa" b[4] = "aaa 3 aaa"

Hi. I have been talking with Psytel MPEG-4 AAC developer (www.psytel.com) about various compression formats, and to make it short he said that one of the main drawbacks of Vorbis is its vector quantization - it introduces more error then other quantization methods (like non-uniform scalar quantization, if I got it right), probably used in AAC and other similar codecs. I know vector quantization

NSQ_LPC_BUF_LENGTH is independent of DECISION_DELAY. --- silk/define.h | 4 ---- 1 file changed, 4 deletions(-) diff --git a/silk/define.h b/silk/define.h index 781cfdc..1286048 100644 --- a/silk/define.h +++ b/silk/define.h @@ -173,11 +173,7 @@ extern "C" #define MAX_MATRIX_SIZE MAX_LPC_ORDER /* Max of LPC Order and LTP order */ -#if( MAX_LPC_ORDER >

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

I recently traced a bug of mine to the fact that cumsum(s)[length(s)] is not always exactly equal to sum(s). For example, x<-1/(12:14) sum(x) - cumsum(x)[3] => 2.8e-17 Floating-point addition is of course not exact, and in particular is not associative, so there are various possible reasons for this. Perhaps sum uses clever summing tricks to get more accurate results? In some