Well, John's post in this thread says it all. SFront is the living proof that
determinism is possible, even with random number generators, even across
platforms at term.
Frankly, Eric, such determinism _should_ IMHO be normative in MP4-SA, i.e.
_nothing at all_ should be left open in the standard like random things,
reverb and spatialize are at the moment. Maybe it is still time with
corrigenda and things ? Otherwise one of the main points of MP4-SA, which is
that the music will be synthesized identically by any decoder conforming to
the standard, will be defeated I am afraid. People will have to rely on a
single implementation for their music to sound the same, which defeats the
standard too.
WRT the last paragraph of your mail below, normative determinism would make
conformance-testing a breeze too : decoders producing the right sound file
(byte for byte) for every single test orc-sco pair would pass, otherwise they
would fail. This would make things prodigiously simple for everybody.
No offence or criticism meant, just my FRF 0.02 :-)
Eric Scheirer wrote:
>
> >May I respectfully submit that non-repeatable random number generators (or
> any
> >other opcode) may result in perfectly smooth audio sometimes and awful
> digital
> >clipping on other times, even on the same implementation ? That's bad :-(
>
> Well, it depends what you do with the random number generators. If I
> ask for values between -1 and 1, then I lowpass filter them and use them
> to control the frequency of an oscillator (random jitter vibrato), it won't
> ever clip because the values, also unpredictable, are
> predictably bounded. It's important to have the non-repeatable ones
> built-in, because without some kind of system function (get the LSB 16
> bits of the clock) it's impossible to write them yourself.
>
> As I said in the last email, if you need repeatability, it's easy to write
> these yourself. Here is a simple (bad) example:
>
> kopcode myrand(seed)
> ksig state;
>
> if (seed != 0) { state = seed; }
> state = state * 1103515245 + 12345;
> if (state > pow(2,31)) { state = state - pow(2,31); }
> return (mod(state / 65536, 32768));
> }
>
> This is taken right from Numerical Recipes (although it's marked
> as bad there, and it won't work exactly right in SAOL because SAOL
> uses float arithmetic, not integer. But you get the idea).
>
> Maybe someone who is more expert in random numbers can write a
> good floating-point seedable random-number generator as a SAOL
> opcode that I can put on the web page...?
>
> >Are you telling me that non-repeatability of random number generators in
> saol
> >implementations is actually _normative_ ? I mean if a particular
> >implementation seeded its core noise gens with e.g. absolute time times
> >instrument instance number, which would make it random from the user's
> point
> >of view but repeatable from my point of view, would this implementation be
> >illegal ?
>
> No, I don't think so. There is only one implementation note on
> random numbers, which I quote:
>
> The following core opcodes generate noise, that is, pseudo-random
> sequences of various statistical properties. In order to provide
> maximum decorrelation among multiple noise generators, it is important
> that all references to pseudo-random generation share a single feedback
> state. That is, all random values required by the various states of
> various noise generators shall make use of sequential values from a
> single “master” pseudo-random sequence.
>
> It is strictly prohibited for an implementation to maintain multiple
> pseudo-random sequences to draw from (using the same algorithm) for
> various states of noise generation opcodes, because to do so may result
> in strong correlations between multiple noise generators.
>
> This point does not apply to implementations that do not use “linear
> congruential”, “modulo feedback”, or similar mathematical structures to
> generate pseudo-random numbers.
>
> The only normative thing that, say, krand() must do is
>
> "return a random number x chosen according to the pdf
>
> p(x) = 1/2p for x in [-p,p]
> 0 otherwise."
>
> >From this, I conclude that an implementor may choose to do it your way.
> But if a content author depends on such platform-specific behavior, it
> won't work on other implementations. It's better to assume that krand()
> is truly random, and write your own generator for the cases in which
> you want pseudo-random numbers that are controllable in some way.
>
> One final note: It's still an open question in MPEG how we should
> conformance-test the random number generators, so if anyone has any
> suggestions, they should speak up. For example, for a statement like
>
> x = kpoissonrand(1e6)
>
> x should be zero except for one value every 11 1/2 days (on average) which
> is 1.
> (Maybe this is part of some conceptual installation piece). It's
> really hard to tell if an implementation has implemented this right
> without waiting around for years to collect statistics!
-- Greetings, Michel ......................................................................... Michel Jullian Directeur General email mj@exbang.com Exbang Industries S.A. Mas Chauvain route de Villeneuve tel +33(0) 499 529 878 Maurin 34970 Lattes France fax +33(0) 499 529 879 .........................................................................
This archive was generated by hypermail 2b29 : Wed May 10 2000 - 12:15:29 EDT