[Mp4-tech] [audio] max_sfb name is misleading?

[S. R. Quackenbush]

Daniel,
Thanks for your comment. The history of "max_sfb" is that it is the maximum
sfb that is coded in a given block and group, while num_sfb is a parameter
dependent on the sampling rate and long/short block that is a given. So I
agree that it may be confusing, and it is not very satisfying to say that it
"made sense at the time" but it is difficult to make editorial changes in
such a huch a huge document (as MPEG-4 Audio).
Best,
Schuyler
---
Schuyler Quackenbush    Chair, MPEG Audio Subgroup
President, Audio Research Labs
336 Park Ave, Suite 200, Scotch Plains, NJ 07076
phone: 908 490 0700     srq audioresearchlabs.com
fax:   908 842 9151     www.audioresearchlabs.com
  -----Original Message-----
  From: mp4-tech-bounces lists.mpegif.org
[mailto:mp4-tech-bounces lists.mpegif.org]On Behalf Of D.Domazet
  Sent: Monday, May 24, 2024 6:56 AM
  To: mp4-tech lists.mpegif.org
  Subject: [Mp4-tech] [audio] max_sfb name is misleading?
  Hi all,
  This question relates to MPEG-4 GA audio (AAC).
  I think that the max_sfb bitstream element's name is a bit misleading.
  In ISO 14496-3 max_sfb is described as: "number of scalefactor bands
transmited per group...". so wouldn't it be better to name it
num_sfb_per_group.
  Decoding goes like this (this repeats many times during coding process):
  for(g=0; g<num_window_groups; g++)
  {
      for(sfb=0; sfb<max_sfb; sfb++)
      {
          ...[g][sfb] =... ;
      }
  }
  Wouldn't it be more reasonable to have:
  for(g=0; g<num_window_groups; g++)
  {
      for(sfb=0; sfb<num_sfb_per_group; sfb++)
      {
          ...[g][sfb] =... ;
      }
  }
  If we look at the standard, very ofter we have max_sfb lower than num_sfb,
and as it's name says "max", it should me possible maximum of something (in
this case sf bands), and it is not. For example, for short windows at 44.1
kHz, we can have 120 sf bands, and at the same time max_sfb is 15 or lower!
I think that max_sfb should be 120, and actual num_sfb 15, not vice versa.
  Whoever is responsible for the naming should (at least) think about this.
  Any comment is appreciated.
  Thanks,
  Daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/mp4-tech/attachments/20040524/43ad575a/attachment.html