[Playlist] Spacing between tracks (possible extension, related to fade / start / end)

[Jay Fienberg]

Hi XSPF list,

(I am new to the list, though I've tried to be well read via the 
archives. Please excuse any suggestions here that are out of sync with 
your discussions, e.g., re: extension syntax, etc.)

I am composing some music that I want to distribute as/with a XSPF 
playlist of tracks. The music is meant to be heard as a continuous 
piece from start to finish, but (as in classical music, film scores, 
etc.) it also has distinct sections that can be listened to separately.

I want to use XSPF for my music because I think playlists are exactly 
the right way to tell a computer that a bunch of separate sections / 
files can be grouped together and played in a particular sequence. And, 
I wanted to suggest an extension / spec addition that would indicate 
the spacing between tracks that the player should introduce. For this 
particular music I am creating, I want to be able to indicate that the 
player should (if possible) not introduce any spacing between tracks.

Also, I think this extension / spec idea can be related to the start 
time / end time and crossfade discussions I have read on the list.

So, most simply, the idea is to indicate the duration of silence 
between one track and next. While this gap could be specified as being 
either before, after, or both before and after the track, I'll just use 
the example of silence before the track.

This might look like: <track spacingBefore="1000" ... > to indicate 
that one second (1000 millisecond) of silence should occur before the 
track plays.

This could also appear "globally" at the trackList level to indicate a 
single value that should be applied before all tracks:

<trackList spacingBefore="0" ... > to indicate no spacing between any 
tracks.

Additionally, a negative number could be used at the track level to 
indicate a time relative to the preceding track, e.g.:

<track spacingBefore="2000" ... >
<track spacingBefore="-10000" ... >

This could indicate that the second track should start playing 10 
seconds before the end of the preceding track. I imagine this could be 
used as the timing part of specifying a cross-fade (the relative volume 
changes would obviously require other attributes).

***

I haven't coded any media player sophisticated enough to do these 
things, but from my limited experience working with code to play media 
files, it seems like these things require players that can "look ahead" 
in playlists (e.g., one thread starts playing and another is seeking 
out upcoming events and getting them appropriately "cued up"). I am 
guessing that many current players don't look ahead in this way.

What I'd like to imagine is that some media players start to support 
lookahead operations that can include downloading files sooner than 
later and also doing the calculations that translate timing cues to 
byte ranges in the specific files in hand.

(One of the things I don't like about the HTTP Byte Range approach to 
getting parts of a piece of music is, at the human-level, it requires a 
person to take the sensible concept of a time cue and calculate it in 
the machine-level terms of a specific file's byte range--which then 
doesn't translate to different versions of the file, e.g., the same 
point in time will be a different byte offset in a FLAC version than a 
MP3 version.)

I mention this because it might make sense in XSPF to indicate 
something about all of this in the trackList element. Something like:

<trackList lookahead="required">
<trackList lookahead="preferred">

The default case would be the current XSPF spec, where there is no 
lookahead attribute, and no assumption of any lookahead processing. 
And, current players that do not support lookahead, with simple 
modification, could catch the "required" case and throw an error. The 
"preferred" case would be a hint that players could safely ignore when 
they can't lookahead.

Another way to say all of this: there are playlists that don't assume 
any complex timing relationship between tracks, and there are playlists 
that either prefer or require complex timing relationships. If it makes 
sense to support playlists with more complex timing in XSPF, perhaps 
this distinction is one that belongs near the top level of a XSPF 
document. I imagine this would help with the design of extensions at 
the track level, like start / end times, crossfades, and spacing 
between tracks.

Thanks is advance,

Jay
of the Ear Reverends - http://earreverends.com