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

Qiaobing Xie <Qiaobing.Xie@motorola.com> Wed, 08 September 2004 11:09 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00184 for <avt-archive@ietf.org>; Wed, 8 Sep 2004 07:09:25 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C50Nr-00067K-UN for avt-archive@ietf.org; Wed, 08 Sep 2004 07:13:14 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C50HB-0005qW-MC; Wed, 08 Sep 2004 07:06:09 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C50Gj-0005iL-Bi for avt@megatron.ietf.org; Wed, 08 Sep 2004 07:05:41 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00057 for <avt@ietf.org>; Wed, 8 Sep 2004 07:05:38 -0400 (EDT)
Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C50K9-00064g-UY for avt@ietf.org; Wed, 08 Sep 2004 07:09:27 -0400
Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id i88B6PF7008150; Wed, 8 Sep 2004 04:06:26 -0700 (MST)
Received: from motorola.com ([163.14.20.115]) by az33exr01.mot.com (Motorola/az33exr01) with ESMTP id i88AvJRv016438; Wed, 8 Sep 2004 05:57:20 -0500
Message-ID: <413EE7CF.4080807@motorola.com>
Date: Wed, 08 Sep 2004 19:06:55 +0800
From: Qiaobing Xie <Qiaobing.Xie@motorola.com>
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: sassan.ahmadi@nokia.com
Subject: Re: [AVT] RE: <draft-ietf-avt-rtp-vmr-wb-03.txt>: sampling rate
References: <0B08EA1BF5F6304992CDC985EE02209E02A7435F@sdebe002.americas.nokia.com>
In-Reply-To: <0B08EA1BF5F6304992CDC985EE02209E02A7435F@sdebe002.americas.nokia.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8
Content-Transfer-Encoding: 7bit
Cc: magnus.westerlund@ericsson.com, avt@ietf.org, csp@csperkins.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15
Content-Transfer-Encoding: 7bit

Hi, Sassan,

...<snip>...

>>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.

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


_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt