Michel Jullian wrote:
>Only allow me to respectfully submit that MP4-SA _as such_ should not be
>advertised as a lossless compression method as it is currently, for example
cf
>figure 2 of :
>
>http://sound.media.mit.edu/mpeg4/sa-tech.html#compression
>
>Fortunately, one implementation, SFront, _is_ lossless (repeatable), as I
hope
>many others will be ;-)
It's crucial to me to make the distinction between "allowable" normative
decoding
and "absolute" normative decoding. For you as a content author, if you want
your bitstreams to be decoded exactly the same way, within the limits of
numerical precision (differences in multiplication from one platform to
another),
this is always possible. You don't get to use the full array of built-in
opcodes
and table generators and your bitstreams might not be as efficient, but this
is a decision that is up to each musician.
The standard *is* lossless in this sense. For example, in the forthcoming
paper
that inlcudes the implementation of a Turing machine in SAOL, I use only
addition and tableread() and tablewrite() at integer positions (ie,
non-interpolating
tablereads). These operations are exactly normative on every platform to
the
limits of differing implementations of a 32-bit "+" operation. Therefore,
it
is possible to implement *any* computable algorithm to equivalent levels
of normativity. Past that point, it is simply a tradeoff of convenience for
slight
amounts of normativity.
With regard to your question of "repeatability" and the random number
generators,
I don't know whether you are understanding my point that it is very easy for
the
content author to deliver new random number generators that always give the
same result. It is essential to me to allow the other sort--nonrepeatable
ones--
as built-in functions, because sometimes artists want this, *AND THERE IS
NO WAY TO DERIVE THEM FROM MORE BASIC OPERATORS*. This is not
the case with repeatable psuedo-random functions--you might want them,
but they can be easily derived from more basic functions like arithmetic.
So
there is no loss in functionality if the standard does not include these
functions
built-in, because the content author can deliver quite precise ones.
The same one is true of functions like reverb(). There was some early
debate
about whether to include a reverb() function at all, because of the danger
of
confusing authors into thinking they *must* use the nonnormative one, and
clearly we didn't want to specify a single normative reverb function. To
me,
the existence of a nonnormative "convenience" function for reverb() is a
good
tradeoff. If you don't care too much about exact sound quality, as many
multimedia developers unfortunately feel, having a built-in parametric
reverb that's easy to use is nice. But if you really care about sound
quality,
you write your own with allpass(), fracdelay(), biquad(), etc -- all of
which are
defined down more normatively -- and deliver it as part of the music.
(And if you really care about *precisely* normative sound quality, you can
rewrite
fracdelay() with some desired interpolator, since fracdelay() uses
interpolation
which is non-normative ("must be better than linear interpolation") at high
quality setting, and deliver that new fracdelay() as part of the content.
Then
your new reverb can be normative and repeatable down to the precision
of the arithmetic.)
None of these issues depend on any particular implementation. Of course
bitstreams that use the nonnormative functions might sound different from
one platform to another. But to me, this is not an indication that authors
should "target" their sounds to one particular implementation, as much as
that they should understand these aspects of normativity in SAOL so that
they can make their bitstreams as portable as they want to.
As John pointed out, it's a difficult decision what to do about arithmetic.
This
goes both for the word length (Michael Gogins has been agitating for years
to do all computer music in 64-bit arithmetic), and for using a particular
standard (like IEEE) for the math operations. In my opinion, MPEG made
the right tradeoff by using 32-bit unspecified operations--any more precise
than this, and you start to radically restrict the hardware options for a
conforming implementation.
To me, the singlemost goal of the SA project
was to encourage more robust and active work on hardware implementations
of software synthesis--to move software synthesis away from academic tools
and into a fundamental part of the PC architecture, maybe even as part of
the sound card. If it requires giving up a small amount of normativity or
even sound quality to do this, that's a worthy tradeoff. It wouldn't help
anything
to have a standard that was so beautifully precise and high-quality that
people refused to implement it!
(In fact, the first wave of criticisms that we encountered with the original
SA
proposals, and this was in early 1997, were that it wasn't possible to
implement on a M56000, "which is the standard audio DSP solution." Many
people thought we should use only 16-bit fixed point arithmetic--in that
environment, 32-bit floats are a good compromise and it would have been
overreaching to go for 64-bit IEEE arithmetic, which as far as I know, isn't
available on *any* DSP that's shipping today.)
Best,
-- Eric
This archive was generated by hypermail 2b29 : Wed May 10 2000 - 12:15:29 EDT