Re: XSPF support for video chapters or index

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Re: XSPF support for video chapters or index

Jay Fienberg
> Date: Thu, 16 Oct 2008 20:51:52 +0200
> From: Sebastian Pipping <[hidden email]>
>
> I've been collecting a few ideas about a subsong/chapter concept.
> Let me present three possible approaches for an XSPF extension
> introducing this feature.  Feedback appreciated.
..snipped

It's interesting to think about these options (well-done fleshing  
them out). But,  I wanted to chime-in with a birds-eye view about this:

XSPF is a track-list format designed for track-oriented players (and,  
track = file). And, this is extension is getting into the realm of  
cue-lists and cue-oriented players.

IMHO, part of the issue with thinking about how XSPF might handle  
cues is deciding whether these are "real" cues or are just cue-like  
tricks for track-oriented players. In other words, are XSPF  
trackLists really about cues, or really about tracks,?

One of the functional differences, I assume, between track-oriented  
and cue-oriented players is that track-oriented players don't think  
about the list "as a whole," and can be lazier about loading tracks.  
Cue-oriented players need to think about the list "as a whole," read  
forward / look ahead on the cue list, and pre-load upcoming cues so  
that they can successfully hit them on time. Another way to describe  
this is: cue-oriented players see tracks in relationship to a larger,  
already mapped, timeline.

This difference must be more dramatic with Internet players, where  
the time to load a file is often significant and imprecisely known,  
and with a decent potential for error (compared with local files). A  
cue-oriented Internet music player would either need to pre-load most  
or all of the tracks, or have a decent user experience design for  
graceful degradation (and/or, FAIL).

Because of these differences, I think that your approach #1 (Tracks  
referencing container slices--copied below) is the right place to  
start for really handling cues. Basically, a XSPF document could  
contain both a standard trackList and a separate, extension-wrapped,  
cue-list. A cue-oriented player would want to use the trackList to  
load tracks, and the cue-list to play them. A track-oriented player  
would use the trackList for both loading and playing, and would  
totally ignore the cue-list.

Also, an extension-wrapped cue-list potentially could be a timeline-
event structured list, e.g.:

00:00: play track #1 (start: 00:00, stop: 05:00)
05:00: set title "My new mix"
05:00: set artist "Pseudo Hypothetical"
05:01: play track #3 (start:  00:12, stop: 01:00)
06:01: play track #4 (start:  00:00, stop: 02:00)
08:01: play track #2 (start:  00:00, stop: 00:12)

***

On the other hand, if the goal is to add cue-like tricks to tracks,  
approach #3 (Same track multiple times, different slice--copied  
below) seems a more pragmatic design for track-oriented players.

***

Also, for reference, most major digital music recording software  
utilizes cue-lists, and act as cue-oriented players. I use Digital  
Performer, and 99% of the interaction is with cues / timelines /  
events--it's rare to interact directly with files (the equivalent of  
XSPF tracks).

Jay


>
>
>> as in:
>>> Jay Fienberg
>>>> http://jayfienberg.com
>>>
>>
>
>




>
>
> == Approaches ==
> 1. Tracks referencing container slices
> 2. XSPF in XSPF
> 3. Same track multiple times, different slice
>
>
> == 1. Tracks referencing container slices ==
>
> === Properties ===
> - "Ignorant" XSPF processors will not find any locations
> - Feels like a "normal" playlist mainly
> - Supports arbitrary placement of subsongs in the playlist
> - <location> element forbidden for <track>s referencing a container
>
> === Example ===
> <playlist ...>
>   ...
>   <extension ...>
>     <container>
>       <location>...</location>
>       <location>...</location>
>       <slice xml:id="1">5000</slice>
>       <slice xml:id="2">10000</slice>
>       ...
>     </container>
>   </extension>
>   ...
>   <trackList>
>     <track>
>       ...
>       <extension ...>
>         <parent slice="1">
>       </extension>
>     </track>
>   </trackList>
> </playlist>
>
>
> == 2. XSPF in XSPF ==
>
> === Properties ===
> - "Ignorant" XSPF processors will understand it as a single track
> - Poeple don't have to learn anything new
> - Does not allow arbitrary placement of subsongs in the playlist
> - <duration> element mandatory for sub songs
> - <location> element forbidden for sub songs
>
> === Questions ===
> - Should track attributes inherited?
>
> === Example ===
> <track>
>   ...
>   <location>...</location>
>   ...
>   <extension ...>
>     <track>
>       <location>...</location>
>       <identifier>...</identifier>
>       ...
>       <duration>...</duration>
>       ...
>     </track>
>     <track>
>       ...
>       <duration>...</duration>
>       ...
>     </track>
>     ...
>   </extension>
> </track>
>
>
> == 3. Same track multiple times, different slice ==
>
> === Properties ===
> - "Ignorant" XSPF processors will understand it as
>   "the whole thing" several times
> - Supports overlapping and skipping of track slices
> - Supports arbitrary placement of subsongs in the playlist
> - Redundancy on locations
> - Alternative locations put extra burdon on XSPF processor
>
> === Example ===
> <track>
>   <location>...</location>
>   ...
>   <extension ...>
>     <begin>10000</begin>
>     <end>20000</end>
>   </extension>
> </track>
>
>
>
> Sebastian


_______________________________________________
Playlist mailing list
[hidden email]
http://lists.musicbrainz.org/mailman/listinfo/playlist