> Date: Thu, 16 Oct 2008 20:51:52 +0200
> From: Sebastian Pipping <
webmaster@...>
>
> 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
Playlist@...
http://lists.musicbrainz.org/mailman/listinfo/playlist
