similar to: running at 44.1K but with standard frame sizes

Hi Jean-Marc, On Jun 15, 2013, at 2:23 AMEDT, Jean-Marc Valin wrote: >> I'm looking at how to run Opus at 44.1K. I have flexibility in the >> frame sizes of the unencoded audio, and packet sizes on the RF link. > > You should probably consider resampling. It's not that expensive and it > would make things easy. But otherwise, see below. Yes, considering your and

Hi all, I'm implementing the opus codec for a proprietary RF link (for fullband audio) and want to make sure I understand something. The link is currently running at 44.1KHz - realtime (i.e. streaming from an A/D at one side, ultimately to a D/A at the other). Rather than muck with all the infrastructure, I'm looking at how to run Opus at 44.1K. I have flexibility in the frame sizes of

> I'm looking at how to run Opus at 44.1K. I have flexibility in the > frame sizes of the unencoded audio, and packet sizes on the RF link. You should probably consider resampling. It's not that expensive and it would make things easy. But otherwise, see below. On 06/14/2013 06:23 PM, Marc Lindahl wrote: > So, I was digging through the code, and I didn't see any attempt to

Hi Jean-Marc, On Jun 15, 2013, at 12:20 PMEDT, Jean-Marc Valin wrote: > > >> So I still wonder, if you set up a custom mode, but then had all the >> settings the same as a normal mode, would the codec perform worse, or >> the same? > > You'll have to try normal vs custom modes and choose. The only thing I'm > telling you is don't run a 48 kHz

I don't know about the input side; I have personally only experienced being bitten by the output resampler. But it seems like a safe assumption that yes, the input side is equally broken. Any resampling code found on the 'net should be suitable as long as it sounds good, doesn't take too much CPU, and is compatible with your product's licensing/distribution terms. There are

Hi Jean-Marc, I looked at that but importantly these streams need to remain absolutely independent, Further they may have been encoded at some previous time. So my question stands. Thanks, Marc On Jul 26, 2013, at 9:10 PMEDT, Jean-Marc Valin wrote: > Hi Marc, > > I recommend you have a look at the multistream API and how we use it for > surround in the Ogg Opus draft. Sounds

John, Thanks for the reply! You mentioned output sample rates should be 44100 or 48000, should I worry about input (Mic) Sample rates as well? (Currently I was requesting the sample rate on both ends to be 16000 samplesPerSecond, for ease of passing into the codec) Also, do you recommend any particular resampler that I should use, or are any of the ones out there probably okay, or should

> -----Original Message----- > From: speex-dev-bounces@xiph.org [mailto:speex-dev-bounces@xiph.org]On > Behalf Of James Stanton > Sent: Thursday, October 04, 2007 12:53 PM > To: speex-dev@xiph.org > Subject: [Speex-dev] Audio Speed Variability > > > I have a video conference like application that I've been working on for > a while now, and a recent change is

Ok. I did some quality tests. First off; never do quality tests with ints. I had serious problems interpreting my results until it dawned on me that the signal differences were just 0 or 1. So, after a lot of scratching my head, these are done comparing the result from the _float versions (which is how both resamplers work internally anyway). What I did was this: Load speex_wb.wav as one

I saw the custom API, but nothing explicitly says "CELT-only" just "custom sample rate and frame size". I'll dig further now that you've pointed me in a direction. Thanks, -a On 7/6/15, 6:18 PM, Jean-Marc Valin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > I believe what you want is called Opus custom (OPUS_CUSTOM in the > code).

A while ago someone asked about a low-pass filter for oggenc and was told to get AFsp and filter outside of Oggenc. Well, I got it, and am totally lost (It's way more complicated than SOX) so now can anyone briefly describe what type of filter I should set up (FIR, IIR, all-pole), why one is better than the other, and if you have filter coefficient files lying around (lowpass, 19 or 20 kHz

Hi, I just built a sample application with speex resampler in linux and I tried to resample 8K sine wave tone mono to 48k using speex_resample_process_int. I am using a tool called EAQUAL for audio quality. I find the quality of Speex resampler to be decreasing when I increase the quality q of the resampler init function. Can some one give me pointers regarding this?? As per the API, if the

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I believe what you want is called Opus custom (OPUS_CUSTOM in the code). With that you can compile only the contents of the celt/ directory and use it like the old CELT. Jean-Marc On 07/06/2015 06:48 PM, Andrew Lentvorski wrote: > Is there a configuration or compile flag that lets me disable the > SILK portion of the codec and use CELT

On 06/15/2013 12:00 PM, Marc Lindahl wrote: >> Do not do that, ever. Everything is calibrated for 48 kHz and you >> will likely cause audible noise. > > How would it cause audible noise, I don't understand that part? > After all the frequency calculations are off by 8%, that's not too > extreme... Well, the encoder is designed to follow the ear's response and

Marc Lindahl wrote: > Of course, I'm setting up a bunch of tests to evaluate these, what I was asking was more along the lines of, > If you set up the same exact, including the sample rate, do you get the same results (e.g. same code path, calculations, etc.?) If you configure a custom mode with the standard parameters (48 kHz sampling rate and a frame size of 120, 240, 480, or 960),

Premkiran Mannava a ?crit : > I just built a sample application with speex resampler in linux and I > tried to resample 8K sine wave tone mono to 48k using > speex_resample_process_int. I am using a tool called EAQUAL for audio > quality. That's in general not very reliable. You can get PEAQ to say all sorts of silly things. > I find the quality of Speex resampler to be

Hi Jean-Marc, I use the resampler to convert various sampling frequencies to 48 kHz on my Blackfin platform (fixed-point) 48K -> 16K speex -> 48K chain does not sound very good compared to plain 16K. But the main issue is when processing loud signals, I have truncation (and not clipping/saturation) I could hear it and see it with various music and speech messages. See example.png. I also

Hi, *"That's in general not very reliable. You can get PEAQ to say all sorts of silly things." Can you provide me links for any more effective tools other than PEAQ? Which is more reliable for Speex resampler? * *"strongly suspect that it's just not compensating for the delay introduced by the resampler. Because higher quality means higher delay, you'd find that PEAQ

Hi Marcus, Thanks for the fixes. I did some more cmake build testing and encountered a few issues: The option -DFORTIFY_SOURCE=2 should be -D_FORTIFY_SOURCE=2, as the macro has a leading underscore. In the autotools build it defines this if it is not already defined (m4/ax_add_fortify_source.m4). When custom modes are not enabled, the cmake build is nevertheless installing the include file

Hey guys. I think Vorbis is pretty cool, but since the current OggEnc only offers 44.1kHz, it limits what I wanted to use it for. So I've been using Lame to get 16kHz mono Vorbis files. I'm curious about whether Lame does Vorbis encoding the "right" way for non-44.1k stuff, or whether it just encodes as it would for 44.1k & changes the sample rate on the output, but I'm