- From: Frederick Umminger <frederick.umminger@gmail.com>
- Date: Fri, 25 Jan 2013 01:51:03 -0800
- To: Chris Pike <chris.pike@bbc.co.uk>
- Cc: public-audio@w3.org
- Message-ID: <CAPJnUh9w5DpNvc9QO0e3PMhO_MGY_R0nS=yNJg3vPoSGU2f98A@mail.gmail.com>
The solution to channel identification does not have to be overly complicated. You just need to define an enum for each supported format, and provide a definition of what that format is. This is much more robust than attempting to actually describe the format in the way Wave Format Extensible does. An extra clever solution would be to use GUIDs for the enums so that formats can be defined by multiple parties independently without needing a central registry to prevent name clashes. Sincerely, Frederick On Thu, Jan 24, 2013 at 3:02 AM, Chris Pike <chris.pike@bbc.co.uk> wrote: > Channel identification is an issue that is currently being considered in > the broadcast community. It is worth noting that Microsoft Wave Format > Extensible Channel Mask can assist in identifying the required loudspeakers > ( > http://msdn.microsoft.com/en-gb/library/windows/hardware/gg463006.aspx#EMLAC), > although the channel ordering can still be ambiguous and as Frederick has > mentioned it does not currently support more recent speaker layouts such as > NHK's 22.2. In the EBU we are discussing revision of the BWF to allow an > extension of channel description meta-data to handle arbitrary > channel/loudspeaker layouts as well as those defined by industry, and also > sound field and object-based representations. > > Whilst this may be beneficial in the future it is probably an > over-complication at the moment. As recommendations and standards develop > to improve channel identification perhaps it can be incorporated into web > audio? > > Best regards, > Chris > > > > On 23 Jan 2013, at 08:36, Frederick Umminger <frederick.umminger@gmail.com> > wrote: > > It would be wrong to assign a specific channel ordering based only on the > number of channels. > You also need to have an identifier to disambiguate different surround > formats that have the same > numbers of channels. > > For instance, quad (front left, front right, back left, back right) vs > LCRS (left, center, right, surround) > (both of these are directly supported by Pro Tools), or 11.1 vs 10.2. > > Any such identifier should clearly reference the standard it is based on > (ITU-R, SMPTE, Dolby, etc.), > so that the correct speaker layout can be determined directly from the > source standard document. > Note that some standards have the same number of channels, and same > speaker placements, but > different channel orders. > > If there is no standard, the format does not exist and should not be > supported. > > No assumption should be made that all surround formats can be described as > subsets of some > master collection of speaker positions, as is done in the specification of > the multi-channel Wave file > format ( > http://msdn.microsoft.com/en-us/library/windows/hardware/gg463006.aspx). > Doing so assumes a permanent limit on human creativity as applied to > speaker layouts, and is bound > to miss something that will be used in the future. For instance, the > multi-channel Wave file format > cannot describe the 22.2 format promoted by NHK. Nor can it describe 10.2. > > This is a complex topic that should not be oversimplified. Oversimplifying > will cause endless > compatibility problems with the various professional formats, both current > and yet to come. > > All IMHO of course. > > Sincerely, > Frederick > > > On Tue, Jan 15, 2013 at 12:44 PM, Ralph Giles <giles@mozilla.com> wrote: > >> On 13-01-15 10:36 AM, Chris Rogers wrote: >> >> > What Tim says sounds reasonable. I think we should be able to come up >> > with good channel orderings for the currently undefined ones he >> > mentions. >> >> To be clear, what we settled on for FLAC is: >> >> 1 channel: mono. >> 2 channels: left, right. >> 3 channels: left, right, center. >> 4 channels: front left, front right, back left, back right. >> 5 channels: front left, front right, center, >> back/surround left, back/surround right. >> 6 channels: front left, front right, front center, LFE, >> back/surround left, back/surround right. >> 7 channels: front left, front right, front center, >> LFE, back center, side left, side right. >> 8 channels: front left, front right, front center, LFE, >> back left, back right, side left, side right. >> >> This is based on identifying the standard Dolby surround speaker sets >> for home theatre with the the channel designations and order in >> http://msdn.microsoft.com/en-us/windows/hardware/gg463006..aspx<http://msdn.microsoft.com/en-us/windows/hardware/gg463006.aspx> >> >> >> The 'back/surround' hedge is to clarify compatibility with media formats >> and frameworks like Apple's CoreAudio which use the 'surround' >> terminology. For 4, 5 and 6 channel speaker arrangements the distinction >> between side, back, rear, and surround isn't meaningful. >> >> As Tim says, there is confusion with 7 and 8 channel setups between >> different standards as to whether 'surround' maps to 'side' or 'back', >> and whether the rear centre channel in 6.1 is in line with the other two >> surrounds or not. I think selecting 'side' and 'back' makes clear enough >> how to map these channels to any physical speaker arrangement. >> >> > Another thing to note is that the user agent may >> > have to do some amount of "channel swizzling" at the very final stage >> > when talking to the audio hardware to switch the Web Audio ordering of >> > channels into the actual physical ordering on that specific machine >> > (which can vary depending on configuration). >> >> Yes, of course. >> >> -r >> >> > > > > http://www.bbc.co.uk > This e-mail (and any attachments) is confidential and may contain personal > views which are not the views of the BBC unless specifically stated. > If you have received it in error, please delete it from your system. > Do not use, copy or disclose the information in any way nor act in > reliance on it and notify the sender immediately. > Please note that the BBC monitors e-mails sent or received. > Further communication will signify your consent to this. >
Received on Friday, 25 January 2013 09:54:05 UTC