This raise the question if these (recording the broadcast or having logfiles
and analyze methods) are 2 worlds, or must they be combined:
Having a log which display broadcasted items, with the possibility to click
on one and listen the sound.
Which format is common to record sound? Especially, how the files at the end
are dividet? By day or hour, by playlist, by single song (which would losse
transition info)?
This is something I've talked with Akos about as well. In many countries,
a simple text log file is not enough; you have to have a sound recording
of the broadcast. But this is something where a text log could be combined
with the sound file using SMIL. SMIL allows you to annotate audio; in this
case, the annotation would be the in and out points of files, so that in a
long (let's say 4-hour) recording, you could put the in and out points at
the points in the broadcast that correspond to the log, but have all that
in a single SMIL file.
> This is something I've talked with Akos about as well. In many countries,
> a simple text log file is not enough; you have to have a sound recording
> of the broadcast. But this is something where a text log could be combined
> with the sound file using SMIL. SMIL allows you to annotate audio; in this
> case, the annotation would be the in and out points of files, so that in a
> long (let's say 4-hour) recording, you could put the in and out points at
> the points in the broadcast that correspond to the log, but have all that
> in a single SMIL file.
This is *not* accepted. Must be one big audio file over here. Because the
same thing could apply for television with 'text-tv'. For text-tv you
generaly have 20 minutes of broadcast repeated. You must record that 20
minutes for two weeks long (ok it differs per day, but you get the
point)
I think we're in general agreement. Czech stations use VHS tapes, which
generally record in 12-hour mode, so the file could be of indeterminate
length. How long the file is is something the user can decide, based on
legal requirements and on what their hard disks can store.
My point was that by making use of the work Akos has already done on
implementing SMIL, we could combine the text and sound files in a new way,
providing automatically annotated sound files, essentially putting tags on
timestamps in the sound file that correspond to text entries in the log.
This would help to ensure proof of broadcast by providing not only the log
of the item, but also its actual sound output.
doug
Stefan de Konink
12/06/2005 10:39 PM
Please respond to livesupport-dev
> This is something I've talked with Akos about as well. In many
countries,
> a simple text log file is not enough; you have to have a sound recording
> of the broadcast. But this is something where a text log could be
combined
> with the sound file using SMIL. SMIL allows you to annotate audio; in
this
> case, the annotation would be the in and out points of files, so that in
a
> long (let's say 4-hour) recording, you could put the in and out points
at
> the points in the broadcast that correspond to the log, but have all
that
> in a single SMIL file.
This is *not* accepted. Must be one big audio file over here. Because the
same thing could apply for television with 'text-tv'. For text-tv you
generaly have 20 minutes of broadcast repeated. You must record that 20
minutes for two weeks long (ok it differs per day, but you get the
point)
Douglas.Arellanes@mdlf.org wrote:
> I think we're in general agreement. Czech stations use VHS tapes, which
> generally record in 12-hour mode, so the file could be of indeterminate
> length. How long the file is is something the user can decide, based on
> legal requirements and on what their hard disks can store.
Ok, that was the situation here too. VHS tapes and replacing them
Memories
> My point was that by making use of the work Akos has already done on
> implementing SMIL, we could combine the text and sound files in a new
> way, providing automatically annotated sound files, essentially putting
> tags on timestamps in the sound file that correspond to text entries in
> the log. This would help to ensure proof of broadcast by providing not
> only the log of the item, but also its actual sound output.
If you place them in an ogg container, why don't you add the information
to it 'on the fly'?
We currently use our stations internet stream encoder (gstreamer) as
primary source for Video and Audio logging. Every hour the client gets a
killall and because it runs from within a bashscript a new time is
added. I agree, not quiet professional, though it works sweet with ogg.
Stefan de Konink wrote:
> The 'proof-of-broadcast' playlist of our current broadcast system, is just
> artist-title. That is generally speaking not enough. For local stations
> this is not an issue because there is another rights scheme for us.
yes, how I see it, broof of broadcast and broadcast archive is two
separate issues. of course they coincide based on time, and could be
presented us such from a user point of view, but at first I won't mix
the two..
Stefan de Konink wrote:
> We currently use our stations internet stream encoder (gstreamer) as
> primary source for Video and Audio logging. Every hour the client gets a
> killall and because it runs from within a bashscript a new time is
> added. I agree, not quiet professional, though it works sweet with ogg.
we do that same at Tilos Radio, only we use darkice instead of gstreamer...