Hello,
I have never posted to the list before but Alex Broadhead said that
something I may have figured out about the iso spec may be of interest
here. It's about the bug in the spec that states,
"If window_switching_flag is set, several other variables are set by
default:
region0_count = 7 (in case of block_type==1 or block_type==3 or
block_type==2 and mixed_block_flag)
region0_count = 8 (in case of block_type==2 and not
mixed_block_flag)
region1_count = 36 Thus all remaining values in the big_value
region are contained in region 1."
on page 26. and I think I figured out a very logical explanation:
The bug is in the number "36" for region1_count. My initial
question was in regards to the dist10 code which sets region1_count =
20 - region0_count, but to me this made no sense with how the spec was
worded especially in the definition for region0_count[gr][ch]. The
responses on the list indicated that people knew it was a bug, but that it
was a bug since there are 21 scalefactor bands and not 36. This I don't
think is the correct reasoning.
The number to me does look wrong, but for a different reason. When we are
talking about short blocks then we are talking about referencing a table
that has 12 scalefactor bands (assuming we dont count the last one where
the scaling is zero, as the spec doesn't.) In the spec on page 27 in the
def. for region0_count they refer to the fact that for short blocks
scalefactor bands are counted thrice, once for each window. This means (
and they say this in that same spot) that the number of scalefactor bands
for a pure short block granule is 36 = (3 * 12 sfbands for short blocks).
region0_count counts 1 minus the number of sfbands in region0, this value
(region0_count) is hard coded to 8 when mixed_block_flag==0, so there are
9 sfbands in region0. This means that the number of sfbands in region1 is
36-9=27. Since region1_count is the num of sfbands in region1 - 1 = 26.
Thus this value should be 26. This actually coincides perfectly with what
region1_count should be when mixed_block_flag is set. The spec states and
it can be confirmed that if mixed_block_flag is set then the number of
scalefactor bands equals 35 for the granule. This is 8 for the sfbands
counted from the long blocks table and then 3*(the 9 sfbands that are
counted from the short blocks table), 8+27=35, and so going from there
when mixed_blocks region0_count is hardcoded to 7, thus there are 8
sfbands in region0. 35-8=27, thus region1_count should be set to 27-1=26.
The error in the spec is a typo. The "3" should be a "2" (36 -> 26)
according to this logic.
This brings up an interesting point (assuming the logic is correct, which
it seems to be), which is how the dist10 code works. In its reading of
the side information the dist10 code sets the value of
region1_count=20-region0_count and then from there on never references the
value of region1_count if block_type==2. In the huffman decoder it simply
hardcodes the value of region1start to be 36 and the value of region2start
to be 576. This works almost as a coincidence. When short blocks then we
actually need to check whether mixed_block_flag is set to determine where
region0 and region1 are. If mixed block flag is set then we know that
region1_count==7 and the this "7" value is referencing the long blocks
table. In the long blocks table sfb[7] ends at the frequency line 35, thus
in this case region1start==36. If mixed_block_flag is not set, then we
are always referencing the short blocks table and region0_count is
hardcoded to 8. This means that there are 9 sfbands in region0 which
works out since 9 is divisible by 3 and each each sfband is counted
thrice. Thus sfbands 0,1,and 2 are in region0. These three scalefactor
bands combined have a total of 12 frequency lines in them if we ref the
table, thus with all 3 windows there are a total of 36 frequency lines in
all of region0, which means the last index would be 35, thus region1start
also equals 36 in this case. Interesting coincidence which is probably
the reason they hard coded 36 in the first place. Had they actually used
the formula for region1_count to figure out region1_start instead of
hardcoding it would have messed up in certain cases.
If you read this far you were prabably interested, so I wonder what people
think?
Nikhil
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
