[ID3 Dev] ID3 chapter tags feedback

[Patrick Schmitz]

Hi Chris - 

Hi Chris - 

Thanks for your comments and responses. Knowing the TV-Anytime heritage
helps a bit - I am also familiar with that (I went to some of those meetings
as well). Am beginning to wonder if we have met somewhere along the way...

I can see the point of using the absolute offsets for the leaf items, and I
think I see the parallel to the TV-Anytime model (which in turn was based
upon something like the DVD model, AIUI). For author time work, we would of
course use something a little more flexible, but we could flatten this for
export to ID3 tags.

I was forgetting that this is based upon a model for only 1 output channel,
and so there is no need for anything like sync, and there is no way to talk
about a mix of two or more items - e.g. allowing voice over some music where
this is actually mixed on the client. I presume that this sort of
functionality will be left to SMIL (et al.)?
 
So I think I am clearer on the TOC model of indicating whether there is a
sensible sequence of the children, or not. I presume that for the case of
"not", the presumption is that the items would be selected in some
interactive manner. In that case, the SMIL analogs are SEQ and EXCL rather
than SEQ and PAR. The "EXCL" time container constrains the playback to only
allow one child at a time, but does not impose any ordering the way SEQ
does. You can think of SEQ as a subclass of EXCL that adds sequential
ordering. SMIL EXCL also adds interrupt semantics (so you can pause a "main"
track to play other tracks, and the main track resumes when the interrupting
track completes). This sounds like it is more than what you want for this
application, but I thought I would mention it.

I have one more question, however. Why do you constrain a CTOC element to
only have one class of children? I have a number of use-cases I sketched out
that would be more cumbersome with this constraint, and so I was wondering
what the rationale was. Is there not a unified ID-space for the chapter and
CTOC elements? 

I have attached a simple drawing of the problem I am thinking about.

TOC1 is a CTOC with seq semantics, and describes the complete program as a
sequence of basic segments. Segments 1 and 3 have a set of proper
subsegments. Segments 6 and 7 are orthogonal segments.

The spec as is requires that I define a CTOC proxy for segments 6 and 7 in
order to place them into TOC0 along with TOC1. Similarly, since Seg1 and 3
must be CTOCs to describe the sequence semantics of their respective
subsegments, Segments 2, 4 and 5 must all have CTOC proxy elements that
exist only to point to the respective Chapter elements from within the TOC1
element.

Thanks - Patrick



> -----Original Message-----
> From: Chris Newell [mailto:chris.newell at rd.bbc.co.uk]
> Sent: Monday, October 17, 2005 2:25 AM
> To: Patrick Schmitz
> Cc: id3v2 at id3.org
> Subject: Re: [ID3 Dev] ID3 chapter tags feedback
> 
> Patrick,
> At 00:53 14/10/2005, you wrote:
> >Hi - I am new to this list, having just heard about the chapter tags
> work. I am a researcher at Yahoo Berkeley, working on annotation of time
> based media, and so we are naturally interested in the work going on with
> Chapter tagging of MP3 content.
> >
> >My colleagues and I went through the docs today, and our first impression
> is that we like much of what we see. We have a couple of clarifying
> questions, and some suggestions. I am no expert on MP3 "syntax" and header
> constraints, so forgive me if I make some silly suggestions that are not
> in the spirit of MP3.
> >
> >My background is with XML formats, and especially SMIL [*]. As such, I
> was translating in my head from the descriptions I read to how I think
> about descriptions for timing. I hope this is useful both from the
> perspective of clarifying the semantics as expressed in your docs, and as
> an introduction to producing a description of an XML schema that would
> parallel your work (e.g., as an interchange language for tools producing
> ID3 Chapter frames).
> >
> >In SMIL timing [**], there are two common time containers: "par" (for
> parallel) and "seq" (for sequence or sequential). Children of par elements
> have timing relative to the par, but can overlap one another with few
> constraints. Children of a seq are defined to be a sequence, and are
> constrained to play one after another, possibly with delays between any
> two items. While SMIL is defined for synchronization, the basic concepts
> can be applied to this case as a description of the relationship of the
> chapters in a CTOC element.  It looks to me like CTOC plus the "Ordered
> bit" in the flags is more or less equivalent to this - am I right?
> 
> Yes. I'm not very familiar with SMIL but this sounds like an identical
> concept.
> 
> >In the spec, the Chapter start time and end time are defined as being
> relative to the beginning of the file, and yet the CTOC structure implies
> that there is a hierarchy of chapter elements. I would think that it makes
> more sense to have the timing reflect the TOC structure. Thus if I have
> defined a major section of the file as a chapter, I can describe pieces
> within that section relative to the section begin, rather than from the
> beginning of the file. This means that start times and byte offsets must
> be added together to find an absolute offset into the file, but it also
> means that excerpting a section of the whole file is more straightforward
> (only the top-level offsets change).
> >
> >This would of course require that the CTOC elements also have timing
> information - does that conflict very much with your current thinking?
> 
> Although I can see the advantages during editing I think we should use
> absolute offsets within ID3 tags as this makes life easier for media
> players (often low profile devices).
> 
> Relative offsets would also break a useful feature of the current proposal
> - it's possible to refer to a CHAP frame from more than one CTOC. This
> allows you to provide more than one table of contents for a single file.
> e.g. for the recording of a rock festival you could provide:
>  - a full, temporally ordered table of contents
>  - a table providing an index of band names
>  - a table listing highlights
> 
> >We've been playing with some syntax to describe temporal extents in media
> as part of an annotation framework. We are developing the XML syntax for
> this now, but I can say that it borrows from SMIL timing syntax (although
> a good deal more constrained (simpler) than the expressivity of SMIL 2.0
> Timing. We are hoping that this would meld well with the ID3 chapter tags
> work, allowing us a means of encapsulating our semantics in an MP3 file.
> Have you done anything yet in the area of an XML syntax for the ID3
> chapter tags? We'd be happy to contribute to such an effort.
> 
> The inspiration for the chapter frame proposal was an open standard for
> Personal Video Recorders called "TV-Anytime" (http://www.tv-anytime.org/)
> which I've worked on for a number of years. TV-Anytime has an XML schema
> which supports chapters (they call it segmentation) and this maps quite
> well with the binary structures used in the ID3 chapter frame proposal.
> 
> Best regards,
> 
> Chris
> 
> 
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Dr J.C. Newell
> Digital Media Group, BBC Research & Development
> Kingswood Warren, Woodland Way, Tadworth, Surrey
> KT20 6NP  UK
> mailto:chris.newell at rd.bbc.co.uk      http://www.bbc.co.uk/rd
> Tel:   +44 (0)1737 839659
> Switchboard:   +44 1737 839500
> Fax:  +44 (0)1737 839665
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
> For additional commands, e-mail: id3v2-help at id3.org
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 2981 bytes
Desc: not available
URL: <http://lists.id3.org/pipermail/id3v2/attachments/20051018/c6e27ab4/attachment.gif>
-------------- next part --------------
---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org