Lucas Gonze wrote:
>
> Can you talk about what's inside the package? How is it structured?
> What are the parts? How do you do metadata? Do you have some kind of
> manifest file or metadata file; what's the structure of the readme
> metadata file?
>
What we have released today is very simple - as long as its a ZIP its an
Album. That is because the artists themselves create the ZIP files and
upload them for sale. We then extract out each individual media file
from the ZIP so that they can easily modify the metadata, thumbs, etc.
and decide if they'd like to release them as singles.

Once we have better tools for the artists to construct an album we'll
then introduce a more formalized MixPlay Album structure. Our thoughts
on this have been exploratory. These are not suggestions as much as just
some abstract ideas created in a vacuum w/o referencing enough what
already has been done here:

*********
.BUM Format (based on ZIP/JAR)

album table of contents = the "index.html" of this format; basically a
set of feeds (XSPF, RSS) capable of publishing the media assets into
external players

/art = visual display elements, stylesheets for album rendering that are
not part of media assets
/bin = players capable of displaying media assets = album renderer,
musicplayer, ION media library, etc.
/legal = parseable licenses; may be multiple as different assets could
have different usage rights (play vs. remix)
/media = the media assets of the album; no required structure as the
album.* playlists will reference this

usage model: double-clicking on the BUM file causes it to execute,
launching a micro-http server on port 8888, and opens your web browser
to point to http://localhost:8888 ; this displays the album TOC rendered
by whatever /bin tools have been included in the album. The album would
be playable directly from within the BUM format by on-the-fly streaming
from the ZIPd resources. The media assets could be exported by launching
one of the included playlists - XSPF, RSS, etc - into a compatible
desktop player.
*********

That's all for now. Again think of this as more some thoughts on
requirements than a careful study of what a container should look like.
What I am really stuck on is the idea of the album as a self-contained
world w/o any need for external players, though still having the
flexibility to be rendered how it chooses.

The use of a self-contained executable album would also be useful for
mobile J2ME devices, which also support executable JARs (aka "MIDlets").
If albums wanted to be delivered to mobile devices and take advantage of
all the services the carriers have deployed for mobile application
delivery, this could be a great approach.

Best,
Nathan

--
cruXy: buy/sell/promote
independent original creativity
http://cruxy.com