> Maybe someone knows how to handle this, or if it is still something on
> the todo-list.
Two issues here:
-- If a file is meant to be streamed, the notes won't be arriving in
the score_file block of a StructuredAudioSpecificConfig -- instead,
they well be arriving as SA_access_unit chunks, either as SASL
score_line's or as MIDI midi_events. Note that sfront currently doesn't
let you encode SA_access_unit chunks, and can't read them, so in that
sense "streaming audio is on the things to do list" for sfront.
-- The ordering of chunks in a StructuredAudioSpecificConfig block
is not dictated by the standard -- they can come in any ordering.
Additionally, the notes in a score_file block aren't standardized
to be ordered either -- they could come in reverse-time order, and
your decoder would need to sort them first! These two points lead
to these conclusions:
-- treat the StructuredAudioSpecificConfig block as something you
expect to parse all the way through before beginning soundmaking;
if a performance is meant to be streamed, it will have a lightweight
StructuredAudioSpecificConfig block and the incremental stuff will
all be in the SA_access_unit (note that sample blocks, in addition
to MIDI and SASL, can also be in a SA_access_unit, so samples can
come 'just in time'.
-- don't rely on the ordering inside a StructuredAudioSpecificConfig
block being standardized, for each encoder it may be different.
--jl
P.S. Just got Eric's mail on this topic:
> saenc (the encoder bundled with saolc) currently, and I'm sure
> sfront in the future, produces a full bitstream.
Yes, SA_access_unit's are in sfront's future, although handling
these without the context of knowing how SA_access_unit's are
supposed to be integrated into the MPEG 4 file format as a whole
is going to be tricky, since class midi_event (to my knowledge)
won't be carring the timestamps a la' MIDI files, but instead will
need to infer timestamps from the rest of the file format, if in
fact the midi_event's are meant to be interpeted as score_line's
that have has_time=1 are interpeted (from my understanding, both
types of midi_event's will be supported, has_time=0, in which
case you process it when you receive it, and has_time=1, in
which you apply an inferred timestamp, but the midi_event itself
doesn't state its has_time value, that needs to be inferred from
the bitstream also).
--jl
This archive was generated by hypermail 2b29 : Wed May 10 2000 - 12:15:48 EDT