Re: streaming tempo event

From: John Lazzaro (lazzaro@CS.Berkeley.EDU)
Date: Wed Mar 15 2000 - 13:07:08 EST


Hi Marek,

        Here's how I've handled this issue in sfront (which,
as of 0.57, can handle SA_access_units in its -bit file, and
can also encode SA_access_units given a SASL file (-sstr file.sasl)
and a MIDI file (-mstr file.mid). I believe this is compliant:

-- All midi_event's in the SA_access_units, and all score_line's
that have has_time = 0, ignore tempo completely. This time these
events fire is the timestamp associated with the SA_access_unit
(in .sa files, a 32-bit float preceding each SA_access_unit --
a real MPEG 4 Systems file would be different ...), and this
timestamp is in absolute time, not scorebeats (i.e. number of
kcycles since the start of execution multiplied by 1/krate).

-- Score lines that have has_time = 1 use the timestamp inside
the score_line, instead of the SA_access_unit absolute timestamp.
The timestamp inside the score_line is in score time, not absolute
time, and thus is affected by the tempo. Sfront implements score
time internally not by "renumbering" scoretimestamps explicitly,
but rather by having a separate "scorebeats" relative time clock,
that gets advanced by the amount dictated by the current tempo.
                                
-- Right now, sfront encodes score_line SA_access_unit's with has_time
 = 1, and so it recognizes tempo commands on playback. Saolc
encodes with has_time = 0, which is why you didn't get tempo
command recognition.

-- Sfront encodes midi_line SA_access_units correctly -- i.e.
the absolute timestamp on the SA_access_units set the time. To
do this, on encoding a .mp4 file, sfront simulates all MIDI
and SASL tempo changes, and makes sure the timestamp embodies
the tempo commands. Note that settempo() SAOL commands are
not included in this encoding process -- the difficulty of
incorporating settempo() tempo changes into this tempo
simulation is why sfront encodes score_line SA_access_units
with has_time = 1, even though it makes the .mp4 file bigger.
A consequence of this behavior is, if you want the absolute
smallest .mp4 file out of sfront today, don't encode as
SA_access_units (i.e. use -sco filename.sasl, not -sstr filename.sasl).
And of course, don't use the -symtab option, since adding
a symbol table to the .mp4 can really add up the bytes.

I'm hoping the "pre-MPEG4-Systems" era for Structured Audio
binary files are short, and so I'll probably defer implementing
has_time = 0 score_line support until then, although if its
something people really want let me know and I'll consider
adding it sooner ...

                                                        --jl



This archive was generated by hypermail 2b29 : Mon Jan 28 2002 - 12:03:53 EST