On Mon, 24 Apr 2000, John Lazzaro wrote:
>Personally, I think that scenareo is quite reasonable -- people coming
>up with new ideas for encode-decode schemes, implementing the encoder
>in a language like C, generating an MP4-SA compatible bitstream, and
>implementing the decoder in SAOL that also becomes part of the bitstream.
But this does not address the problem of loss of structure. For instance,
automatic source level transformations of SAOL can be conceived if the more
traditional model of generative SA is used. But with only the decoder in
SAOL, this becomes difficult. Not to mention the loss of reusability in
orchestras.
>packed data, and then unpack it in SAOL. The issue here is, the
>sample wavetable generator converts these ints to floats between
>-1.0 to 1.0. Doing floating-point math to reliably extract (say)
>a 6 bit number concatenated to a 7 bit number concatented to a
>three bit number, give a float between -1.0 and 1.0 that codes
>the concatented triplet, may be tough to do -- roundoff will be
>your enemy.
If the conversion from reals to integers is properly implemented, there
should not be a problem. I've done this many times, even across
platforms. Can you say arithmetic coding? ;)
>Finally, its a good question to ask "why would you bother to do this"
>rather than just use the natural codecs already in MPEG 4 audio,
>assuming your terminals have both Structured Audio and the natural
>codec decoders built in? Three reasons come to mind:
>
>-- Special-purpose coding algorithms for subsets of natural sounds,
>like the singing voice in isolation.
I think there is something for this in the standard already. CELP comes to
mind. But the general idea is sound. What makes me worry is the abundance of
data types and the strength of computation needed to implement quality lossy
compression. I'm not sure anything but handcoded assembler or C will do for
a realtime architecture. SA largely depends on the orchestra being
'electronic' in the sense that extensive algorithmics outside the heavily
optimized filtering etc. operations are bound to be quite slow.
>-- Patent avoidance -- a public-domain natural coding algorithm can
>have both its encoder and decoder available as GPL'd software, and
>Structured Audio solves the problem of "how to get the decoder installed
>by the masses".
True enough. In a perfect world such IP issues would not exist.
>-- Experimentally deploying new general-purpose algorithms.
Agreed.
Sampo Syreeni <decoy@iki.fi>, aka decoy, student/math/Helsinki university
This archive was generated by hypermail 2b29 : Mon Jan 28 2002 - 11:46:39 EST