Subject: Re: [AVT] draft-ivov-avt-slic-03

From: Stefan Sayer <[email-masked]>
Date: Tue, 16 Nov 2010 17:44:43 +0100

Hello,

please allow me to revive this old topic.

Michael Ramalho (mramalho) wrote:
> I am confused.
> 
> Why are you guys (imprecisely) trying to re-invent wheels long ago
> invented, standardized and understood?
> 
> Definitions of all this stuff (RMS power, signal power, background noise
> power, now to normalize mu-law or a-law to 13 or 14 bit precision, etc.)
> is in the ITU-T Software Tools Library (a.k.a., G.191 .... search for it
> at ... http://www.itu.int/itu-t/recommendations/index.aspx?ser=G).
> 
> In some cases this STL references other standard for more precise
> definitions (e.g., speech "power" in P.56).
> 
> And C-language tools (code) to generate any power of interest are even
> provided in the STL ... so you can verify if your results are within an
> acceptable tolerance of what the STL tools produce.

Thank you for the hints to P.56 and G.191, and please excuse my 
ignorance; the intention is definitely not to re-invent any wheels.

Nevertheless, I am not convinced that the method B from P.56 
(implemented in G.191) is what makes sense for the mixer-to-client 
audio levels. P.56 describes a method to measure the "active speech 
level" (method B). Quoting P.56 5.1:
     "However, the all-important question is what criterion should
      be used to determine when speech is present. Ideally, the
      criterion should indicate the presence of speech for the
      same proportion of time as it appears to be present to
      a human listener, excluding noise that is not part of the
      speech (such as impulses, echoes, and steady noise during
      periods of silence), but including those brief periods of
      low or zero power that are not perceived as interruptions
      in the flow of speech [4]."

One intention of the mixer-to-client audio levels is to give the 
conference participants hints about who is contributing noise to the 
mix (e.g. in order to mute that participant, see the introduction in 
draft-ivov-avt-slic-03).

If only the *active* speech level is sent to the client, exactly this 
valuable information about noise in non-active periods may be lost. 
So, I think that for the use case of mixer-to-client audio levels, the 
raw signal should be measured without any speech detection, and I 
think that the simple power calculation from G.100.1 described below 
done on the raw signal makes sense.

Note that this is different for client-to-mixer audio levels, as there 
the use case is different (simplify speaker selection in the mixer). 
Here the active speech level measure is appropriate.

Stefan

> 
> [I say acceptable tolerance because I don't really mind if you are a few
> tenths of a dB off ... if you have a particularly efficient way of
> generating a power level of interest.]
> 
> Michael Ramalho
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Stefan Sayer
> Sent: Thursday, July 22, 2010 4:42 PM
> To: Peter Musgrave
> Cc: [email-masked]
> Subject: Re: [AVT] draft-ivov-avt-slic-03
> 
> Peter Musgrave wrote:
>>>> Also, looking at the draft and the references to other docs which
>>>> calculate the level I still don't know how to implement the  level
>>>> calculation. I suspect there is some unstated knowledge that I have
>>>> never learned or forgotten - but it the audio level number the
> maximum
>>>> level in the packet? Total energy? Some kind of average?
>>> I see. We were thinking that the reference to calculating comfort
> noise
>>> levels would have been enough but it's proving not to be. I guess
> that
>>> in the next iteration of the drafts we could also add an annex
>>> containing sample code. This would probably also help
> interoperability
>>> issues. How does this sound?
>> Sample code might be useful. There is an attempt at a reference w.r.t
>> G711 waveforms in the docs you reference which baffles me. I would
>> have thought the audio level in the packet would apply to the linear
>> data inside independent of how it was coded - so if there is sample
>> code I assume it is referring to the pre-encoded (linear) data?
> dBov is defined in G.100.1 5.7. This reference should probably be 
> added to the levels draft, as it is (surprisingly) missing in the 
> referenced RFC3389.
> 
> Quoting G.100.1: "The power of a sampled signal x(n) with a length of 
> N samples can be defined by:
> 
>            N-1
>            ___
> P=  1/N * \   x(n)^2
>            /
>            ---
>            n=0
> 
> For a digital system which has an overload point xover, the maximum 
> signal power will be P0 = 1.0.
> In this case, the power level for a digital signal in decibels 
> relative to the overload point (dBov, where the characters "ov" 
> arbitrarily mean digital overload signal level) is defined by
> 
>     Lov = 10 log   ( P / P0 )   [dBov]
>                 10
> The level of the maximum signal power P0 is thus 0 dBov, which is 
> chosen to be the reference level."
> 
> For example, if the system were transmitting 16 bit signed PCM samples 
> (L16), a packet of 32767 -32768 32767 -32768 ... would be at the 
> overload point of 0 dBov (likewise a packet full of 32767 32767 32767 
> ... or -32768 -32768 -32768 values). If we were transmitting 160 
> samples in a packet, the maximum power would be P0 = 32767^2 =
> 1073676289.
> 
> To calculate the level of a packet with 160 samples as for sending in 
> the audio levels header, we can sum up the squares, divide by 160, 
> divide by 1073676289, take the logarithm to base 10, and multiply with 
> -10.
> 
> Now, the input to a G711 mu-law encoder must be quantized to 14 bits, 
> and the highest value at the decoder output is 8031. If I understand 
> G.711 correctly, the value at the segment end point (i.e. the highest 
> value that a G.711 u-law encoder should be fed with, or, the upper 
> limit of the highest quantization step) is 8159. So, if you for 
> example have 16 bit samples which are attenuated to 0dB (they go from 
> lowest to highest sample value), you would requantize to 14 bit. Then 
> you could attenuate the signal such that the highest value is 8159 
> (not 8191, what the highest value of a signed 14 bit sample could be). 
> In reality, though, I guess you would omit that step, as it only 
> accounts for -20dB  (10*log(33/8192)). What is important here is that 
> apart from precision it doesn't matter whether the audio level 
> relative to overload is calculated with the 16 bit samples, or the 14 
> bit samples. And, if the input to a coder has a power reference point 
> well below 0, before feeding the audio to the encoder we would have to 
> attenuate the signal anyway, such that the calculation of the dBov 
> with the uncoded (PCM) signal stays correct. Logically, on the wire, 
> we can only refer to the overload point of the coded signal, but still 
> we can calculate the power level properly from the uncoded signal.
> 
> Please correct me where I'm wrong.
> 
> Stefan
> 
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt
>

---

From: "Allison, Art" <[email-masked]>
Date: Tue, 16 Nov 2010 13:33:13 -0500

Indeed dabbling in this area is questionable, as there are plenty of standards and recommendations established by experts in the audio field.  ITU has a recommendation that covers measurement of audio levels including the anchor element (normally dialogue) level. See ITU-R: "Recommendation BS.1770-1, Algorithms to measure audio programme loudness and true-peak audio level," International Telecommunications Union, Geneva, 2007. Also see AES: "TD-1001", SMPTE RP 200, and ATSC A/85 (and it's many references).

May I suggest that avt should not venture past how to associate and transport of any  metadata that is deemed needed?  

Art Allison
Senior Director Advanced Engineering, Science and Technology
National Association of Broadcasters
1771 N Street NW
Washington, DC 20036
Phone  202 429 5418 
Fax  202 775 4981
www.nab.org
Advocacy  Education  Innovation

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stefan Sayer
Sent: Tuesday, November 16, 2010 11:45 AM
To: Michael Ramalho (mramalho)
Cc: [email-masked]
Subject: Re: [AVT] draft-ivov-avt-slic-03

Hello,

Stefan

---

From: Stefan Sayer <[email-masked]>
Date: Tue, 16 Nov 2010 20:50:11 +0100

Thanks for the pointers to measurement methods for these loudness levels.

My opinion is that for the intended applications (identifying active 
speakers and identifying sources of noise in audio conferencing), 
simple power (RMS) levels are sufficient, and they are also universal.

For other applications it might be beneficial to be able to associate 
and transport loudness levels that correspond to subjective loudness 
experience, surround/multi channel and whatnot, but for the given use 
cases I think this is just unnecessary making things complex.

Stefan