[codec] Comment on Opus Draft 07: Section 4 Range decoder

"Christian Hoene" <hoene@uni-tuebingen.de> Wed, 27 July 2011 15:14 UTC

Return-Path: <hoene@uni-tuebingen.de>
X-Original-To: codec@ietfa.amsl.com
Delivered-To: codec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A7A821F86DC for <codec@ietfa.amsl.com>; Wed, 27 Jul 2011 08:14:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.931
X-Spam-Level:
X-Spam-Status: No, score=-5.931 tagged_above=-999 required=5 tests=[AWL=0.318, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 74D1GeYetQR5 for <codec@ietfa.amsl.com>; Wed, 27 Jul 2011 08:14:38 -0700 (PDT)
Received: from mx06.uni-tuebingen.de (mx06.uni-tuebingen.de [134.2.3.3]) by ietfa.amsl.com (Postfix) with ESMTP id ACFAC21F873D for <codec@ietf.org>; Wed, 27 Jul 2011 08:14:37 -0700 (PDT)
Received: from hoeneT60 (modemcable004.100-203-24.mc.videotron.ca [24.203.100.4]) (authenticated bits=0) by mx06.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id p6RFENsx022318 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <codec@ietf.org>; Wed, 27 Jul 2011 17:14:30 +0200
From: Christian Hoene <hoene@uni-tuebingen.de>
To: codec@ietf.org
Date: Wed, 27 Jul 2011 11:14:22 -0400
Organization: Universität Tübingen
Message-ID: <008501cc4c6f$e1f7b550$a5e71ff0$@uni-tuebingen.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AcxMbtf/Se211NMuRLWvHn/xbK0S9g==
Content-Language: de
X-AntiVirus: NOT checked by Avira MailGate (version: 3.2.1.23; host: mx06)
Subject: [codec] Comment on Opus Draft 07: Section 4 Range decoder
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Codec WG <codec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/codec>, <mailto:codec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/codec>
List-Post: <mailto:codec@ietf.org>
List-Help: <mailto:codec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/codec>, <mailto:codec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Jul 2011 15:14:39 -0000

Hi,

some editorial comments to the opus draft version 7, Section 4.1 to 4.1.2

Section 4.1
========
1) You might want to move Figure 8 to this section or - even better - add a
small new figure showing range encoded bits and raw bits at the beginning
and the ending of a frame.

2) The sentence  "Let f[i] be the frequency of the _i_th symbol in a context
with _n_ symbols total." is not complete. Instead I would write "Let f[i] be
the frequency of the _i_th symbol. There are _n_ symbols in total and index
_i_ ranges from 0 to n-1."

3) I am not sure about the rules of using "_something_". Maybe, it would
make sense to use the notion for _variable_, only, if at all.

4) Also, fl should be renamed to fl[k] and fh to fh[k] to make things more
clear. This also implies a couple of changes in the following sections.

5) I would change "It then immediately normalized ..." into "The remaning
bit is used in Renormalization (Section 4.1.1.1) function, which is
immediately calld to reads further bits from the input so that rng become
than rng > 2**23.".  Otherwise, one cannot understand (if reading only
serial) the equations in 4.1.1.

Section 4.1.1
==========
1) In this paragraph, "The decoder ... identified symbol" one can introduce
the index k to denote the index of the identified symbol.

2) I have a question in respect of the "rng" variable for k=0: Why do you
use (ft-fh) instead of fh in the equation "rng = rng - (rng/ft)*(ft-fh)". 
Because of the reason given in the following paragraph? "With this
formulation, all the truncation..." Adding a sentence here would make things
more clearer. 

3) Also, you might move "After the updates... identified symbols" to the end
of this section 4.1.1. 

4) Page 19: "log"? Do you mean logarithm dualis?

Section 4.1.1.1
============
1) " Then it reads the next 8 bits of  
   input into sym, using the remaining bit from the previous input octet
   as the high bit of sym, and the top 7 bits of the next octet as the
   remaining bits of sym."

This sentence is unclear. Which bits are read where? I would suggest to
change it to

" Then it reads in to total 8 bits from the input stream into the variable
sym. Bit 2**7 is taken from the previous input octet has a remaining bit
(refer e.g. to the initialization of the 
   as the high bit of sym, and the top 7 bits of the next octet as the
   remaining bits of sym."

2) I know, it does not make a difference in C. However, not everybody can
remember the priority of operators all the time. Thus, I would suggest to
change it to
"((val<<8)+(255-sym))&0x7FFFFFFF." (Page 19)

3) Before "It is normal and expected that the range decoder will read
several
   bytes into the raw bits data (if any) at the end of the packet by the
   time the frame is completely decoded, as illustrated in Figure 8."
A section header is missing like "4.1.2 Reading the last bits". I also would
explain it better. For example 
"The Renormalization is reading continually bits from the frame until the
last octet of the frame has been processed. After that, the range decoder
still might need further bits to continue the decoding of the last symbols".
These bits MUST be set to zero."
(Technical question: Are you really using these zero bits for compression?
So to say, are you truncating the frame if the last symbols have an index
k=0? Otherwise, there is no need for to demand zero with MUST).
Cont. "If the last bit of the frame use for getting raw data (see new Figure
in Section4.1), then the range decoder will process them for decoding its
symbols." 

Section 4.1.2
==========
I am not happy with Section 4.1.2. First, you cannot understand the text
without looking up the source code (= decompressing it in your memory).
Also the functions are only optimizations and are not needed to understand
the range decoder algorithm. I would suggest to move Section 4.1.2 entirely
into the source comment making it a description of the function
(alternative, you may move them to an appendix).

======

Enough for now. I need a coffee.

Dear authors, 

just a request: If you are considering my input and if you are change the
draft, please send me brief feedback on which changes are included and why
the other are not considered. Thanks

With best regards,

 Christian Hoene


----------------------------------------------------------------------------
-----
Dr.-Ing. Christian Hoene, University of Tübingen, Computer Science, Chair of
Communication Networks, Research Group Interactive Communication Systems
(ICS)
Sand 13, 72076 Tübingen, Germany, Tel +49 7071 2970532,
www.net.uni-tuebingen.de