similar to: OPUS_SET_WAVEFORM_MATCHING() and Ambisonics

Hi Drew, Some comments on the libopusenc patch: + int _oge_use_projection(int channel_mapping); These functions are part of libopusenc, so I'd expect them to have an ope prefix like the other functions in the libopusenc library. + if (_oge_use_projection(h->channel_mapping)) + { + len=27+(h->channels*(h->nb_streams+h->nb_coupled)*2); + } + else + { +

Hi Jean-Marc, I've modified my patches for libopus and libopusenc based on your suggestions. Cheers, Drew On Mon, Mar 19, 2018 at 2:05 PM Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: > Hi Drew, > > I think the libopusenc patch is better, but there's still a few issues > left: > 1) The static MAX_PACKET_BUFFER_SIZE value is still problematic because > if you

Le 19-12-18 à 12 h 29, Marc Lavallée a écrit : > 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

Martin, I do not believe that there is any need for code specifically supporting Ambisonics. FLAC supports conversion to and from other audio formats which hold multiple channels. Ambisonics B-format involves channels WXYZ, C-format is UHJ or BHJ, G-Format can be any number of channels, but typically 5.1 on DVD. You can work with Ambisonic recordings by either using individual mono

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 >

I've discussed hemispherical ambisonics and mixing matrices with a few people. The consensus is that there is no set of hemispherical basis functions common enough to warrant inclusion yet. We should force channel counts to be values (l + 1)^2 for simplicity and to keep the possibility open of including hemispherical bases should one ever become popular. As for mixing matrices, we are not

Hi Marc, 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 your interest! Please feel free to voice your support for this work on the codec at ietf.org mailing list. The more support the better. > I

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

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

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,

Alright, here is a somewhat formal definition of the channel mapping I had in mind: ------ 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. Each channel is assigned to an ambisonic component in Ambisonic Channel Number (ACN) order. The ambisonic

Hello, I am trying to encode an Opus file with Ambisonics including Head-Locked (non-diegetic) Stereo sound for a Virtual Reality 360° video. YouTube describes the spatial audio requirements here: https://support.google.com/youtube/answer/6395969 It's the last list item 5. > 5. Supported First Order Ambisonics (FOA) with Head-Locked Stereo format: > W, Y, Z, X, L, R as a 6-channel

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 thread; the latest version is on a different thread. The patch does not use the mapping family numbers used by libopus and libopusenc; could you update it to use family 2 and 3 rather than 254 and 253? The patch also appears to break encoding of surround files

All, Progress has been made on the proposed draft spec for integrating ambisonics into vorbis. We are not yet finished (should be soon), but you can see the progress here: http://docs.google.com/Doc?id=df4dtw69_3626qqq6st The issue we have hit now concerns how/who would implement the encoding and decoding in Vorbis Tools. Because ambisonics uses spherical harmonic components, an ambisonic file

Marc, Thanks for the comments. On Sat, May 28, 2016 at 5:50 PM, Marc Lavallée <marc at hacklava.net> wrote: > So, channels will stay uncoupled for Ambisonics? That would be great, > because considering how good Opus already is, I don't think that more > optimization is required, and it would put content creators at ease; > they often believe that any compression or channel

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

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 these mappings for free -- if there's any use for > them anyway. Well, more specifically, the channel count is

Greetings, I apologize if I posted this in the wrong list, I wasn't sure where to post it, but seeing as the tags are called "vorbis comments" I thought vorbis, rather than ogg-dev, would be the right choice. (actually, I'm not even a developer anyway) What I'd like to propose is a simple way to encode ambisonic files in vorbis comments as simple tags. By this I don't

Hi Drew, I think the libopusenc patch is better, but there's still a few issues left: 1) The static MAX_PACKET_BUFFER_SIZE value is still problematic because if you link libopusenc with a new version of libopus that supports higher order projection or just more projection channels for order 3, then you will overflow the buffer. I think what you'd want is a _ope_opus_header_get_size() call

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