[Eric]
>If you only use the precisely-defined functions (and I can produce a
>complete list with some time if you'd like, or maybe Giorgio has one
>sitting around), then each output wave is exactly the same in the way
>you need. And will be the same whether you're using sfront, saolc,
>or any other implementation.
>
I have a table that for sure is too much complicate for a discussion like
this one, but I try to summarize it in its fundamentals. I hope I didn't
omit something important
*******************************************************************************
Math functions: precise definition
Pitch converters: precise definition
Table operations: precise definition except tableread and oscillators,
where interpolation is non normative (if interp == 1 in
the global block of the orchestra)
Signal generators: precise definition except pluck and grain, where
interpolation is non normative (as before)
Noise generators: the output is not deterministic
Filters: port has a precise definition
hipass, lopass, bandpass and bandstop are non normative (once the
-6 dB criterium is satisfied)
biquad, comb and allpass have precise definitions
fir, iir, firt and iirt are open in implementation methods, but the
output of course is specified
Spectral analysis: fft and ifft (radix-2) have a precise output (same as
fir etc.)
Gain control: rms, gain, balance have precise definitions
compressor has a non normative part only in the soft-knee
curve zone
Sample conversion: precise definition
Delays: delay and delay 1 have precise definitions
fracdelay has precise definition except for method 2 (tap) because
of the interpolation (as before)
Effects: non normative
Tempo functions: precise definitions
Other than core opcodes, the spatialize statement is also non normative
******************************************************************************
[Michel]
>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 ?
I think there has been enough time in MPEG to discuss these issues (from July
'97 until March '99 if I remember well) and this is the result. Then I don't
want to spend any more words about this being the best solution or not. This is
the MPEG4-SA. "Corrigenda" is a curious verb tense in latin that stands for
"to be corrected"; we can correct evident errors, typing mistakes, normative
text vs. reference software (i.e. saolc) and things like that. But if you read
carefully the list above you see that what you frankly propose is to rewrite
a good portion of the standard. The only choice left now is to implement or
not MP4, I fear.
>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.
There is another part of the standard that is called Conformance and is not
yet at the final point. There you will find specified precise levels of
complexity
to be supported to claim compatibility with MPEG4. And if your chosen level
will imply supporting SA with some high constraints, with some high values for
fl operations, memory, tests, filters etc., what will be the gain in having
such a
high quality decoder and low quality non normative parts ? I suppose that
the the market will defeat you in your market shell, more than you will
defeat the standard. Am I completely wrong ?
Best regards to all,
Giorgio
__________________________________________________________________
Giorgio ZOIA
Integrated Systems Laboratory - DE/LSI - EPFL
CH-1015 Lausanne - SWITZERLAND
Phone: + 41 21 693 69 79 E-mail: Giorgio.Zoia@epfl.ch
Fax: +41 21 693 46 63
__________________________________________________________________
This archive was generated by hypermail 2b29 : Wed May 10 2000 - 12:15:29 EDT