This is very beneficial for the scale factor tables where 4*64+4*15
bytes of length information can be replaced by eight codebooks of 12
bytes each; furthermore the number of codes as well as the maximum
length of a code can be easily derived from said codebooks, making
tables containing said information superfluous. This and combining the
symbols into one big array also made an array of pointers to the tables
redundant.
For the wordlen and code table tables the benefits are not that big
(given these tables don't contain that many elements), but all in all
using codebooks is also advantageouos for them. Therefore it has been
done.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
ATRAC3+ uses VLCs whose code lengths are ascending from left to right in
the tree; ergo it is possible (and done) to run-length encode the
lengths into so-called codebooks. These codebooks were variable-sized:
The first byte contained the minimum length of a code, the second the
maximum length; this was followed by max - min + 1 bytes containing the
actual numbers. The minimal min was 1, the maximal max 12.
While one saves a few bytes by only containing the range that is
actually used, this is more than offset by the fact that there needs
to be a pointer to each of these codebooks.
Furthermore, since 5f8de7b741 the content
of the Atrac3pSpecCodeTab structure (containing data for spectrum
decoding) can be cleanly separated into fields that are only used during
initialization and fields used during actual decoding: The pointers to
the codebooks and the field indicating whether an earlier codebook should
be reused constitute the former category. Therefore the new codebooks are
not placed into the Atrac3pSpecCodeTab (which is now unused during
init), but in an array of its own. The information whether an earlier
codebook should be reused is encoded in the first number of each
spectrum codebook: If it is negative, an earlier codebook (given by the
number) should be reused.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This allows to remove lots of pointers (130) to small symbol tables;
it has the downside that some of the default tables must now be coded
explicitly, but this costs only 6 + 4 + 8 + 16 + 8 bytes and is therefore
dwarfed by the gains.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The ATRAC3+ decoder currently uses ff_init_vlc_sparse() to initialize
several VLCs; sometimes a symbols table is used, sometimes not; some of
the codes tables are uint16_t, some are uint8_t. Because of these two
latter facts it makes sense to switch to ff_init_vlc_from_lengths()
because it allows to remove the codes at the cost of adding symbols
tables of type uint8_t in the cases where there were none before.
Notice that sometimes the same codes and lengths tables were reused with
two different symbols tables; this could have been preserved (meaning
one could use a lengths table twice), but hasn't, because this allows
to use only one pointer to both the symbols and lengths instead of two
pointers.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Andreas Rheinhardt