Giorgio Zoia wrote:
>
> [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
With the bemol maybe that floating point implementations may vary as John
pointed out in a recent post ?
> 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.
Thank you Giorgio for offering me such a wide range of options (just kidding,
you've done a great job Eric, Giorgio et al, and I guess I've just put my big
foot in it). Since I only discovered this fascinating SAOL concept a few days
ago I necessarily know very little about it, apart from some quick reading on
the net and trying out saolc and sfront, so please forgive my enthusiasm.
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 ;-)
> >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 ?
This I'm afraid I didn't quite get : why should I have low quality non
normative parts ? Is there something low quality and non normative in
determinism ? Does SFront have to give up determinism to be in the norm ?
> I suppose that
> the the market will defeat you in your market shell, more than you will
> defeat the standard. Am I completely wrong ?
I hope so ;-) But I have no intention to defeat the standard either. I just
meant it might (well, admittedly I didn't say "might") be defeated if people
have to turn towards a single implementation so their music sounds the same on
the author side and on the listener side, and the same every time you play it
(although the concept of a piece of music which sounds differently each time
has an indisputable artistic value I must admit. People would never get bored
with it and might even never need to buy another record for the rest of their
life ;-)
Peace,
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