>Date: Thu, 15 Nov 2007 20:44:02 -0500 >From: Frank Pirrone <frankpirrone@xxxxxxxxx> >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... -- .pltk. _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
