bum51's dashboard

You need to tweak that section to your needs I believe.


if ($soundname == 'tone') {
// This path is OUTSIDE the webroot
$filepath = ""../../../../../mp3/".$soundname.".mp3";
} else {
$filepath = 0;
}

will actually only work if $soundname is "tone". otherwise it will get no sound file.
I'm assuming that you want to use many files with this script so if you take out the section and use it with just the

$filepath = ""../../../../../mp3/".$soundname.".mp3"

part then you should be able to do what you are trying to do.
To make it more secure you need to add the security in yourself, which will be dependent on the setup you're using.

The if statement there, I believe, was just an example of how to implement the security, but unless you want to manually code in every file, then you should probably use a database with IDs of the files and their locations. Then instead of $soundname, you could use $soundID and then get the name/location out of the database. At very least this way the user needs to have the ID if they want to steal it.
There are other precautions you can take to make sure that the user is logged in or other conditions, but I think starting with a database routine would be a good step for the moment. – bum51, on November 20, 2009 14:34

I agree with Scott, it looks quite good. However my idea was to port HTML5 to SoundManager instead of the other way around. It just makes it backward compatible with pre-existing applications. Not to mention the flash features being more readily available. I do think that any NEW application would definitely benefit better from your project, as it makes it a bit more future-proof. – bum51, on November 20, 2009 02:46

Basically what I've come up with as the easiest solution right now is a wrapper object that uses an <audio> object as the main engine, but includes SM2 as a sort of plugin engine for an cases that the <audio> doesn't work (instead of an extension of SM2), or is not supported with requested features (wave/eq data, or certain audio codecs). I would want to make it look and feel like SM2 as much as possible so that it can be relatively easily dropped in to any code that already uses SM2.

The advantage to this approach would be that each "engine" is separate from the wrapper code so if for instance the <audio> spec changes, the engine can be stripped out and restarted, without having to scrap any other part of the project. And to go one further, if someone ever wanted to make a silverlight plugin or something, that would be possible as well (not that I can imagine why anyone would though)...

For now I'm going to work on the <audio> engine, and then I'll get to the wrapper.

(btw, kinda off topic, but since we've got stereo wave forms, can we get the same for the eq? my visualizations look kinda funny when the waves are stereo and not the bars :D ) – bum51, on November 17, 2009 04:53

In that case I think I'm gonna take some time and look through the SM2 js code, and see if I can't come up with a temporary solution, possibly even one that ends up being a complete solution. I'll let you know if I make any headway! – bum51, on November 14, 2009 14:30

I know that you may be working on it for the next version, and I know that if that's the case then it's going to be a MAJOR upgrade and such (maybe time to call it SM3?)so it's gonna take a LONG time to complete, but any updates? I'm sure lots of us are eager to know if you have made any progress with it at all.
I've been working on a successor of the website I've been hosting and one of the requirements we're hoping to fulfill is mobile device support. If possible I do not wish to have a separate library to run audio on different devices or browsers (if we move to strict html5 then we obviously lose IE, not that we like it anyway). Anyway, if you're working on it, then good luck and I'm definitely excited! Always a fan,
-bum51

My expectation is that this is probably because you are trying to direct to an unavailable location. First, make sure that the location is available from a browser.

Say you're doing this locally, and you are at :
http://localhost/

then you are trying to access :
../../swf/soundmanager2.swf (or "../../swf/" when applying to SM)

then browsers will resolve to :
http://localhost/../../swf/soundmanag...

Which doesn't exist.

Try putting it in a sub folder or in the same folder and see if that helps.
Alternatively if it is in a subfolder the root of the domain, you can replace "../../" with "/". So you would have
/swf/soundmanager2.swf (or "/swf/" when applying to SM)

which will always resolve to the root domain, and you would end up with
http://localhost/swf/soundmanager2.swf

from whatever page/folder you're currently at instead.

Otherwise I expect that more details are needed (like a testcase).

I would think that another option would be to have the page player reference an instance of soundmanager on page load. Then when you load each frame it can check for the parent page and soundmanager. That way you only have to find the reference once per page load, and if no parent soundmanager exists, then load up the scripts on the local page and run it from there.
This method would have the added benefit that if you navigate away from the page in one of the iframes then the top level never has to know about it. The page can either look for a parent or won't, and no harm done.
In fact, this could probably be done with a little tweaking to the soundmanager init function so that you don't have to change all the references elsewhere. All you would need is to insert a little custom check for a parent page and parent soundmanager, if it then fails, it would automatically fall back on itself and create the flash object.

Client side apps don't generally have access to view folder contents. You CAN enable this in apache I believe, but it would be much much easier to make a server-side script to compile a list of available songs and send that to the client.
Don't have an example on me, but I know that the php filesystem objects certainly allow that kind of action. Just about any server-side scripts do.

Dagnamit! I just witnessed it happen again :(

See that's where it's still weird. I'm not trying to multishot anything, I mean I do play the sounds multiple times, but never at once. In fact, in the while events I have stuff in there so that if the sound playing isn't the "current" sound, then it will stop itself.
And it doesn't seem to matter whether it's the first time the sound is loaded or the 50th. It's just intermittent.
And just to note, when it happens, the values don't seem to change at all. (duration and position certainly don't update ever, didn't check on the bytes/bytestotal)

So I'd just like to present an update on this issue. I'm still not entire sure that it's fixed, but I haven't seen it happen in a while since I made a tiny change so I'm updating you now anyway.

Not sure why this would work, however I was previously using autoLoad=false and not defining the autoPlay attribute in the defaultOptions.
I have now defined autoPlay=false and it seems that the issues is gone.

The only thing I can come up with that would make any sense is that it was trying to play the sound somehow without loading it, and then the flash thought that the original instance of the sound was playing already, so when it finally loaded and played, it thought that it was a multishot sound, and so the while events would not fire.

I've looked through both my own code and the soundmanager JS and have not found anything that would in any way cause this. I don't have much experience with ActiveScripting but I checked that out and it all seemed good as well.

As I said, I have no idea why this works or would even make any difference as soundManager even defines autoPlay: false anyway.

I do still believe that it somehow ties into multishot, as every other event fires just fine and my code all uses the same events, so if it were breaking once then it would probably break every time.

Another thing I'd like to note is that if I played a sound, and it failed, then I unloaded and re-loaded then it would sometimes have fixed itself. Sometime if it were fine in the first place then it would break the second time and so on.

With any luck, it was actually a flash issue that has been resolved by an update of some sort, because I'm really running out of explanations here :D

I would like to note however that using the prefixes results in the same, but the first issue won't exist, so it's probably better if you do it that way if you use the prefix method as it's a bit safer regardless. – bum51, on July 06, 2009 17:24

I previously had a similar issue with soundmanager and found that if you turn your id into a string like so:

for (var i = 0; i < array.length; i++)
soundManager.createSound({id: i+"", ...});

then it creates the value into the object part of the list instead of the array, and will accept any value.

In essence this way you get a hashtable instead of an array.

There are 2 issues I know of using it this way...
The first: you can't use the
soundManager.sounds.0.play()
syntax.
However, instead you CAN use
soundManager.sounds["0"].play()

The other issue is that if you try to use
soundmanager.sounds.length
then it will never show the correct number of sounds, however since you obviously already have an array of sounds then I wouldn't think that this will matter that much.

Actually in my case I only actually want this for some debugging ;-)

I absolutely love this idea. My only suggestion would be letting the coders choose the fallback order.
For instance, I want to be able to use waveform and eq data where possible, so I would want to have an order of flash then html5 but for those who don't, you might want to be able to set html5 first in case it would run faster (I believe that the html5 standard is also supposed to support seamless repeats, so that would certainly be nice).
It would also be nice to do it that way in case you know that say, most of your clientele will be using IE.
Plus, the HTML5 standard technically only supports OGG formats I believe at the moment (though browser makers obviously aren't going to be happy with just that as mp3 is a much more popular right now, so I expect they'll generally implement it, but some purist browsers won't)

On top of that allowing specific fallback orders according to file type would be nice as well. However that could make it very messy I think.

EX. (cleanest I came up with)

sm2.fileTypes = {
"mp3":["flash","html5audio"],
"ogg":["html5audio"],
"flv":["flash"],
.....
}

And then should be able to "override" the file type for a given sound object.

The biggest problem (which would also be a nice bonus at the same time) I see with that is that it would require soundmanager to change the way it functions for each file type. Meaning that you could get a mix of flash and html5 on the page.

Unfortunately flash/javascript does not have access to the filesystem for legitimate security concerns, so no you can't do this.
The best alternative I can think of would be to have a server on the client machines and then give them a full-copy of the app with the files on the server.
There may be a hack in one (or more) browsers that allows it but if you find it then they will patch it.

Otherwise what you are looking at is a standalone application, which could easily be accomplished through something like Adobe Air.
I have not tried SM with Air, but it might be worth looking into for such an app.

Hahaha, I hadn't even considered that! My entire implementation is dynamic and we don't even use "A" tags. It's all divs and spans where the songs are concerned and it's not even in the source because it's all loaded via ajax. You can still get the keys out of say, firebug, but so many of our users don't even know what firebug is that it's safe enough for us.

Having myself reconsidered the idea of the http headers, I expect that it would end up being convenient, but after a while if the user base for any website is to grow then it would have to be removed for compatibility with non-flash or non-js browsers.
Example:
iphone (rapidly growing popularity for browsing); no flash, therefore you should be able to click on the link to download it, however if we add a special http header then it would not be accessible via a regular "get" access. Of course you could check the special header AND the referrer, but after a while it ends up with really jumbled code when you need to hard code every single header that you may use.
In essence, with the idea of backward AND forward compatibility on the web (html5) it's probably a bad idea to implement something that would be dependant on that, though for now and the next year or two it will probably be a perfectly acceptible form of security.

Plus, the http headers are just as easy as post variables to fake with all the developer tools available these days. Let alone the thousands of hacking/pirating tools ;-)

Nicholas has my method to a T.
One extra little tidbit would be that you don't even need to have the sound files directory in the http accessible folders. You could have them in a completely separate location on the hard drive that apache doesn't allow access to, and then the "getmusic.php" file would be able to access them regardless. This way you can even protect against admin priviledges.

And of course for the HTTP headers thing, you could add that directly to the getmusic script. It should only be a problem of telling it to expire immediately so that as soon as you unload the sound it vanishes. Hadn't thought of that one, good call!