Subject: RE: [AVT] RE: <draft-ietf-avt-rtp-vmr-wb-03.txt>: sampling rate

From: [email-masked]
Date: Wed, 8 Sep 2004 00:08:09 -0700

Hi Qiaobing,

> Is it true that all the coded frames output from a VMR-WB 
> __encoder__ use the 12.8k sampling 
> rate, independent of the original sampling rate of the speech?

The above statement is true. However, I want to make sure that it is not misinterpreted.

The VMR-WB encoder converts the 8 or 16 kHz sampled input speech to 12.8 kHz prior to the encoding functions. This INTERNAL sampling frequency is transparent (hidden) to the user. The bit stream generated by the encoder is then transmitted to the VMR-WB decoder.

The VMR-WB decoding functions are independent of the encoder input speech sampling frequency. By default, the VMR-WB decoder generates a wideband output, unless instructed otherwise. The internal sampling frequency must now be converted to 16 kHz (for wideband output) and the higher frequency band (6.4 to 7 kHz spectrum) must be reconstructed by the decoder. If a narrowband output is desired then 12.8 kHz sampling frequency must be converted to 8 kHz. Therefore, you CANNOT use the 12.8 kHz internal sampling frequency for any other purposes than the encoding-decoding functions. 

Depending on the output audio interface (or the network interface), one may wish to instruct the decoder to generate a narrowband or wideband output.

For proper operation, the RTP timestamp clock rate must be either 8000 or 16000 depending on the narrowband or wideband operation, respectively. The 12800 Hz internal sampling rate CANNOT be used for the RTP timestamp clock rate. The correct timestamp or clock rate (8000 or 16000) is required for proper buffering and other functions in the transmitting and receiving sites.

cdma2000 Service Option 62 (VMR-WB) also recognizes only 8000 or 16000 Hz sampling frequencies.

Since VMR-WB and AMR-WB codecs share the same core technology, the concept of 12800 Hz internal sampling frequency is used in both codecs. As you see in AMR-WB RFC and 3GPP specs, there is no external usage of the internal sampling frequency and the default RTP clock rate for the AMR-WB codec is 16000 Hz.

Regards

-Sassan Ahmadi

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Qiaobing Xie <[email-masked]>
Date: Wed, 08 Sep 2004 19:06:55 +0800

Hi, Sassan,

...<snip>...

> The VMR-WB encoder converts the 8 or 16 kHz sampled input speech to 12.8 kHz prior to 
> the encoding functions. This INTERNAL sampling frequency is transparent (hidden) to the
> user. The bit stream generated by the encoder is then transmitted to the VMR-WB decoder.

So this is sort of a "normalization" of the original sampling frequency, and is part of the
pre-processing in the encoder. I guess in theory the original speech can be of sampling
rates other than 8k and 16k and as far as the right "normalization/re-sampling" algorithm is
applied, the encoder will work just fine.

> The VMR-WB decoding functions are independent of the encoder input speech sampling frequency. 

Of cause, since it knows that it only needs to deal with the 12.8k internal sampling rate.
But without outside hints, can the decoder still be able to tell what the original sampling
rate is? I think this is related to Magnus's question about the missing rate information in
the storage file format. By looking at the data in a stored vmr-wb file, I guess one won't
be able to tell what the original sampling rate of the speech is, i.e., the original
sampling rate info is lost forever after the speech was "rate normalized", encoded, and put
into a file with the current file format definition, right?

> By default, the VMR-WB decoder generates a wideband output, unless instructed otherwise.
> The internal sampling frequency must now be converted to 16 kHz (for wideband output) 
> and the higher frequency band (6.4 to 7 kHz spectrum) must be reconstructed by the decoder. 
> If a narrowband output is desired then 12.8 kHz sampling frequency must be converted to 8 
> kHz. Therefore, you CANNOT use the 12.8 kHz internal sampling frequency for any other
> purposes than the encoding-decoding functions. 
> 
> Depending on the output audio interface (or the network interface), one may wish to 
> instruct the decoder to generate a narrowband or wideband output.

How and from whom will the decoder be "instructed" about the final output sampling rate to 
use (8k or 16k)? Strictly speaking, the decoder does not need this instruction. More 
precisely, it is the re-sampler after the decoder that needs to be told about the desired 
output sampling rate, right?

> For proper operation, the RTP timestamp clock rate must be either 8000 or 16000 depending 
> on the narrowband or wideband operation, respectively. The 12800 Hz internal sampling
> rate CANNOT be used for the RTP timestamp clock rate. The correct timestamp or clock rate
> (8000 or 16000) is required for proper buffering and other functions in the transmitting 
> and receiving sites.

This means that, if we take an RTP packet that contains some vmr-wb coded frames, even 
though the timestamp in the header may say 8000 or 16000 rate, the speech bits are actually 
always from 12.8k speech, right?

regards,
-Qiaobing

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 08 Sep 2004 13:36:54 +0200

Hi Sassan,

Based on what you write in the previous mail. It seems that the only 
reason for using different RTP timestamp rate between 8000 and 16000 Hz 
is to indicate the sampling rate of the source material. If the codec 
does not need any indication at all if the source material is 8k or 16k 
then, I think the usage of different RTP timestamp rates is creating 
unnecessary interoperability barriers. The barrier is that one actually 
needs to indicate the rate of the source material, and cope with RTP 
timestamp switching.

To avoid the unnecessary function I would propose that VMR-WB only 
defines 16kHz as RTP timestamp rate. If there is desire to have 
knowledge about source sampling rate that will be used, then one should 
define a parameter that indicates that. But I am not certain it really 
is needed. Such a parameter is declarative and does not matter in 
regards to any interoperability and can be ignored without consequence. 
Or is it something else about the codec that prevents this? I would not 
think so as the file format can be fine without an explicit indication 
of the source sampling rate.

Cheers

Magnus

-- 

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

---

From: Qiaobing Xie <[email-masked]>
Date: Thu, 09 Sep 2004 15:55:02 +0800

Hello, Magnus,

> needs to indicate the rate of the source material, and cope with RTP 

Right on! You nailed the issue perfectly.

> defines 16kHz as RTP timestamp rate. 

Agreed. This would effectively remove the interoperability barrier you pointed out above.

My only concern is that this may create some interesting situations. Let's consider an 
example - original speech of 8k rate is passed to vmr-wb encoder and the decoder is set to 
output speech at 8k rate.

Here, we would then have:

  - source sampling rate = 8k
  - actually sampling rate of the bit stream sent over RTP = 12.8k
  - sampling rate output from vmr-wb = 8k
  - RTP header timestamp rate = 16k!!!

I am not sure this will cause any problem, but it seems strange.

 > If there is desire to have

I, too, would like to first see some use case here. If we don't know how the information is 
going to be used, it makes no sense to specify a mechanism in RTP or even SDP to pass it around.

regards,
-Qiaobing

>>> Is it true that all the coded frames output from a VMR-WB __encoder__ 
>>> use the 12.8k sampling rate, independent of the original sampling 
>>> rate of the speech?
>>
>> The VMR-WB encoder converts the 8 or 16 kHz sampled input speech to 
>> 12.8 kHz prior to the encoding functions. This INTERNAL sampling 
>> frequency is transparent (hidden) to the user. The bit stream 
>> generated by the encoder is then transmitted to the VMR-WB decoder.
>>
>> The VMR-WB decoding functions are independent of the encoder input 
>> speech sampling frequency. By default, the VMR-WB decoder generates a 
>> wideband output, unless instructed otherwise. The internal sampling 
>> frequency must now be converted to 16 kHz (for wideband output) and 
>> the higher frequency band (6.4 to 7 kHz spectrum) must be 
>> reconstructed by the decoder. If a narrowband output is desired then 
>> 12.8 kHz sampling frequency must be converted to 8 kHz. Therefore, you 
>> CANNOT use the 12.8 kHz internal sampling frequency for any other 
>> Depending on the output audio interface (or the network interface), 
>> one may wish to instruct the decoder to generate a narrowband or 
>> wideband output.
>>
>> For proper operation, the RTP timestamp clock rate must be either 8000 
>> or 16000 depending on the narrowband or wideband operation, 
>> respectively. The 12800 Hz internal sampling rate CANNOT be used for 
>> the RTP timestamp clock rate. The correct timestamp or clock rate 
>> (8000 or 16000) is required for proper buffering and other functions 
>> in the transmitting and receiving sites.
>>
>> Since VMR-WB and AMR-WB codecs share the same core technology, the 
>> concept of 12800 Hz internal sampling frequency is used in both 
>> codecs. As you see in AMR-WB RFC and 3GPP specs, there is no external 
>> usage of the internal sampling frequency and the default RTP clock 
>> rate for the AMR-WB codec is 16000 Hz.
>>
>> Regards
>>
>> -Sassan Ahmadi
>>
> 
>

---

From: Colin Perkins <[email-masked]>
Date: Sat, 11 Sep 2004 12:06:24 +0100

Magnus,

On 8 Sep 2004, at 12:36, Magnus Westerlund wrote:
> reason for using different RTP timestamp rate between 8000 and 16000 
> Hz is to indicate the sampling rate of the source material. If the 
> codec does not need any indication at all if the source material is 8k 
> or 16k then, I think the usage of different RTP timestamp rates is 
> creating unnecessary interoperability barriers. The barrier is that 
> one actually needs to indicate the rate of the source material, and 
> cope with RTP timestamp switching.
>

I disagree.

> If there is desire to have knowledge about source sampling rate that 
> will be used, then one should define a parameter that indicates that.

All RTP audio payload formats need that knowledge, since it determines 
the RTP timestamp rate. This is the purpose of the "rate" parameter.

Colin

---

From: Colin Perkins <[email-masked]>
Date: Sat, 11 Sep 2004 12:08:06 +0100

On 9 Sep 2004, at 08:55, Qiaobing Xie wrote:

>> codec does not need any indication at all if the source material is 
>> 8k or 16k then, I think the usage of different RTP timestamp rates is 
> My only concern is that this may create some interesting situations. 
> Let's consider an example - original speech of 8k rate is passed to 
> vmr-wb encoder and the decoder is set to output speech at 8k rate.
>

Exactly! This is why the RTP timestamp rate is set to the sampling rate 
of the media stream for all audio payload formats.

Colin