Subject: [AVT] Resend of draft-ietf-avt-dsr-00.txt review ...

From: John Lazzaro <[email-masked]>
Date: Thu, 24 Jan 2002 13:06:53 -0800

Resending my draft-ietf-avt-dsr-00.txt review -- it looks like my
first attempt to post was mangled (at least it is in the archives.

> Stephen Casner writes:
>
> I have not seen other offers.  Have reviewing arrangements for other
> drafts been made off-list?

Here's my review of:

    Distributed Speech Recognition (draft-ietf-avt-dsr-00.txt)

[1] Spelling errors:

engin --> engine
engins --> engines
increacing --> increasing
recogziers --> recognizers

It looks like engin made it into someone's spell-checker dictionary,
given how many times this misspelling shows up ...

[2] Sentence structure:

  o "encapsulating a front-end signal processing feature streams"

    Plurality issue -- remove the "a".

  o "A solution that combats this uses a scheme called [...]"

    Never use "this" as a noun -- try:

    To address this problem, we use a distributed speech 
    recognition (DSR) architecture.

  o "The remote device processes the speech, compresses, and error protects
    the bitstream, [...]"

    Either remove the comma after "compresses", or add a noun phrase:

    compresses the data, and adds error protection to the bitstream

  o "Therefore, it will be desirable"

    Verb tense problems: you've committed to using present tense in
    this document, so a future-tense sentence like this one is not
    good style -- rewrite. Read through the document front to back
    looking for other future tense sentences, and rewrite them too!
   
  o "frame-pairs"

    Ditch the dash -- pair is the noun, frame is the adjective, the
    two work fine together without needing a dash.

  o "A decreasing number of FPs per payload packet [...]"

    The using of increasing/decreasing is bad form here -- we're not
    talking about dynamically changing the FPs per packet, we're 
    discussing the optimal number of FPs per packet as a static 
    decision. Rewrite.

  o "rises the potential of the loss of a large number"

    Bad English -- try:

    "increases the probability of catastrophic packet loss"

  o "A contiguous segment of DSR frames"

    Try:

    a set DSR frames coding an unbroken speech segment transmitted
    from the terminal to the server

  o "This is a lossy compression, with the output being a frame 
     containing an integer representation of the encoded speech."

    I tried reading this a few times, but I can't see why you'd
    bother noting the coefficients are integers -- I don't know
    of anyone coding mel-cepstra coefficients as floats or char
    strings :-). Delete or rephrase.

[3] IETF issues

   o At the head and the tail of the document, replace the 
     "expires in 6 months" phrase with the actual date of 
     expiration.

   o Someone with more experience in IETF stuff should search
     on RECOMMENDED, SHOULD, and MUST, to make sure each usage
     rises to the level where it deserves the all-caps, RFC-2119
     connotation -- I suspect a few of them are really lower-case
     in reality.

   o The bitfield figures lack titles -- add a "Figure N" and a title
     under each bitfield, and refer to each in the text as "Figure N."

[4] Content -- micro issues

    o Psychologically, its very comforting to see RTP headers on
      the top of payload bitfields -- it reminds people that the
      bitfield shown is the entire payload. So add them to the
      appropriate figures.

    o Explicit comments about the marker bit, timestamp, and 
      sequence number are in order -- even if each comment is 
      "no special usage or semantics", having such a comment
      acts to caution implementors not to do "embrace and extend"
      on the RTP header (the marker bit is always tempting ...). 
      Also, be explicit about the dynamic payload number, to 
      remind implementors the days of static payload numbers are
      over.

    o The packetization has a bunch of implicit decisions in it,
      about where in the transmission chain it makes sense to
      do the obvious "over-the-air" stuff (packing idx's and
      frames into sub-octets, and adding the 4-bit CRCs). By
      putting them in the RTP packet, instead of defining an
      octet-based, non-CRC packetization, the assumption is
      that general-purpose servers doing SR are better at doing
      bit-level ops than the device that interfaces the on-air
      to the first IP link. Specifically:

      [1] not zero-padding each idx coefficient to be 8 bits
      [2] failing [1], not zero-padding each frame or frame pair
          to be octet-aligned.
      [3] including the 4-bit CRC

      are consequences of this decision. Do people in the group
      feel comfortable with this decision?

[5] Content -- macro issues.

    I realize suggestions of the sort I'm about to make are out
    of place this late in the review process -- I'm bringing them
    up to inspire someone else to do a better next-generation 
    packetization, not because I expect the authors to start
    from scratch on this one :-).

    I think defining an unparameterized, plain-vanilla mel-cepstra
    front end is the wrong way to go. Back when I was doing SR
    work, so much of the difference between "usable recognizers"
    and "useless ones" revolved around customizing a basic 
    front-end algorithm (say, cepstra) to work well with a
    particular task and a particular back-end recognition engine.
    Many of these parameterization can't be done well (or at all)
    on the vanilla cepstra representation received by the server --
    it needs to be done as part of the front-end calculations.

    To be specific:

       -- the frame window length
       -- the frame window period (independent of window length)
       -- number and quantization of cepstra
       -- inclusion of C0 (volume) and pitch information
       -- alternative filter-bank spacing (other than mel-spacing)
       -- size of FFT used to compute cepstra on
       -- audio pre-emphasis and DC filtering
       -- use of spectral subtraction, RASTA, and other well-known,
          well-tested noise-reduction techniques, many of which have
          parameters as well

     A packetization that let a server and a handset negotiate a 
     common set of cepstra parameterizations based on the list above,
     falling back on the simplest default if all else fails, probably
     could halve your error rate in the real-world, relative to using
     a vanilla mel-cepstra. In addition, some of these parameterizations
     would serve to reduce the bandwidth for a given performance rate
     (most notably, customizing the number and quantization of the 
      coefficients). 

     I think this sort of scheme is doable, given the maturity of 
     RTP, SIP, and the speech recognition community's front-end lore.

-------------------------------------------------------------------------
John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley
lazzaro [at] cs [dot] berkeley [dot] edu     www.cs.berkeley.edu/~lazzaro
-------------------------------------------------------------------------

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