[Playlist] time offsets and annodex

Brown, Dave dabrown at yahoo-inc.com
Mon Nov 1 00:18:59 UTC 2004

How about using multiple <location> nodes? 

-----Original Message-----
From: Lucas Gonze [mailto:lgonze at panix.com] 
Sent: Sunday, October 31, 2004 3:44 PM
To: New playlist format discussion
Subject: Re: [Playlist] time offsets and annodex

On Sun, 31 Oct 2004, Robert Kaye wrote:
> (If we accept this approach we will need to change the spec from
> "xspf:track elements MUST be rendered in the order in which they appear"
> to
> "xspf:track elements MUST be rendered in the order in which they 
> appear, unless the playlist provides hints for an alternate playback
> But we should probably do that in any case.

I am a definite +1 on that.

> And I would like to add shuffle instructions. And I think the answer 
> to both of these requests should be *NO*. I like keeping XSPF simple 
> as it stands now
> -- I think we're on to a pretty good standard.

:( There's a trick to clipping, though.  I think that clip info has to apply
on a per-resource basis, since different resources might have different
start and end points.

Let's say there's a speech that's ten minutes long.  There's a URI for the
whole thing -- http://speech.com -- and another URI for just the first
minute -- http://speech.com/minute/1.  Let's say you wanted to put that
first minute in a track, and you wanted to be able to use both URIs in case
one went down:

<clip start="0" end="60s">http://speech.com</clip>

(I'm using "clip" here as a placeholder for "some XML that leads to

The point is that the clip info has to show up in the same place as the
location or id.

The reason I bring this up is to show that clip offsets which appear
anywhere but in the location or id element will have to deal with some extra
complication to associate themselves with the target.  EG:

<extension clip>

...and this seems like rather more of a drag than just:
<location start="0" end="60s">http://speech.com</location>

One last point about that.  It seems to me that the start and end params are
non-optional, so XSPF processors would be required to deal with start and
end if they claim to deal with the item at all.  That would require a change
to the spec that would break backwards compatibility, so would have to wait
for the next time we increment the version and change the namespace.


I can think of a third method as well -- putting the clip params in a new
URI type.

For example:


I have to think about your <extension> idea for a bit before I know what I
think of it!

- Lucas

> However, I really like the idea of clipping and playback hints 
> (shuffle), so I spent more time digging into namespaces and I made the 
> XSPF spec
> extensible:
> http://mayhem-chaos.net/stuff/xspf-draft-8-ext.rng
>    <extension>
>        <sh:shuffle order="random"/>
>    </extension>
Playlist mailing list
Playlist at lists.musicbrainz.org

More information about the Playlist mailing list