similar to: ambisonics formats and channel mappings

On Tue, 31 May 2016 09:41:37 -0700 Michael Graczyk <mgraczyk at google.com> wrote: > UHJ is an interesting way to preserve compatibility with non-ambisonic > playback systems. However, I have not seen it generalized to higher > orders. I expect that its popularity will decrease as HOA becomes more > and more common. If UHJ becomes popular in the future, we could > specify

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

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 3/22/07, Brian Willoughby <brianw@sounds.wa.com> wrote: ... > But to return to your question, exactly what kind of "support" are > you looking for? I wasn't looking for any particular support, but just to see what support was there (if any). ... > I do not believe that there is any need for code specifically > supporting Ambisonics. FLAC supports conversion to

"Gabriel I." wrote: > 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) Hi Gabriel, I doubt whether the Xiph community would promote a

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 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

Hi, I have posted this three times to the flac-dev, vorbis-dev, and ogg-dev mailing lists. I wanted to see what code there was currently to support Ambisonics. So I downloaded the code from the xiph download page for libogg-1.1.3, libvorbis-1.1.2, vorbis-tools-1.1.1 and flac-1.1.4, but wasn't able to find anything. If it exists then I missed it, so could somebody please point me to it.

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

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 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

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 >

Thanks for the great input. I corrected a few other errors (spacing and document name) and submitted the document. You can find the status page here https://datatracker.ietf.org/doc/draft-graczyk-codec-ambisonics/ and the document draft here http://www.ietf.org/id/draft-graczyk-codec-ambisonics-00.txt I will be sending an email out to the CODEC mailing list shortly.

On 10/19/07, Sampo Syreeni <decoy@iki.fi> wrote: > On 2007-10-19, Martin Leese wrote: > > OggPCM Draft3 > > Draft 3 is obviously a joke. Draft 2 is what most of the people agreed > upon the last time around, with the channel maps left unfinished. Draft > 1 was abandoned by most people in favour of draft 2. So what is "OggPCM"? I started this thread

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

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 came out of the OggPCM discussion, but I think it needs to be addressed on a wider scale. Let's start here, 5 years ago.. http://lists.xiph.org/pipermail/vorbis-dev/2000-July/009513.html (I included this email, below) I emailed David (author of that email) and asked him to join this list. I'm thinking, as I look at the problem, that surround sound needs to be defined _outside_

Michael Graczyk wrote: > That makes sense. For now I will focus on encoder only changes. If an > adaptive pre/post transform had to send side information, would it > also need to go through the IETF process? The IANA registry for channel mappings has a policy of "specification required", but not "RFC required", so it is possible to specify something without going

Ian Malone <ibmalone@gmail.com> wrote: > It depends what your aim is. The mapping type > in the vorbis setup header is meant for > this[1],[2]. Of course a nonzero mapping type will > cause a lot of players to give up, but so will > including the XML stream. I believe this is how > is was intended multi-channel would be handled. Thanks for the response, and for the

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