>However (and I think Eric would agree here) its important to
>keep alert for inconsistencies between saolc and the standard
>when looking through the saolc code -- there may still be bugs
>left to be found in the saolc code, and its better to flush the
>bugs out now, rather than to enshrine them as "features" by
>copying the buggy behaviors into other implementations.
Yes, I couldn't agree more! saolc is not perfect, by any means --
and while in general I think it's good to have a single reference
implementation, it seems awfully dangerous to privilege the *bugs*
in the implementation as well as the correct things.
> If I remember well a clear understanding of how the standard
> works can be found in saolc, saol_sched.c, scale_sched_events
> function: saolc is not just *the first* implementation, it is the
> reference software, and in this sense it has the same value
> of the text for every part that is normative.
Of course this is strictly the MPEG policy, but we must be careful
how far down that path we proceed. When the standard is
ambiguous, the reference code can perform a useful service
in disambiguation. But when either the standard or the
software is wrong, we should fix things, first among ourselves
as a community, and later by submitting the fixes to ISO.
The important thing to me is to have the broadest number
of implementations doing things right, not just adhering
to the reference software. If this means in some places,
the reference software must be considered "wrong", that's
fine and we can fix it.
One of the useful things about having normative software is
that it provides a second-level check on the standard. If
they don't match, you know it's an area to tread carefully.
And the proportion of places where both the standard and
the software are wrong in the same way should be very small
| Eric Scheirer |A-7b5 D7b9|G-7 C7|Cb C-7b5 F7#9|Bb |B-7 E7|
|firstname.lastname@example.org| < http://sound.media.mit.edu/~eds >
| 617 253 1750 |A A/G# F#-7 F#-/E|Eb-7b5 D7b5|Db|C7b5 B7b5|Bb|
This archive was generated by hypermail 2b29 : Mon Jan 28 2002 - 11:46:35 EST