Subject: [clue] removing area of capture for audio

From: "Duckworth, Mark" <[email-masked]>
Date: Mon, 16 Jun 2014 10:17:19 -0700

If the group agrees, I will update the framework to disallow use of area of capture for audio.  More below.  Let me know if you agree.

>From the minutes of the May 13 2014 design team:

> 5. Intended-capture-area polygon
> After some discussion it was agreed that capture "area" (2-dimensional) is
> not applicable for audio, and should, if anything, be a "volume" (3-dimensional).
> It was agreed that a better way of defining this capture volume would be in 
> terms of the microphone physical location (point of capture), the generic 
> microphone directivity pattern, and the microphone axis of orientation (if directional).

Referring to the data model, I think what this means is that if the provider wants to give spatial information for audio captures, the provider should not (MUST NOT?) use the <captureArea> element within the "spatialInformationType".  The provider should use the <capturePoint> element, which also includes <lineOfCapturePoint>.  This makes sense to me, so if the group agrees with it I will update the framework section 7.1.1 to make this clear, from the semantic point of view of the framework.  I will also have to update some examples in section 12.

I think the data model would need changes also, either clarifying text that <captureArea> is not allowed for audio, or changing the schema to make it impossible to use for audio.

Regards,
Mark

---

From: Paul Coverdale <[email-masked]>
Date: Mon, 16 Jun 2014 14:42:40 -0400

Hi Mark,

Yes, based on the discussion during the May 13 Design team meeting I think
we need to remove the concept of area of capture for audio from the
Framework. I think it needs to be specifically stated in section 7.1.1.3
that area of capture is only applicable to video. To convey spatial
information for audio, we can use point of capture and point on line of
capture as you propose, but I think we need to introduce another element to
define the generic microphone directivity pattern.

Regards,

...Paul

>-----Original Message-----
>From: clue [mailto:[email-masked]] On Behalf Of Duckworth, Mark
>Sent: Monday, June 16, 2014 1:17 PM
>To: [email-masked]
>Subject: [clue] removing area of capture for audio
>
>If the group agrees, I will update the framework to disallow use of area
>of capture for audio.  More below.  Let me know if you agree.
>
>> After some discussion it was agreed that capture "area"
>> (2-dimensional) is not applicable for audio, and should, if anything,
>be a "volume" (3-dimensional).
>> It was agreed that a better way of defining this capture volume would
>> be in terms of the microphone physical location (point of capture),
>> the generic microphone directivity pattern, and the microphone axis of
>orientation (if directional).
>
>Referring to the data model, I think what this means is that if the
>provider wants to give spatial information for audio captures, the
>provider should not (MUST NOT?) use the <captureArea> element within the
>"spatialInformationType".  The provider should use the <capturePoint>
>element, which also includes <lineOfCapturePoint>.  This makes sense to
>me, so if the group agrees with it I will update the framework section
>7.1.1 to make this clear, from the semantic point of view of the
>framework.  I will also have to update some examples in section 12.
>
>I think the data model would need changes also, either clarifying text
>that <captureArea> is not allowed for audio, or changing the schema to
>make it impossible to use for audio.
>
>Regards,
>Mark
>
>_______________________________________________
>clue mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/clue

---

From: Christian Groves <[email-masked]>
Date: Tue, 17 Jun 2014 23:05:07 +1000

Hello Mark,

Yes I agree. I think its a "MUST NOT".

Regards, Christian

---

From: Paul Coverdale <[email-masked]>
Date: Thu, 19 Jun 2014 10:46:17 -0400

Colleagues,

Following up on the action from the Design Team meeting of June 17, I
propose the following text to be added at the end of section 7.1.1.3 in the
Framework document.
 
................
Note that area of capture is not a valid concept for audio. To capture
spatial information related to audio, the point of capture and point on line
of capture ( as defined in sections 7.1.1.1 and 7.1.1.2) may be used, along
with another element defining the nominal sensitivity pattern of the
microphone (bearing in mind that the actual microphone sensitivity pattern,
in situ, may be somewhat different due to local obstacles). Nominal
microphone sensitivity patterns to choose from include: Omni;
Bi-directional; Cardioid; Super-cardioid; Hyper-cardioid; Shotgun. For a
stereo microphone pair, the point of capture is defined as the mid-point
between the point of capture of the individual microphones.
..................

Regards,

...Paul

---

From: "Duckworth, Mark" <[email-masked]>
Date: Fri, 20 Jun 2014 11:48:18 -0700

Thanks Paul,

I agree with your suggestion, but I would like to add a new section 7.1.1.x for the new sensitivity pattern attribute.  Then split your proposed text between 7.1.1.3 Area of Capture and 7.1.1.1 Point of Capture and the new section.

I can also update the section 12 examples that mention spatial information for audio.

Mark

> From: clue [mailto:[email-masked]] On Behalf Of Paul Coverdale
> Sent: Thursday, June 19, 2014 10:46 AM
> To: [email-masked]
> Subject: [clue] How to do deal with CLUE spatial audio aspects
> 
> Colleagues,
> 
> Note that area of capture is not a valid concept for audio. To capture spatial
> information related to audio, the point of capture and point on line of
> capture ( as defined in sections 7.1.1.1 and 7.1.1.2) may be used, along with
> another element defining the nominal sensitivity pattern of the microphone
> (bearing in mind that the actual microphone sensitivity pattern, in situ, may
> be somewhat different due to local obstacles). Nominal microphone
> sensitivity patterns to choose from include: Omni; Bi-directional; Cardioid;
> Super-cardioid; Hyper-cardioid; Shotgun. For a stereo microphone pair, the
> point of capture is defined as the mid-point between the point of capture of
> the individual microphones.
> ..................
> 
> Regards,
> 
> ...Paul
>

---

From: Paul Coverdale <[email-masked]>
Date: Fri, 20 Jun 2014 20:47:00 -0400

Hi Mark,

Your proposed way forward is fine for me.

Thanks,

...Paul

>From: Duckworth, Mark [mailto:[email-masked]]
>Sent: Friday, June 20, 2014 2:48 PM
>To: Paul Coverdale; [email-masked]
>Subject: RE: [clue] How to do deal with CLUE spatial audio aspects
>
>Thanks Paul,
>
>I agree with your suggestion, but I would like to add a new section
>7.1.1.x for the new sensitivity pattern attribute.  Then split your
>proposed text between 7.1.1.3 Area of Capture and 7.1.1.1 Point of
>Capture and the new section.
>
>> propose the following text to be added at the end of section 7.1.1.3
>> in the Framework document.
>>
>> ................
>> spatial information related to audio, the point of capture and point
>> on line of capture ( as defined in sections 7.1.1.1 and 7.1.1.2) may
>> be used, along with another element defining the nominal sensitivity
>> pattern of the microphone (bearing in mind that the actual microphone
>> sensitivity pattern, in situ, may be somewhat different due to local
>> obstacles). Nominal microphone sensitivity patterns to choose from
>> include: Omni; Bi-directional; Cardioid; Super-cardioid;
>> Hyper-cardioid; Shotgun. For a stereo microphone pair, the point of
>> capture is defined as the mid-point between the point of capture of

---

From: Christian Groves <[email-masked]>
Date: Mon, 23 Jun 2014 15:01:03 +1000

Hello Paul, Mark,

Paul: Thanks for providing the text. For the sensitivity pattern 
attribute is there some short description giving an example how it could 
be used by the Consumer?

Mark: I agree with your suggestion. I think its better to capture the 
changes that way.

Regards, Christian

---

From: Paul Coverdale <[email-masked]>
Date: Wed, 25 Jun 2014 13:50:19 -0400

Hi Christian,

I'm assuming such a description would go in the proposed new section
7.1.1.x. I don't know what level of detail is appropriate, but here's some
possible text, although we really need a picture for clarity.

At the Consumer, the sensitivity pattern attribute may be combined with the
point of capture and  point on line of capture (which together define the
major axis of the sensitivity pattern) to define a 3-dimensional volume of
capture where sounds can be expected to be picked up by the microphone
providing this specific audio capture. This volume can be compared with the
area of capture for video media to provide a check on whether the audio
capture is indeed appropriate for the video capture that it is supposed to
be associated with. For example, a video area of capture that fails to
intersect at all with the audio volume of capture, or is at such a long
radial distance from the microphone point of capture that the audio level
would be very low, would be inappropriate.

Regards,

..Paul

>From: clue [mailto:[email-masked]] On Behalf Of Christian Groves
>Sent: Monday, June 23, 2014 1:01 AM
>To: [email-masked]
>Subject: Re: [clue] How to do deal with CLUE spatial audio aspects
>
>Hello Paul, Mark,
>
>>> Note that area of capture is not a valid concept for audio. To
>>> capture spatial information related to audio, the point of capture
>>> and point on line of capture ( as defined in sections 7.1.1.1 and
>>> 7.1.1.2) may be used, along with another element defining the nominal
>>> sensitivity pattern of the microphone (bearing in mind that the
>>> actual microphone sensitivity pattern, in situ, may be somewhat
>>> different due to local obstacles). Nominal microphone sensitivity
>>> patterns to choose from include: Omni; Bi-directional; Cardioid;
>>> Super-cardioid; Hyper-cardioid; Shotgun. For a stereo microphone
>>> pair, the point of capture is defined as the mid-point between the
>point of capture of the individual microphones.
>>> ..................
>>>
>>> Regards,
>>>
>>> ...Paul
>>>

---

From: "Duckworth, Mark" <[email-masked]>
Date: Thu, 26 Jun 2014 10:41:13 -0700

This seems reasonable to me.  I'll also add this to the framework if nobody objects.
Mark

> Sent: Wednesday, June 25, 2014 1:50 PM
> To: 'Christian Groves'; [email-masked]
> capture is indeed appropriate for the video capture that it is supposed to be
> associated with. For example, a video area of capture that fails to intersect at
> all with the audio volume of capture, or is at such a long radial distance from
> the microphone point of capture that the audio level would be very low,
> would be inappropriate.
> 
> 
> Regards,
> 
> ..Paul
> 
> >attribute is there some short description giving an example how it
> >could be used by the Consumer?
> >
> >>> Following up on the action from the Design Team meeting of June 17,
> >>> I propose the following text to be added at the end of section
> >>> 7.1.1.3 in the Framework document.
> >>>
> >>> ................
> >>> 7.1.1.2) may be used, along with another element defining the
> >>> nominal sensitivity pattern of the microphone (bearing in mind that
> >>> the actual microphone sensitivity pattern, in situ, may be somewhat

---

From: Christian Groves <[email-masked]>
Date: Mon, 30 Jun 2014 12:20:23 +1000

Hello Paul,

It sounds good.

Regards, Christian