[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
- [codec] Comment on Opus Draft 07: Section 4 Range… Christian Hoene
- Re: [codec] Comment on Opus Draft 07: Section 4 R… Timothy B. Terriberry
- Re: [codec] Comment on Opus Draft 07: Section 4 R… Timothy B. Terriberry