Re: [codec] Discussion around ITU LS

"Christian Hoene" <> Wed, 14 September 2011 10:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CB39E21F8C57 for <>; Wed, 14 Sep 2011 03:32:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.644
X-Spam-Status: No, score=-5.644 tagged_above=-999 required=5 tests=[AWL=0.605, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FwYU+RiYYaLu for <>; Wed, 14 Sep 2011 03:32:40 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D67D321F8C47 for <>; Wed, 14 Sep 2011 03:32:39 -0700 (PDT)
Received: from hoeneT60 ( []) (authenticated bits=0) by (8.13.6/8.13.6) with ESMTP id p8EAYMxx024867 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 14 Sep 2011 12:34:26 +0200
From: "Christian Hoene" <>
To: "'Jean-Marc Valin'" <>, "'Anisse Taleb'" <>
References: <> <> <> <> <> <>
In-Reply-To: <>
Date: Wed, 14 Sep 2011 12:34:24 +0200
Organization: =?us-ascii?Q?Universitat_Tubingen?=
Message-ID: <01b501cc72c9$e1a23a00$a4e6ae00$>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Content-Language: de
X-AntiVirus: NOT checked by Avira MailGate (version:; host: mx05)
Subject: Re: [codec] Discussion around ITU LS
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Codec WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 14 Sep 2011 10:32:40 -0000


> Hi Anisse,
> Keep in mind that what we are standardizing here is a format more than
> an actual implementation, so there's nothing that prevents anyone from
> using any stretching/shortening algorithm. And in fact, thanks to Google
> we now have an open-source time stretching/shortening algorithm as part
> of the GIPS NetEQ jitter buffer they recently released:
> Q/main/source/
> (see accelerate.c and expand.c more specifically). 

Yes, the algorithm actually quite similar to the one I have implemented. 
First, you downsample the signal.
Then, you make a crosscorrelation to find the pitch period.
Last, you do an overlap-add operation to smooth the removed pitch.

> So I have really no
> desire to reinvent the wheel.

No, but it also does not make sense to have an additional function to get
stretch, length, and lag of the pitch period and the energy level of the
signal if this data is already available at the decoder.
Calculating things twice does not make sense.

It would make sense to use the information available at the decoder and then
simply add an pitch drop and replication function together function at the
decoder output. That can be done easily (even by me).

Koen and Jean-Marc: With parameters in the Silk/CELT codec provide this


 Christian Hoene