Allow external/remote audio files like video.module

that sounds cool but it's a pretty huge change from the way the modules currently works.

http://drupal.org/node/48094#comment-71519

the same goes for external files. I have planned two ways of dealing with remote files: let your webserver get them from the remote host and store them locally. And store only the url, and leave the file on the remote host.

Bèr

See also: http://drupal.org/node/58915

Hi,

The new version of the playlist module will basically abstract out playlist functionality into an API. This means that hopefully, it will be easy to define new playlist modules relatively easily and dictate what node types can be added and new feeds to make out of the playlists. So if you were to create a second node type called audio_external, then you could make a new playlist node type made up of audio_external and audio nodes, but that together show up in one playlist/feed.

More info: http://drupal.org/node/58493

Yeah, this is something I need ASAP and will be coding myself if it's not there.

I'm making a podcast aggregator, tied in with aggregator2, and might just have to write a custom node type that uses some of audio.module's functionality.

I'd like to maybe patch audio.module to work with external files. How hard would this be?

Hi RobRoy...

It has been suggested to create a simple audio_external.module that would basically be a simple node module that contained a web url to the file. Additional fields could be there for Song title, desc, artist, etc.. just like the audio module. Also, the flash player could be utilized to play the remote file (last i checked). So basically it would be mimicking the way the audio node object is built but not actually utilizing ID3 tags or any stored metadata.

Then other modules could use this new node object as if it was an audio node. audio_external->['player'], etc...

It might actually be simpler than trying to patch the audio node.

Farsheed

RobRoy, i think the consensus is that the best way to add remote support is with a new audio_remote node type. zirafa's got some new playlist code in his sandbox that will allow playlists of both local and remote audio.

looks like i cross-posted with zirafa. i think he's laid out the best course. i just wanted to add, that i'd be open to including it as a sub-module in the audio module "package".

see also: http://drupal.org/node/65695

better subject?

see also: http://drupal.org/node/34878

It seems that a better strategy would be to remove the hardcoded id3 functionality and keep the audio.module pretty lean. I'd rather there be an option to enter a URL for a remote file in addition to the upload field. If a URL is entered, it would be used as the file source instead of the locally uploaded file.

See http://drupal.org/node/70576

http://drupal.org/node/76833 has been marked as a dupe of this.

In addition to the already mentioned feature set, I would like to see a way to store own audio files on a separate server. Use case: The webserver providing the Drupal site at http://www.examplesite.com wouldn't be battered from downloads at http://mediastore.examplesite.com. The difference of this addition is that audio files are provided through the Drupal site and do not have to be stored at the media server first.

For this I think we would need a FTP transfer option for audio module, so that new audio files can be stored on the remote server.

I totally agree that this has to be a separate audio_remote.module.

I'm thinking efforts would be best focused on getting a better FileAPI and a CCK filefield field type that can handle remote files of different media types. I think dopry is working on both, maybe in his sandbox. A more generic way of handling files would be the way to go IMHO. Would someone more in-tune with this care to comment?

i haven't had a chance to look at dopry's filesystem module but i've heard very positive things about it. i agree that cck field and general filesystem improvements are the way to go. in my dream world the audio module would just plug into a generic file hook and do everything there.

Just checking in on this...anybody takin a lead? What would be required to do this considering the new changes to the audio module?

Not that I really know what I'm talking about, but could these sites/services help provide some sort of solution:
http://www.songbirdnest.com/features
http://www.songbirdnest.com/development
http://xspf.org/applications/
http://tech.groups.yahoo.com/group/webjay-dev/
http://www.streampad.com/

This'll be a great feature to have in Drupal!

Gus

i've been making some changes to open it up but it's not a high priority item for me right now. i think the first step is getting the module to work right without getid3. part of that would be the moving some of the more "optional" metadata out to the file table.

just posting to track this post. I also think this is essential for this module and would make it really useful.

was there any progress on this? I am stuck and waiting for this functionality.

thanks

i'd love to work on it but i've got classes to finish. if you can rally $500 i'd power though and get that done.

Happy New Year everyone. Any news?
I'm also interested in this functionality and contemplating developing it myself, unless someone is already planning a release in the next month or so.

I would if this gets finally implemented.

Drewish maybe starting a ChipIn for this would allow people to start contributing to get this done.

http://www.chipin.com/

Okay I've setup a chip-in page: http://drewish.chipin.com/external-audio-file-support

Nice! ChipIn rocks!

Nice. I put some $ towards this already. I'll see if I can get more people or contribute to this more myself.

i'm interested in this - although have no access to funding.

how would the chip in process work - would do the coding?

I'll be doing the coding. I've said several times it's a feature I want to work on, but don't need it for personal use so the money is to justify my time.

remote mp3's would rock! this needs to happen to keep this module relevant (IMHO)

ekendra, if you want to see the feature implemented please contribute to the chipin fund: http://drewish.chipin.com/external-audio-file-support

marked http://drupal.org/node/121881 as a duplicate

Lots of people seem to want this feature. Please donate a few $$ to the ChipIn fund so we can make this happen!

Hello,

i just wanted to mention that ourmedia.com (which is actually based on drupal) uses archive.org to store their files to. but instead of simply filling in a remote url (which would already be a nice feature for the audio module anyway) the files are uploaded directly to archive.org.

i found on the ourmedia wiki an article that roughly describes the way this remote upload process works:
http://tools.ourmedia.org/index.php?title=Upload_process

wouldn´t it even better to make it possible that one can upload audio files directly from drupal to a remote host than having to upload the content on a different site first and then cp the url into drupal??

subscribing...

Hi, the Chip In link has expired. Any way to renew it?

(re)subscribing

Is there any traction here? I'd be willing to help out both financially and on the coding end if we can get some of the folks more familiar with the audio module to get the audio_remote going. I have people asking me about this kind of functionality ALL the time. I know a lot of folks that host their own content but want to pipe it through podtrac or other online advertisers. The Audio module completely fails at allowing that kind of functionality.

I have been spending a better part of the afternoon sifting through the audio.module code. I am having a hard time understanding the need for an audio_remote module when this functionality can be bundled into the audio.module.

As far as I can see there needs to be a new form field for URL. if that field is submitted, it triggers the getID3 code to copy a remote file locally and get the ID# tag info before deleting it. next the url is added to the db and then when $node->url_play is called it checks for the filepath if null check for url field and use that instead to build the song_url param for flash. Am I missing something big here?

That's the basic idea, but I think there is a bit more, the theming functions to display the audio file need to be separated out. Nothing too difficult. But the consensus is that this should be built into the audio module directly at this point (hence the effort to fund drewish to do it). Feel free to submit a patch though.

this is so long overdue. glad to see some activity.

jayphoni and ekendra, i've re-opened the chip-in. i'd love your support: http://drewish.chipin.com/external-audio-file-support-reposted

44 posts and the thread is a year old. Something like 11 unique people want this feature, but only one person has actually chipped in (myself). It seems like the answer is pretty simple...$400/11 = around $37 bucks per person. Pretty good deal I'd say.

If you are tired of waiting or really need this, put your money (or code) where your mouth is! Believe me, this thread will just keep sitting here otherwise.

Only one more month left before the ChipIn ends for this...if you have an extra few $ to donate now would be a good time :)

Zack Rosen also chipped in. I'll be a busy month leading up to the D6 code freeze so I won't be doing much on it until after that.

subscribing...

Currently working to get the remainder of what is needed for the ChipIn. Question, though: What is the turn around time once the funds are met?

Will this support secure third parties? I'm thinking that this might be a good thing for storing files securely and remotely, a la Amazon S3 or seperate file/ftp server? Especially for high volume sites that might want to use ecommerce on top - this would then totally rock.

This might be OT.

i use delicious playtagger[1] to play mp3 storing in archive.org at http://niuniu.rijiben.org . It's a site telling/reading stories for children. All content are created by us and released under cc-by-sa.
[1] http://del.icio.us/help/playtagger

But, of course it won't get the id3 tag msg so no meta data of the mp3 will be displayed, therefore, you don't have those fancy functions that come with audio module, click a id3 tag to show all shows related, track download times, etc.

Basically, with playtagger you don't even need to use audio module.

The audio module is the module that strongly influenced to me use drupal but I disabled it in most of the sites I maintain because 1) I trust http://archive.org 's ability to host my audio files permanently more than my own server (this is important, i might not have enough money someday or the sites get shut down by authorities), etc 2) the bandwidth issue

I think to allow external audio files is very important.

There's a project called station[2] which based on audio and other modules. I, and some other people as I know, want to do grassroots/independent net radio station based on that. But we can't afford storing the files locally. I don't think small independent station can do that either. Archive.org is providing such great service for individual and grassroots orgnization, so we really want to use it.
[2] http://drupal.org/project/station

Allow external/remote audio file can facilitate more people to bring their voices out. There probably might be a larger issue here.

I haven't chipped in any money so for the moment I will keep my mouth shut.

Thanks for the great works done by audio module developers!

NikLP: Yes, I think as long as a user has remote access to the file via HTTP it will work. The file will be served through the flash player (or direct link) but the link will be to the third party site instead of the site's server.

404, i'm familiar with the station module, i wrote it ;) the service provided by the internet archive site is very cool and the inability to use it's has been the feature that people have been clamoring for. as i've said i think it's a great feature but it's not an itch i need to personally scratch but if people will scrape some money together i'm very happy to implement it.

Woohoo! We made it. 101% of the goal, looks like somebody even pitched in a $5 tip.

excellent! i wan't expecting that to happen that soon. i'm going to be out of town on vacation for the next week so i won't be able to start on this until then. i've very excited by this.

thank you very much to everyone who contributed!

Subscribing; this sounds awesome

splendid! -> subscribing

I want, I want!

I need this for a podcast on http://gmking.org, which is really draining bandwidth, with this I could host it on archive.org! Donating to the chipin fund and subscribing!

Robin

Whoops, chipin ended. I'll just give my +1 :)

Robin

subscribing

A few obligatory questions:

1. Is there a better place to keep up with the news on this? (IRC, CVS, groups.drupal.org .. devel mailing lists .. etc?)
2. Do you need help? (I'm building an app that will use exactly this functionality ... the faster this gets developed the better, for me ... we're willing to help :-).
3. For whom do we buy beer?

James.

James Andres:

Changing the title changes the thread's title, so watch out.

This is the best place to keep track of progress on this. The ChipIn fund was reached.

The beer buying goes towards drewish for this one. ;)

Oops, sorry.

Cheers,

James.

Yeah - very exciting to see some progress - will chip in a beer for drewish also.

Quick question - does this type of functionality have some commonality with the embedded media field module? http://drupal.org/project/emfield

Guess they're a bit different.... and awesome!

Subscribing!

hey sorry for the lack of updates. i've been trying to catch up on my summer of code project. i should have a good chunk worked out by next week and some time to start battling the audio module issue queue. i appreciate everyone's patience.

Ping :P

People are asking: http://groups.drupal.org/node/4534#comment-14875

bumping this back up. i've spent the day clearing out the audio module issue queue to get back in the swing of it. i got a lot of bugs fixed and now i'm ready to get going on this.

i'd done some work to refactor the database, moving the data from {audio_files} into {files}, as part of patch but after a little experimentation on audio_images realized that that half may have to wait until we migrate to Drupal 6. i'm going to scale back and try to do this as simply as possible.

subscribing

Please be sure to consider people on cheap hosting that can't change their PHP max upload to above the default 2MB and so wish to host their audio files of larger size on something like Cachefly. I've seen mention of coding the module such that it downloads the file locally in the process and this might be an issue, there. Looking forward to this functionality.

subscribing

subscribage

marked http://drupal.org/node/175190 as a duplicate

Hey drewish - any update on the remote file issue? is there any implementation/patch of that feature yet?

@drewish - any status update on this?

yes, any update?

subscribing....

Would love this feature...

any news?

subscribe

subscribe

subscribe

There seems to be no movement on this feature. It seems to me that it would make an ideal candidate for a GHOP task (http://drupal.org/node/205806). I'd be happy to submit the proposal. Let me know if there are any objections. I'll do it this weekend.

The bounty on this feature was filled a while back for drewish to complete the task. GHOPing the task might create some movement on it but perhaps we should get some updates on where drewish is with it first.

FYI, I spoke with drewish about this feature recently. I was very busy with classes this past term and didn't have the time to finish this task. Currently we are juggling this task as well as the update to D6.

It might be a little bit longer to get this feature out but he has already started writing it.

Since not much has been done and quite a few people have perceived this as urgent, would it be possible to submit this as a GHOP task anyway and use the bounty money for some other improvements to the module or adding extra features to the basic functionality. At the moment, I'd be quite happy with a basic patch that would allow me to put in a URL that would show up as an RSS attachment and display a basic player. Nothing else. There are lots of features that could be added on top (AJAX), integration with media mover and other media modules, etc. that the bounty could go towards. I really do not want to step on any toes but this is rather important for a site I'm working on with no development budget and I understand a lot of people are in the same position. Basically, any solution where podcasts with off site hosting could be implemented easily would be sufficient. There seem to be a lot of open GHOP task slots that need to be filled so it would be a pity to waste them. But I will not go ahead if the consensus is against that option. One other option would be to ask for that feature for the CCK media field module.

subscribe

any news? would even consider to contribute some $$$ and/or testinng...

$$$ were already contributed via chipin.

With the GHOPpers continuing on after Google, I think this would be a great project for them to take on.
http://groups.drupal.org/node/8383

This is ridiculous! This feature has been available in wordpress for years. The audio module is almost useless for people that have popular shows and use content delivery networks to host their files. This feature has been requested almost two years ago and there has still been no features added even with money being contributed.

For real, get this added to the module!!!

subscribe

subscribed

i agree. i'm actually moving from Drupal to WordPress for my podcast site *specifically* because of this lack of feature. Also, I was playing with this module's code to see just how difficult it is to implement the feature. I really didn't spend that much time in the code, so I don't have a say in the issue -- but I was able to successfully hard-code remote CDN media URLs in a matter of minutes... is the issue that it's much more difficult to provide a setting that does the trick, rather than hard-coding it? Honestly, I'm not skill-bashing, and I'm sure I'll be put in my place in a second... but I've been trying to get time to fix it myself, because it doesn't seem that hard :s

Hasn't there been money commited to develop this feature six months ago? Any update on the status? drewish?
:-)

i hacked it to work temporarily for me. my line 440ish of audio.module ( in audio_load() )looks like

$path=db_result(db_query("SELECT remote_url FROM {audio_file} WHERE vid=%d",$node->vid));
	if($path){
		$ret[url_play]=$path;
		$ret[url_download]=$path;
	}
	  
    // Allow other modules to access newly loaded audio node.	
    $ret = array_merge($ret, audio_invoke_audioapi('load', $node));

and i created a new column in {audio_file} called remote_url where I store the CDN url's. I'm currently putting URLs in there via phpmyadmin. it's jank, if I ever get around to it I'll write a patch.

Because of all the add on modules (like to edit ID3 tags) that are affected this is no small change to do well.

Is it time the audio module became CCK or CCK like in nature? Then we could ease some of this impact and have more than one audio node type. Just brainstorming.

yeah, with my hack i still have to upload to the local server because the id3 addon can't access remote URLs. so yeah, i think CCKification is in order. Also, another issue i'm having with audio.module over wordpress's is audio.module's poor itunes rss that's generated (comparatively). If audio.module is separated from its itunes rss view, it will streamline the development of the view for audio nodes.

EDIT: Actually, podPress (wordpress's plugin) uses that same id3 library to get id3 stats on remotely-located media. when I get time I'm going to compare podPress to audio.module and see if a patch can't bring audio.module up to speed.

I would second a CCK audiofield module that simply stored remote or local files and used 1pixelout as the default player. The audio_attach module sort of behaves this way, just not through CCK. We've got to start the migration away from the audio-as-a-node concept to audio-as-a-cck-field, so we can eventually get to audio-as-a-file-type (proper media/file handling...).

It does feel like we've coded ourselves into a corner here and need to make some transitions.

I'm going to take a look at http://drupal.org/project/asset. That might be a good place to work on audio as a file(url) type.

@lefnire - it looks like podpress can only read ID3 tags and not write to them.

Im very interesting about allowing external/remote audio files and im already start to testing some codes.

The faster method to add an audio from remote path is to upload a test mp3 via drupal and the adding the file via phpMyAdmn
[ audio_file >> filepath ] changing the "files/audio/any.mp3" to "http://test.com/test.mp3".

but the player doesnt looks like ready to play the song!The error is:

"The following errors where encountered while reading the file's ID3 tags: Remote files are not supported in this version of getID3() - please copy the file locally first"

So i supposed the first changing of code will be in ID3 :P

You can't just change the filepath and expect the module to work. There are fundamental differences between what you can do with a local file and a remote file. For instance, getid3 can't directly access a remote file meaning it's can't pull the info needed from the file to know whether or not to display the flash player.

There are some fundamental changes that need to happen to this module for it to support offsite files. One change is that it would have to download the remote file and cache it to get into out of the file with getid3.

i understood that module can not work in that way!

My question is "should we change code in getid3(?) or just use an other script,like getid3?"

If I figured out the change code in getid3,the audio module could support remote files,only changing filepath?

One idea is to not support getid3 for remote files for the time being.

@zirafa - The problem with this is that the flash player needs info about the file that getid3 tells us. So, if we don't use that then the flash player won't display by default.

mfer:

The only player I know that reads the id3 tags from the file itself is 1pixelout. If it can't read the id3 tags or the file doesn't have one, it just doesn't display any id3 information - but the player will still work.

With the other players used (musicplayer.sourceforge.net), we pass the flash player the title, artist, and other variables in query strings, or it reads the metadata from an XSPF file (in both cases the player doesn't actively try and read the file). The flash player will still work, even if the id3 info is missing. The nice thing about this is you can arbitrarily pass the flash player title/artist information and it doesn't have to necessarily come from id3 tags.

So while it's ideal that we have the ability to read/write id3 tags so that the players can show information, it's not *required* for the flash players to at least show up and work. It's somewhat annoying, but the real value of the flash player is quick and instant listening of the audio file, not the id3 information.

hope that makes sense. just feels like we are breaking our backs to try and make the id3 stuff work, but in the bigger picture a simple flash player that plays remote files is what we are after. let's simplify the problem instead of working on a complex solution.

I totally agree! we just need something that can attach external files and have the simple flash player play them on the site. I don't care that much about all the metadata stuff... anything is better than nothing!

If you're not interested in iTunes integration and ID3 stuff than check out the asset or filefield modules. You can have the 1pixelout flash player with either one of those.

any news on this one yet? remote mp3 feature would be perfect :)

mfer:

I think you misunderstood me. I *could* just go use another module like filefield/asset, but they are too generic. I'd like to improve and make this module more compatible with any future file system. For now, it seems fair to support ID3/metadata with local files and not support it for remote files, otherwise we'll get nowhere.

But we aren't going anywhere. This issue is over 2 years old and is stalling even with an injection of money (reverse bounty). I'm pretty burnt out talking about it, unfortunately.

hello,did anybody check the http://www.playlist.com ??

I pretty sure that use drupal!

I am trying to understand the way that playlist.com works with remote audio files...

Looks similar to the way webjay.com used to work. Songs are stored only as indexed hyperlinks + title of song, and then it generates xspf feed for the flash player.

I think drupal only need these variables

* TITLE
* ARTIST
* ALBUM
* TRACKNUMBER
* COMMENT
* GENRE
* YEAR
* ATTACHED_PICTURE

and analyze($filepath) function from getid3 to work.Right?

i have start write a script reading ID3 (ID3v1, ID3v2) from mp3 in remote servers,like http://code.google.com/p/php-reader/

Is there any list of variables and functions needed from audio.module to work without getid3 script?

Another possibility would be to get a portion of a remote file - enough to read the header info. Here's some code that I found on www.getId3.org that may work which reads the first 32kb of the file. I haven't tried it yet:

$remotefilename = 'mylink,example'; 
$fp = fopen($remotefilename,'rb'); 
if ($fp2 = fopen('boo', 'wb')) { 
   $first32kb = fread($fp, 32*1024); 
   fwrite($fp2,$first32kb); 
} 
fclose($fp); 

$ThisFileInfo = $getID3->analyze('boo'); 

I was thinking of combining this with lefnire's 'hack' that he mentions in the post above (http://drupal.org/node/47998#comment-748302) which works great for playing the audio from a remote URL.

looking for the same feature

Maybe some of these hacks can be committed to a dev version?

Subscribing

Embedded media file (audio) allows this if you run HEAD (has a URL input).

subscribing, I use pubclip.com and want my users to be able to post their audio blogs and podcasts that are on the pubclip server - if anyone's figured out how to do this, please let me know.

subscribing

subscribing

subscribing

subscribing

Has there been any progress on this? I have a dire need for a site that has about 3500 audio files and I want to leave the media on the present server and move the site and db (minus the audio) to a faster server.
http://diydharma.org can't handle the strain on Dreamhost anymore (but I still want to use them to serve up the bandwidth).

If anyone has done this please let me know!

thanks

I would also like to see this feature implemented.

subscribing

+1 for using external audio files, this is the reason I am not using the audio module.

I built this exact functionality for a scratch built (non-Drupal PHP) netlabel site, www.tootingbizarre.org, because it is far cheaper to host high bitrate audio files on www.archive.org than on our little shared server.

You submit the urls of the files, they are briefly copied locally, the id3 tags are read and written to the DB, then the temp files unlinked and the url used to generate a XPLF button player and a table of audio links, e.g. http://www.tootingbizarre.org/Thumpermonkey%20Lives!/Bring%20Me%20Sun%20...

If CCK wasn't so mysterious to me, I would build this for myself alone. Pobster - wanna double-team this?

Yeah sounds like a plan. Few questions:

• Are you absolutely sure that no other module implements this functionality (or similar) already?
• Is the audio module the best module to choose for this end goal (I only ask as its currently listed as being UNSTABLE)

Pobster

Are you absolutely sure that no other module implements this functionality (or similar) already?

Not 100%, but the 120 comments above seem to suggest as much :-)

Is the audio module the best module to choose for this end goal (I only ask as its currently listed as being UNSTABLE)

I would be equally as happy with a seperate CCK field module. I like to add a new field on the manange fields screen, to select field type "linked audio" and be able to have one, two or an unlimited (add more) number of URL input boxes on the node submission form. On submit, the module goes and gets the ID3 tags, (possibly holds a backup of the file locally - configurable), and popluates a set of additional fields.

Problem with that is that every "linked audio" field now generate six columns in the content field instance table.

(Lets discuss this in person/pub...)

Pub sounds good, I wonder if the chipin fund is still unclaimed...? That's a lot of beer...

Pobster

Just FYI, there is some form of internet archive support (http://drupal.org/project/media_archive) for the embedded media field module (http://drupal.org/project/emfield). Although it's not directly related to the audio module, it may fit your needs.

If I understand it correctly, the Archive.org CCK plug in does not actually embed a flash player.

Ideally, you'd want this part of the audio module so that the audio file is part of the RSS enclosure and you could combine locally hosted with remotely hosted files in the same stream.

Very unlikely to happen. The future in D7 and beyond is file (field) along with PHP stream wrappers and other niceties. Media module makes use of these features already.

We perhaps need a new discussion on groups.drupal.org, to analyze and figure out what kind of functionality projects like Audio and Video should provide, if any, starting from D7.

Good idea.

posted http://groups.drupal.org/node/77908

subscribe

Although this has been marked won't fix, seems that this thread won't die. Hopefully nobody is still using Audio module 5.x, but here is a module that lets you open up cck file upload fields to allow remote file downloads (needs CuRL) which essentially is a solid solution for this bug going forward.

http://drupal.org/project/filefield_sources