I have installed and examined as many of the media related module efforts (audio, mp3 flexinode, media etc) as I can find and reviewed most of the wish lists and commentary posted here (e.g. http://drupal.org/node/28667) - I am worried the piecemeal approaches are not converging on a unified and generally useful waying of handling media in Drupal. Here is an attempt at a unified vision:
Features:
Metadata support: We need to be able to read and write metadata. Only the audio module allows writing as I recall. Metadata needs careful caching so we can efficiently support changes to uploaded media files and media files supported externally. Although the libraries that handle it are different we should embrace the idea that all media types (and that includes images) have metadata and provide a unified api. We should try to standardize the names of the obvious common elements, e.g. width/height.
Bulk upload: People already have their media collections organized in a variety of different formats and we should provide import/export facilities because it is too hard to handle thousands of media assets one by one.
Flexible Media Player SupportThere are many ways to present access to media from general purpose flash players to special purpose players built into operating systems or browsers. It should be easy to configure the page rendering to be sensitive to what the browser reports is available. There should be a fallback to simple file download or streaming. Support for this idea seems patchy so far. There are some handy html fragments in the video module and is it the media module that relegates this to a theme?
Play Lists and GalleriesMy main observation: why should a gallery book or playlist need different implementations? They are all ways of handling an ordered list of assets. Just because we are in the habit of using different words for the assets doesn't justify separate mechanisms. chapter==image==clip==sound. I would like to see why the book outline feature can't be generalized to handle this. The outline feature is already in the right place from the GUI standpoint. There are some presentation differences perhaps for the mediatypes but these can be handled within the themes/css world.
ThumbnailingAll the media types need thumbnailing. It is tempting to consider the thumbnail itself as a node. This would efficiently allow for still images to serve as video thumbnails. There are projects that use text as thumbnails for audio and images. Note that conceptually there is no difference between a teaser and a thumbnail.
External media hosting support: It is likeley that many users will want to handle media by reference to external hosts, e.g., http://www.ourmedia.org.
RSS support: Good RSS support will follow naturally from the previous features as the necessary data will have been carefully stored and cached.
Making it Happen:
In some ways I am hoping my comments here are irrelevant because some happy crew of 4.7 developers is fixing the core to do all this. I would think this stuff would be near top on the list of things to take care of at sites like ourmedia.org, archive.org,drupalart.org. If the problem is simply coordination and lack of skilled drupal developers my group with appropriate sponsorship may be able to help.
Adrian Freed
Research Director
CNMAT, center for new music and audio technologies
UC Berkeley
Comments
flexinode
Now that the layout of flexinodes is even more flexible with fleximax I can see that this might be a good basis to build media nodes from. Fleximax should use symbolic field names instead of id's though.
a general Media Management Module is sensible
Adrian, I think your idea of Media Management Module as you well presented is sensible and viable -and a must- to handle all media files -out of box -as good CMS should do
As Fleximax/Flexinode requires some buliding/structuring before it may function as a 'Media Manager'
Absolutely
And we are starting to do media right, the audio module being one of the first examples.
Some of the items you mention need to be generalized and available to all types of media. Others are better implemented on a per-media-type basis -- playlists AREN'T galleries, especially from a metadata point of view (yes, there is a playlist module in the works as well). That being said, there is at least one external image gallery module in progress, that seamlessly relies on the image module for it's core support.
So, I would say people support your vision...just need more people developing core code to move forward.
Adrian, would love to discuss with you further how we can connect with your group in testing (and developing?) great core media functionality for Drupal.
Regarding the flexinode comments, the way that flexinode is implemented is not particularly scalable. The CCK approach will mean that core media modules such as image, audio, video, etc. will actually define fields that can be re-used across content types, so that is definitely the direction things are heading.
Thanks for the CCK pointer
Could you please expand on your assertion that playlists and galleries differ from a metadata point of view? I notice Apple, for example, building devices (iPod) and podcast RSS spec that suggest a convergence.
Media functionality in Drupal is central to our use of it so we will be both testing and developing. I would like to minimize reinvention and having to remap our extensive content from one module/db scheme to another.
Matter of specialization
While some of the data structures might be similar (i.e. collection of images, collection of audio files), lots of the information around them is quite different. Or different enough in the information and most especially the display that it makes sense to have a separate module.
The data structure concepts are something we're working on, see Creating a generalized relationship module. So, following that link and applying it to albums/playlists, an album node is related to N audio nodes.
As opposed to an image gallery, it need support for XPSF, m3u, and possibly other playlist formats. Audio also needs support for iTunes RSS, which doesn't know what to do with the images.
So, base functionality like sticking stuff in the enclosure element of a feed is already common. Microsoft plans to do a lot of things using this method directly with IE7 -- e.g. imagine a slideshow based off of a remote RSS feed where the images are in the enclosure field.
File handling is probably the first best place to rationalize. E.g., we also just posted about Extending the file API to handle remote files. From file uploading will come the next step of hooks to extract metadata as they are uploaded.
Whewh. That's probably enough for now for a bunch of stuff that is only in progress and not built yet (except for the playlist module, which should be another week or so before it's first release).
Stream player radio + podcasting from local or remote server
Is it possible to use audio.module as a stream player?
or can it be configued somehow?
I am looking a way to implement a block with a mini player - Flash player, Real plugin or QuickTime plugin
ie.. a drop down selection of
BBC Radio1
BBC Radio2
BBC Radio3
CRWC
COOLradio
[add stream] (for admin)
[add stream] (allowed user groups)
choosen BBC Radio1 grabs the stream and plays of...
BBC Radio1
rtsp://rmlivev8.bbc.net.uk/farm/*/ev7/live24/radio2/live/r2_dsat_g2.ra
- one of the places to get radio streams
http://www.streamaudio.com/radiostations/list.asp?type=format&criteria=A...
This method also can be useful if someone who does not want to upload pdcast but stream from their local computer with broadband
ie. my podcast on http://1.0.0.0.(my ip):80
or any other remote server
basically all rounder radiostreamer function
This is not currently
This is not currently implemented, but I would really like to add support for remote files (and streams). The question is how to best go about this. I've heard talk about making changes to the file api to support remote resources, as opposed to adding this to the audio module directly. In the above comment, you are talking about adding a URL that points to an audio file (or stream), but it could just as easily be an image on flickr or a video on ourmedia.org.
My current thought is that it makes sense to add this to the file API, and then to work this new code into the audio module (and others).
This will be a killer feature though!
I concur
We need this feature
Podcasting News...
http://drupalart.org/node/146
I dont know if anyone has seen this or anything but this is looking prosperous for drupal in the media department... He made a podcasting module and it seems to work pretty damn good!
-------------------------------------
Paul Malenke
paul.malenke@gmail.com
AfterDeathGraphics.com
This is interesting
This podcasting module looks interesting, but I wanted to mention that the audio module also currently supports podcasting. One added benefit of the audio module is that each audio file is treated as an individual node. This means that you can have a podcast based on a taxonomy, for example. As well, other modules can utilise these audio nodes. An example of this is a playlist/audio-album module that is just about complete. It lets a user select and order audio nodes and in addition to pumping out M3U, pls, and XSPF, the playlist's feed is 'podcastable'.
Looking forward to more drupal media progress being made!...
podcasting properly
I haven't found any complete support for the full iTunesRSS spec. which allows for episodes - yet another kind of playlist which has an event time associated with it: http://phobos.apple.com/static/iTunesRSS.html.
I also notice the itune podcasts can refer to PDF's which makes me think we should be able to syndicate the PDF version of a page. Am I right in concluding that this is another thing that awaits 4.7: http://drupal.org/node/23545?
While I am on the RSS aspects I should mention Media RSS. I think that a good media data representation within drupal should take into account representing the metadata and tags from that spec.: http://search.yahoo.com/mrss
More features
I don't see anything about episodes in the spec. Colin intends to have full support for iTunesRSS out of the box.
AFAIK, PDFs etc. are included directly into the MPEG4 AAC file using Apple's "Chapter Tool" (I believe there are some third-party apps that do this as well). *Theoretically*, Drupal could combine this with MPEG4 files on the fly, since it just generates some XML.
MediaRSS is more general than just audio. That would be best implemented at a "higher" level...probably starting off as a module. http://ourmedia.org implemented this, but haven't shared the code yet.
collaborative,community creativity tools-beyond the Mediamodules
This post not 'strictly' in topic but I am just posting 2 software combined with websites which I like share them with you - as some breakthrough ideas may inspire you too and give bigger picture to come back and contribute Drupal with fresh ideas.
They built around completely different ideas. One thing in common is they based on 'community building' which is aslo Drupal's motto translated as 'community plumbing'
I was going to post as fresh topic the reason I though it would be useful to follow this topic is other common medium they work on is Media and each serves different purpose in different way
1- http://www.last.fm/radio/
"Last.fm is the flagship product from the team that designed the Audioscrobbler system, a music engine based on a massive collection of Music Profiles."
which I can setup/connect my iTunes and stream the info to my account... which oover the time I built a my 'music' profile and find ot what other people listens on mt account on the site and other find people can mathes my music and listen what other 'profiles music of similar taste verso versa.
-join it and have a test drive
2- http://www.celtx.com/overview.html
This one more about collaborative script writing combined the usage of media covering all stage of film pre-pduction toolset (stuff you start when u go to film making)
It breaks the convention of script writing is a isolted creative eting process of writer and the typewriter. Now its a collaborative process
Its software is creative canvas other writers can splash into
Its well intgrated local software and database and the website
many features can take long time to describe - I also liked the idea of representation of Props as images and sound to use as canvas for script writing and own Firefox browser withing to seach stuff to find text info/image to integtrate
in their own words
"Features include:
Write, import, edit and publish scripts using standard industry formatting
Manage pre-production tasks like location and talent scouting
Perform production breakdowns by adding media (sound files, video clips and digital pictures)
Collaborate with team members over the Internet"
-Download join and experience
while we like Drupal its nice to see ahead and get some ideas which does not to imitate but help our visions somehow
~ regards
I know it is not complete, but it is a start
It doesn't have all the features that you described, but it does have some. And I think it could grow into the sort of module you are thinking of. Check out Acidfree. It was originally envisioned as a generic media management system, although I only took the pains to implement photo and video. I already have another user with a patch for adding audio.
I really do want to do it The Right Way™ — simple to use, yet having enough features to do what it should. I have tried to make it Mother-in-Law proof. Besides myself, she is the only non-geek I know that uses Acidfree. And she can use it great. So I don't want to make it complex with every feature ever imagined (like Gallery, which is awesome, but much too much for me).
I would love help and support from the community to help make Acidfree into a generic media management system.
--Vernon
Thanks for acidfree
I am evaluating it now. I am still dismayed at the number of different parallel efforts for media support.
No parallel efforts
There actually aren't parallel efforts. The image module is well developed, the audio module is turning into a solid base, and there is node-based support for video as well (although it needs some work ATM, I believe).
There is definitely room for improvement, and work is needed at the file API layer, but these are the kinds of tough/unsexy problems that someone needs to take a lead on and/or make suggestions.
Please do join the developers mailing list and/or continue to post suggestions and feedback to this working group. Are there any particular feature requests or issues that you have with current modules? The my issues link is the starting point for any projects you have submitted to.
--
Please turn on the "story" type, so we can use it to have an archive of best practices, how tos, and configuration recipes.
Duplication
I was referring to the three ways to do video: Video, Media, AcidFree and the three ways to do audio: Audio, mp3 in flexinode, attached files.
And the three ways to do images: AcidFree, image api, Gallery.
And there is the ourmedia.org work that has not been contributed back.
I still maintain they could all be cleanly built on a single media API that handles collections, metadata and syndication in a unified way. I am hesistant to start on yet-a-another way to do media in drupal though.
Has anyone looked at the Media features of Mambo for inspiration?
Audio and Video would be the
Audio and Video would be the "base" ways of doing things. Robert Douglass, who is the original author of the Media.module, should probably indicate that it is deprecated. We talked here in Amsterdam that extending the file API to handle hooks for different file types would be a way to route files to different modules.
Ourmedia, which I have some knowledge, likely does not have anything useful in the way of code.
Metadata should most likely be implemented as a horizontal module -- like event or location, which can be enabled and configured per node type. That's a pretty brief outline, ask questions if you're not clear on what I mean by this.
It would be great, as I said, to see a longer proposal of how you think it should be done, and then we can discuss.
--
Please turn on the "story" type, so we can use it to have an archive of best practices, how tos, and configuration recipes.
Not the right way
Vernon, if you're serious...you'll make Acidfree a gallery module that works with the base node types of image, audio, and video. We cannot work without having base types for people to extend in multiple ways.
Your approach is fine for what you want to accomplish, but not appropriate as a building block for other efforts: these *must* be node based in order to pull on the full power of Drupal, expose APIs for other modules to use, etc.
--
Please turn on the "story" type, so we can use it to have an archive of best practices, how tos, and configuration recipes.
The right way
I agree that the right way would be to have separate base modules for each type and then a container module that would help out with better organization. However, this requires consistency. It requires a standard API that all the different media types (image, audio, video, etc.) would implement so the single container module could interact with them in an intelligent way.
But it really seems that everyone wants to do their own thing in the contributions section. I think that is the real problem. The more the debate goes on about how people need to collaborate and how to fix it, it seems that the right thing to do is get rid of the contribution section all together. Then take top contenders and top developers and make the appropriate modules and put them in the core. This is really the only way you won't have 3 of every module.
And then again, there might not be a right way. After all, Drupal is not the only CMS because other people like Mambo better. Some people like the features of Acidfree, some people like Image+Album. I think personal preference and the targeted website usage model makes a huge difference in what is the right way. After all, the right way is the way the users want it, right? Well, you can't suit them all, so maybe if you just have 3 flavors of each idea, they can pick and choose.
I guess the whole point of this is that there is no absolute right and wrong way. If there was, it would have been implemented years ago and we would all be out of a job.
re: betterupload aka modular media system
http://www.webschuur.com/node/246 are the docs that go with the alpha/inprogress code at http://drupal.org/node/31736
And feel free to commit code or docs. Ive got only limited time and resources.
---
if you dont like the choices being made for you, you should start making your own.
---
[Bèr Kessels | Drupal services www.webschuur.com]
Still under development?
Hi Ber,
Your approach seems the must promising I've found so far. It seems the it is not very far up on your priority-list. The last CVS version is almost half a year old now.
Is that still on your agenda. It is one of the Key-Features MISSING from drupal now.
globo
image and media in another OS CMS
http://ez.no/doc/ez_publish/technical_manual/3_6/reference/datatypes
http://ez.no/doc/ez_publish/technical_manual/3_6/reference/datatypes/image
http://ez.no/doc/ez_publish/technical_manual/3_6/reference/datatypes/media
archive.org
I agree that archive.org-hosted podcast mp3s are a must.
Module for podcasting?
Drupal all ready have proper audio and video modules but they lack "serous rss control".
To properly create feed from content maybe best would be to make additional "advanced feed module" that could add into drupal feeds the "media:thumbnail" and itunes additional meta data (and others, defined by administrator).
That module could open possibilities to make in future full blown "distros" of drupal for podcasting and videocasting.
___
Obin.org - Independent media workshop
Module for podcasting?
Drupal all ready have proper audio and video modules but they lack "serous rss control".
To properly create feed from content maybe best would be to make additional "advanced feed module" that could add into drupal feeds the "media:thumbnail" and itunes additional meta data (and others, defined by administrator).
That module could open possibilities to make in future full blown "distros" of drupal for podcasting and videocasting.
___
Obin.org - Independent media workshop