similar to: Channel Mapping Family for Ambisonics

Hi, Ambisonics are good for the recording but what is about the playback? In addition to an Ambisonic channel mapping, isn't it worthwhile to think about some object based audio coding, too? But then again, that would be much more work than just adding a new channel mapping. Christian > Michael Graczyk <mgraczyk at google.com> hat am 18. April 2016 um 04:29 >

On Tue, Apr 19, 2016 at 10:20 AM, Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: > So the important question is "can an existing decoder (assuming it knows > about the ambisonics channel mapping) decode your file?". If the answer > is yes, then it's just an encoder-only change and it's easy to add to > the code base. If the answer is no, then it's actually a

Hello Tim and others, Thanks for your help explaining this process on IRC. I wrote out a first draft in the RFC xml format. I have attached the xml (labeled as xml.txt so it will appear inline) and the rendered txt files. Please let me know where I can make improvements. I will upload this draft to the IETF datatracker and send it out to codec@ after addressing your comments. -------------- next

Tim, Would you mind giving me a more specific example of the sort of document that you think this should look like? I'd like to write up something that is somewhat final. On Mon, May 2, 2016 at 9:30 PM, Michael Graczyk <mgraczyk at google.com> wrote: > On Fri, Apr 29, 2016 at 4:32 PM, Timothy B. Terriberry > <tterribe at xiph.org> wrote: > > As a general point,

On 19/04/16 12:17 PM, Timothy B. Terriberry wrote: > We should probably start keeping track of the space of invalid TOC > sequences somewhere global so that people don't define conflicting > extensions. I started such a page at https://wiki.xiph.org/OpusExtensions -r -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type:

On Mon, Apr 25, 2016 at 9:32 AM, Timothy B. Terriberry <tterribe at xiph.org> wrote: > Jean-Marc Valin wrote: >> >> Would it make sense to allow an arbitrary number of channels and just >> "truncate" the list of channels. For example, two-channel ambisonics >> would be W plus X and three-channel would be W, X and Y. The idea is >> that you would get

Hi Michael, On 04/25/2016 05:32 AM, Michael Graczyk wrote: > Channel Mapping Family 2 > > Allowed numbers of channels: (1 + l)^2 for l = 1...15. > > Explicitly 1, 4, 9, 16, 25, 36, 49, 64, 81, 100, 121, 144, 169, 196, > 225. Ambisonics from first to fifteenth order. Would it make sense to allow an arbitrary number of channels and just "truncate" the list of

On Sat, 28 May 2016 16:21:33 -0700, Michael Graczyk <mgraczyk at google.com> wrote : > Hi Marc, Hi Micheal. > On Sat, May 28, 2016 at 10:44 AM, Marc Lavallée <marc at hacklava.net> > wrote: > > I subscribed because your discussion on the IETF draft ("Ambisonics > > in an Ogg Opus Container") was mentioned on the sursound list. > > Thanks for

Hi Opus list. I subscribed because your discussion on the IETF draft ("Ambisonics in an Ogg Opus Container") was mentioned on the sursound list. I tried Opus for ambisonics more than a year ago. It does works with uncoupled channels (I had to patch the encoder). I don't know what else could be done to optimize support for ambisonics, as I'm not a codec expert. So I think that

Hello Jean-Marc, Thanks for the quick reply and comments. On Thu, May 26, 2016 at 5:41 PM, Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: > Hi Michael, > > Here's some more minor comments below. As long as you address the two > comments from my previous email (254 -> 2 and the draft name), the draft > is good for submitting as initial version on the IETF website (even

Here is the modified patch. I added a flag to configure.ac which is set to 0 to disable ambisonics, and 1 to enable it. Right now the implementation simply creates a surround encoder with N uncoupled streams. Thanks, Michael Graczyk -------------- next part -------------- An HTML attachment was scrubbed... URL:

On 04/17/2016 10:29 PM, Michael Graczyk wrote: > Based on my reading of the libopus code and the IETF spec, it seems one > reasonable option would be to add a new "Channel Mapping Family" for > ambisonic audio [2]. The mapping family would indicate to the decoder > that the audio is ambisonics and the channel mapping array would > indicate which ambisonic channel (W, X, Y,

Michael Graczyk wrote: > As for mixing matrices, we are not confident in any choices for setups > beyond stereo. Although there have been papers and studies on Okay, better to give no advice than bad advice. > provide only a stereo downmixing matrix. It looks like this would go > in 5.1.1.5? The matrix should be As a general point, it's too late to add anything to the soon-to-be

This patch adds top level functions to create an ambisonic multistream encoder. The implementation currently just calls the analogous surround sound functions with channel mapping 255 to create an encoder that bundles uncoupled streams. Forthcoming patches will actually set channel bitrate and other configuration. My main concern is that adding additional

Friendly ping for the opus-tools patch... ---------- Forwarded message --------- From: Drew Allen <bitllama at google.com> Date: Mon, Mar 19, 2018 at 2:53 PM Subject: Re: [PATCH] Support for Ambisonics To: opus at xiph.org <opus at xiph.org> On Mon, Mar 19, 2018 at 11:52 AM Drew Allen <bitllama at google.com> wrote: > Hello all, > > Sorry for the delay (got really

This patch adds a static bitrate allocation for ambisonics encoded with the multistream API. We allocate 4 bits to the mono channel (channel index 0) for every 3 bits allocated to other channels. The allocation is static because it does not depend on the input audio. This patch also forces the underlying encoders to use CELT only for ambisonics. -- Thanks, Michael Graczyk -------------- next

Since the opusenc and opusinfo changes were independent I split them up and landed the opusinfo changes (with updated mapping family numbers). - Mark On Thu, Sep 6, 2018 at 4:22 AM, Mark Harris <mark.hsj at gmail.com> wrote: > Hi Drew, > > Sorry for the delay. > > FYI the patch that you attached is not your latest version. This > thread that you replied to is an older

Hi Andrew, I suspect that the configure option should be enable-ambisonics (instead of enable_ambisonics), but for each of opus, libopusenc, opusfile and opus-tools git repos (on master branch), when I try "./configure --enable-ambisonics", I get this error message: configure: WARNING: unrecognized options: --enable-ambisonics Thanks for your help. Marc Le 19-12-18 à 11 h 52, Andrew

I compiled the latest (git master) of opus, libopusenc, opusfile and opus-tools: $ opusenc --version opusenc opus-tools 0.2-8-g4976421 (using libopus 1.3.1-4-gad8fe90d) I tried to encode a 3rd order Ambisonics wav file with the standard Ambix (ACN-SN3D) format; opusinfo is reporting : Streams: 16, Coupled: 0     Channel Mapping Family: 255 Map: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14,

Unfortunately, ambisonics aren't exposed in opusenc yet, thus the trouble. They're an API-only feature, but it's a good time to discuss what such a command-line interface would look like, notably: how to specify multiple streams & stream order, select the mapping family, coupled channels, and how to specify the matrix (for family 3). Likewise, there's no multistream support at