[Playlist] call for clipping format proposals

[Jim Sowers]

I have been lobbying for extensions from a DJ perspective. (Actually, 
Lucas asked me to write up a spec, which I'm not sure how to do.)  But 
here are a few basic concepts that would be nice to capture for basic DJing:
* like clipping -- a start point, but with a % volume setting, a time 
until full volume, and a fade function, i.e., linear, logorithmic
* fade out point -- some criteria as fade in
* two tracks should be able to be overlaid, such that one track is 
fading out whilst the other is fading in.

That in itself, could be huge.

Advanced stuff would be identifying a section and having it loop N 
times.  However, this would probably be part of an extended DJ  version.

jim (SpinCycle)

Ryan Shaw wrote:
>>> What are the use cases for the developer who might implement this?
>>> Remix? Time-based annotation? Time-based triggers for other media?
>>> Podcast excerpting?
>>
>> Use case #1: there is a video of a speech by a politician, and the
>> video is licensed in a way which prevents third parties from hosting a
>> modified copy.  Clipping functionality would allow a user to create a
>> highlights reel containing notable sections.
>>
>> Use case #2: there is a concert recording, and the recording is
>> licensed in a way which prevents third parties from hosting a modified
>> copy.  Clipping functionality would allow a user to address a single
>> song within that concert.
>>
>> Use case #3: there are a set of recorded jazz performances which
>> contain segments that an educator wants to use as examples, and the
>> recordings are not licensed in a way that allows the educator to host
>> a modified copy.  Clipping functionality would allow the educator to
>> publish the set of examples.
>>
>> I hadn't thought of the time-based annotation application, but now
>> that you bring it up I think it's really good.
>
> Here's a strawman proposal:
>
> We want to enable client-side clipping for media being served from 
> sources that do not support server-side clipping. This means that the 
> client will either A) progressively download the source media until 
> the clip start point is available, or B) use the clip timings to guess 
> at byte ranges and make HTTP byte-range requests.
>
> (For server-side clipping XSPF support is a non-issue. Servers that 
> support clipping will have a server-specific URI scheme for specifying 
> ins and outs, and these URIs can be used in standard XSPF <location> 
> elements.)
>
> How about just allowing multiple <clip> elements under a <track>?
>
> <playlist xmlns:cl="http://example.com">
>    <trackList>
>       <track>
>           <location>http://example.com/song_1.mp3</location>
>           <clip start="00:00:03.000" end="00:00:10.000"/>
>           <clip start="00:00:15.000" end="00:00:20.000"/>
>           <clip start="00:00:18.000" end="00:00:25.000"/>
>       </track>
>    </trackList>
> </playlist>
>
> The "start" and "end" attributes use NTP time code format.
>
> The "end" attribute is optional, if it is missing the clip extends to 
> the end of the media.
>
> Clips can overlap.
>
> Clips can have gaps between them.
>
> Players that support client-side clipping should play only the pieces 
> of the media that fall within the specified clip ranges. In this case, 
> the range from 00:00:18.000 to 00:00:20.000 would be played twice.
>
> Players that don't support client-side clipping should ignore the 
> clipping stuff and play the source media in entirety.
>
> Clip elements should support <link> or <extension> sub-elements, for 
> example to specify URIs of content (annotations, images, etc.) that 
> are relevant to the clip.
>
>
>
>
> _______________________________________________
> Playlist mailing list
> Playlist at lists.musicbrainz.org
> http://lists.musicbrainz.org/mailman/listinfo/playlist