15 Nov
2007
15 Nov
'07
10:53 p.m.
Date: Thu, 15 Nov 2007 20:44:02 -0500
From: Frank Pirrone <frankpirrone(a)gmail.com>
plutek-infinity wrote:
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...
--
.pltk.
<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.