Date: Thu, 15
Nov 2007 20:44:02 -0500
From: Frank Pirrone <frankpirrone(a)gmail.com>
plutek-infinity wrote:
<snip>
i did some quick "back-of-an-envelope" figuring while riding around on the bus
today, and came up with this worst-case scenario (well... BEST-case, really.... he-he..):
assume 44.1kHz/32-bit - that's around 11MB/track/min
assume we want to produce a complete record (~60min) - that's about 2/3 GB per track
assume we're going 24 tracks deep - that's about 16GB
assume we need some headroom (text files, presets, screenshots, whatever) - call it 20GB
instead
assume we have 20 users, who ALL upload AND download EVERYTHING twice every week -
that's somewhat less than 4TB/mo
SO........
20GB storage
4TB/mo. bandwidth
<snip>
This is absolutely NOT the way to construct a song through on-line
collaboration. See my postings for an alternative detailed proposal.
They generated little comment, so I assume little interest, but this
magnitude of traffic and bandwidth is both whacked and needless.
frank -- i take your point, absolutely. initially, i was unclear on how the substitution
of uncompressed tracks for compressed ones would be made, but i guess if there is a
standard naming convention or session file with timestamps, that will not be a problem.
when the suggestion of CcHost came up, i simply jumped on it as a way of getting the ball
rolling, and began to imagine worst case scenarios, not wanting to jump into something i
couldn't handle. upon sober reflection, a dead-simple repository of compressed tracks
with a clear file-naming and/or session-file protocol is killer -- lean and mean. i like
it.
let's continue the discussion tomorrow...
Why not try out both idea and trash the one or merge teh best bits as
time goes on. It should be easy enough to convince people to make two
tracks as a test case and build from there...
I can host the wiki version if someone want to point a domain name at my
server. I have around 300GB to spare at the moment.
Cheers.
--
Patrick Shirkey
Boost Hardware Ltd.