Looks like a Base64-encoded JS URI in the video player URL. Somewhat sneaky. How it ends up redirecting the page to a reblog URL isn't clear.
https://gist.github.com/4196142
The code is on github ( https://github.com/scottschiller/SURVIVOR ) for those interested. The level editor does horrible things with data in the URL, but it was a fun add-on.
Sorry it isn't more clear - by default, you get "non-scratch mode" until it's determined your GPU (hardware accel in browser) + CPU can handle the extra load. Once you opt in, localstorage remembers that preference until you opt out.
You can force scatch mode via http://wheelsofsteel.net/?scratch=1 - but without hardware accel (hardware + OS + driver support, I recommend Safari 5 or Chrome 12), rendering falls back on CPU use which will skyrocket and that will kill the audio processing bits.
I wrote a small book on the whole process (and performance caveats) on my main site as someone linked below. Numerous pics + videos too. ;)
I haven't touched this stuff since last October (boo), but I put it on Github in the hopes someone might find it useful (yay!) Currently distracted with other personal projects, but hope to revisit this at some point.
That's in there also, yep. The prototype is aiming to recreate most of the usual tricks. It gets a bit hackish. Release TBD, hopefully soon. A teaser: http://www.youtube.com/watch?v=6NiMMSyk9GU
The next step would be to move to websockets on the client (and also node, yes), and eliminate the Flash dependency altogether.
I personally prefer to work in HTML/CSS/JS entirely, but there are some things that Flash does nicely - and it can talk to JS (and can be fast), so it makes for a way to extend functionality in some cases.
Flash can load MP3s from remote domains, but it cannot read certain metadata (eg. ID3 tags, waveform/eq/spectrum data) unless granted permissions via a crossdomain.xml policy file. For hosting, the SWF should be on the same domain as the HTML document or JS-Flash communication will be restricted (or, use the cross-domain version of the SWF.)
If you're loading the demo offline (ie., from the local file system via file:// or some such), Flash enforces strict (but good) security which doesn't allow JS and Flash to talk by default.
To allow JS+Flash (ExternalInterface) to work together, you have to whitelist the specific location (by either whitelisting a whole directory/path, or specific file). I recommend just whitelisting the parent directory, as opposed to the root.
These types of restrictions do not apply when the content is served over HTTP, ie., as with the live site.
(I write and maintain SoundManager 2, which is a JS + Flash sound library as used in this nifty demo - I'm honored. :P)
One person has spent 10,000+ hours building this since 2018, including developing their own animation tool and a custom video format.