Where can I find the Header file or whatever which specifies the "Mapping" flag. In feb - apr 2007, there was a lot of discussion about Ambisonics and Monty kindly stated that Mapping = 1 ; Denotes and Ambisonic file as opposed to = 0 which is 1 speaker/ 1 channel Has this been written explicitly into the standard? Which standard should I be looking at? http://xiph.org/vorbis/doc/Vorbis_I_spec.html#id342556 specifies only Mapping = 0 The reason why I'm searching for the actual physical definition of the flag is the unwashed Ambisonic Community would like this to be just a bit (bit 1) rather than a single value (Mapping = 1) That's cos we might want more bits from yus guys later if / when we have more than 16 channels ( more than 3rd order Ambi) -- Internal Virus Database is out-of-date. Checked by AVG Free Edition. Version: 7.5.524 / Virus Database: 268.0.0/1587 - Release Date: 2/08/08 17:30 -- Internal Virus Database is out-of-date. Checked by AVG Free Edition. Version: 7.5.524 / Virus Database: 268.0.0/1587 - Release Date: 2/08/08 17:30
On Sun, Sep 7, 2008 at 2:07 AM, Richard Lee <ricardo at justnet.com.au> wrote:> Where can I find the Header file or whatever which specifies the "Mapping" flag. > > In feb - apr 2007, there was a lot of discussion about Ambisonics and Monty kindly stated that > > Mapping = 1 ; Denotes and Ambisonic file as opposed to = 0 which is 1 speaker/ 1 channel > > Has this been written explicitly into the standard?I don't believe so, but it was always the intention. It wouldn't be in the standard because there is no specification on what to do inside the mapping. [snip]> The reason why I'm searching for the actual physical definition of the flag is the unwashed Ambisonic Community would like this to be just a bit (bit 1) rather than a single value (Mapping = 1) > > That's cos we might want more bits from yus guys later if / when we have more than 16 channels ( more than 3rd order Ambi)Hm? Why would you want additional bits? B-format support is going to need a channel map even for second order because you may want to do mixed order-representations. A commons usage would be second-order horizontal only (this is what would probably be used for 5.1->b-format conversions), or things like third-order horizontal plus first order height (which is more of a fit for speaker arrays which can reasonably be constructed in a residential setting). I wouldn't use the mapping to indicate H/V orders. Or were you referring to the lack of a canonical selection of orthogonal harmonics for higher orders? I thought that had been resolved. If not, I think it probably should be rather than expecting Vorbis to handle it.
>> That's cos we might want more bits from yus guys later if / when we have more than 16 channels ( more than 3rd order Ambi)> Why would you want additional bits?> B-format support is going to need a channel map even for second order because you may want to do mixed order-representations.As it so happens, mixed orders up to 3rd are implicitly specified by the number of channels. This is described Martin Leese's "File Format for B-Format" page at http://www.ambisonia.com/Members/mleese There is no need for a channel map for the forseable future. When we start distributing 4th order stuff (which requires >16 speakers) we can get around this by having missing channels simply silent. Vorbis compression is very efficient at coding silence. Thanks to Gregory Maxwell for this excellent suggestion on the sursound forum. Be aware though that Martin's "official file format for downloadable B-Format files" has errors and ambiguities. In particular, there is talk of "attenuation of W" which causes much confusion to newcomers to Ambisonics and old hands alike. I intend to start an "Official Vorbis Ambisonic specification" which is meant to be used in conjunction with the official Vorbis "Mapping = 1" specification when if appears. This will specify the signal in the various channels and also some parameters eg coupling modes. I'll correct some serious errors in most public Ambi specifications and bring them into line with real life. This would allow practical microphones to be designed. At the same time, we'll retain a simplified spec to facilitate coding eg ITU 5.1 and various 7.1 modes efficiently to Ambisonics with good results. So we probably won't need extra bits. But we'd still like to have Bit1 as the Ambisonic flag rather than Mapping =1 if that's OK with yus guys _________________________> The second proposal, was from Sampo Syreen, who suggested to add the full OggPCM (option 2) channel mapping, ... because we would also add support for surround formats >5.1.This can stay in Ogg. It is a VERY bad idea to have with Vorbis Ambi (Mapping = 1) They are fundamentally VERY different in their approach. Ambisonics defines the soundfield; WHAT SHOULD BE HEARD. How you achieve this is completely separate and depends on your speakers, the layout etc. This allows it to be played on 4.0 5.1 .. 7.1 ... zillion.1 speakers and in all cases extracts the best possible sound from the original recording and the speakers and the room. It is this 'spatial coding' that gives its sonic advantage and allows 3 channel ambi to outperform 5.1 Having more channels does not only improve the sound in the direction of the extra speakers but improves the sound from ALL directions. 5.1 7.1 ... zillion.1 are one channel / one speaker formats. You will never keep up with this sensibly. Crude mixing 7.1 to 5.1 or vice versa usually gives bad results. In fact the best way to do this is to code these into Ambisonics and then play this via an Ambisonic decoder matched to your speakers and room layout. 5.1 7.1 ... zillion.1 belong in the one channel / one speaker zone (Mapping = 0) You will need ever increasing amounts of obfuscating metadata to describe it so please keep it in Ogg. The best thing about this is that Native Vorbis can ignore it all for (Mapping = 1). Lets keep it that way. ___________________ What's required to do a full Vorbis Mapping = 1 (Ambisonic) spec? We'll have a) Channel Definitions b) Coupling Modes. Gregory Maxwell is working on a Lossless Coupling mode optimised for Ambisonics. Can present decoders decode the full set of Stereo Coupling modes described on the web page? eg Dual, Lossless Stereo, the Phase Stereo mode ... Can we specify minimum and recommended Lossless Coupling modes? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/ms-tnef Size: 4070 bytes Desc: not available Url : http://lists.xiph.org/pipermail/vorbis-dev/attachments/20080910/7b523ab2/attachment-0001.bin
>> When we start distributing 4th order stuff (which requires >16 speakers) we can get around this by having missing channels simply silent. Vorbis compression is very efficient at coding silence. Thanks to Gregory Maxwell for this excellent suggestion on the sursound forum.>Fons killed that proposal already on the sursound list. The Ambisonics decoder have to be setup before the playback starts.For higher orders, Gregory's scheme, has silent channels. The player would need to look at the first sec. or so to determine the order for horizontal and vertical. By the time we need higher orders, the decoders will need to be so complex that allocating buffers and then freeing them would be trivial. Before this happens, we also need a new professional format which is likely completely different from the present one. In the meantime, I'm very much against repeating info at different places and in different form. This always begs the question of what does the player do if the info conflicts. And many applications will cheat and/or get one wrong.>> This can stay in Ogg. It is a VERY bad idea to have with Vorbis Ambi (Mapping = 1) They are fundamentally VERY different in their approach.> Are we sure we know what we are talking about? What is Ogg, what is Vorbis and what OggPCM?> I don't see any reason why a flexible universal channel mapping approach is a VERY bad idea. Just don't call it Ambisonics channel mapping. There are hybrid formats, how could you describe these with a simplistic Ambisonics-only channel mapping? I'm thinking of B+ Format (Ambisonics + Stereo) or maybe WXY(Z) plus a center channel and optional LFE as a 5.1 alternative.As I understand it, Ogg is a container and may have several streams eg Video, vorbis sound, FLAC sound, subtitles, karaoke etc. The sensible way to do mixed modes like Ambi with dedicated CF speaker channel is to have the extra channel and its metadata in a separate Ogg stream. This way, Vorbis Ambi & AmbiDecLib have a clean interface and only deal with Ambi type signals. Making Ambi Vorbis cater for these will seriously complicate the decoder and its API which we are attempting to simplify. If Monty grants us bit1 rather than Mapping = 1, we can ask for more bits later. Don't want to be too greedy and ask for the full OggPCM channel mapping, especially as none of it is necessary at present.
>> When we start distributing 4th order stuff (which requires >16 speakers) we can get around this by having missing channels simply silent. Vorbis compression is very efficient at coding silence. Thanks to Gregory Maxwell for this excellent suggestion on the sursound forum.> Fons killed that proposal already on the sursound list. The Ambisonics decoder have to be setup before the playback starts. A silent channel is still a channel that at any point in time could become non-silent.By the time we need higher orders, the decoders will need to be so complex that allocating buffers and then freeing them would be trivial. A simple way to guarantee there's always something to be detected is to specify the first eg 256 samples to have at least a -80dB FS noise type signal. We'd have to choose a noise type that wouldn't be killed completely by the coupling or compression. Aaron's experience with video is that metadata is always lost. The only thing that survives is the data itself. If we're clever, we could have this code the metadata itself .... down boy! Down! Shaddup! .... 8>D I'm in favour of simplicity and letting complexity sort itself out when the time comes. Make sure you do important things as simply and as good as you can and leave complexity for little / never used stuff. -- Internal Virus Database is out-of-date. Checked by AVG Free Edition. Version: 7.5.524 / Virus Database: 268.0.0/1587 - Release Date: 2/08/08 17:30
On Fri, Sep 12, 2008 at 7:24 PM, Richard Furse <rf015d9821 at blueyonder.co.uk> wrote:> Are we saying that something like the excellent OggPCM stuff would be > difficult to implement in Vorbis? This does seem a shame... > > > That aside, the suggestion below is nicely simple and directly > backwards-compatible, give or take the unusual ordering for the mixed/full > channel cases and the extensions to higher order.we can use any other ordering, it's just a continuation of the sequence Gerzon started with W XYZ.> Some possible tweaks: > > Furse/Malham encoding is only defined to third order, and at higher order I > guess it isn't going to be the standard as it makes more sense to redefine > in a general way from the spherical harmonics - using the FuMa components > here for the lower orders only is entirely possible but ugly. The problem > with redefining now is that we'd lose direct backwards-compatibility and > we'd need to herd the cats long enough to agree which formulation and > normalisation to use; I think this will scare some folk and I'm probably > going to regret mentioning it ;-)Better break it now, than later. I don't have much clue about HOA. What are the specific problems in defining a higher order standard? Is there more than defining ordering and weightings? Sorry if that is a dumb question, I started understanding higher order Ambisonics a little bit, when I started rotating 3d models of spherical harmonics on my computer... I have no idea how the math works.
Sampo Syreeni <decoy at iki.fi> wrote: ...> Third, Richard Lee's argument about ambisonic channel metadata carries > over to channel semantics in general: you need to know what each channel > means from the word go, so channel mappings need to be present in the > codec initialisation headers, and not, say, in Skeleton. Otherwise we're > going to experience delay before the channels can be played properly, > which isn't going to be appreciated by the better part of people who are > used to fast synch in DVDs, big screen movies, and indeed the other > container formats.No, the Skeleton stream comes ahead of all other streams. (In Ogg-speak this is "chaining".) Note also that the intention is that *every* Ogg file should include a Skeleton stream. (The problem, as you might expect, is backwards compatibility.)> So, while I *do* undertand (and perhaps even support) the idea that the > ambisonic mapping in Vorbis should be as simple as possible, I *still* > think the above reasoning for it is gravely mistaken.Well, the simplest mapping is to let Channel Mapping = 1 signify a B-Format Vorbis stream. That's all you need for third-order. You don't even *need* a Skeleton stream (although it would be useful to make one mandatory in Ogg files containing a Vorbis B-Format stream). Fourth-order and higher needs more metadata but, as the Skeleton stream is intended for metadata about other streams, that's a good place for it. Regards, Martin -- Martin J Leese E-mail: martin.leese stanfordalumni.org Web: http://members.tripod.com/martin_leese/
> In feb - apr 2007, there was a lot of discussion about Ambisonics and Monty kindly stated that> Mapping = 1 ; Denotes and Ambisonic file as opposed to = 0 which is 1 speaker/ 1 channel> http://xiph.org/vorbis/doc/Vorbis_I_spec.html#id342556> specifies only Mapping = 0> The reason why I'm searching for the actual physical definition of the flag is the unwashed Ambisonic Community would like this to be just a bit (bit 1) rather than a single value (Mapping = 1)> That's cos we might want more bits from yus guys later if / when we have more than 16 channelsMy apologies. Should be please can we have "bit0 set" to define Ambisonics. This is compatible with Mapping = 1 Mea maxima culpa. My excuse is kunt reed en rite ... 8>D -- Internal Virus Database is out-of-date. Checked by AVG Free Edition. Version: 7.5.524 / Virus Database: 268.0.0/1587 - Release Date: 2/08/08 17:30