You missed one of my main points - I want to do this so
I can gain knowledge by dealing with the various issues
that a project such as this could entail. E.g. writing
threaded, multi-client handling socket code, with all the
associated data structures and support code, designing
the client/server protocol, etc. I haven't done a large
project like that before, and doing this would expose
me to a lot of the areas that I want to gain expertise
it.
I just think MP3 would happen to be a very cool payload. I
could do a distributed client/server system for anything -
distributed huffman encoding, or even matrix operations
on random data that I don't even care about. But if I can
make it work w/ MP3 encoding, why not?
>From the commentary so far, it seems that using the larger
internet/WAN would yield no gain in encoding time, although
I never really envisioned it as a large scale, 'public'
sort of thing exactly like distributed.net. Instead, I had
in mind that people might use it to create smaller, private
clusters with their friends, with all participants having
high-speed connectivity (no 28.8 modems, here). And, in
the words of another respondant, yes, there is a very
decent corporate LAN in my workplace, and getting more
decent all the time :) As well as a fair number of fast Suns
which idle afterhours most of the time.
As far as muddying up the codebase, my goal here is not to
learn the MP3 encoding algorithm in detail. In fact, I
would like to avoid doing so as much as possible, in keeping
with principals of procedural abstraction/information hiding/
insert your favorite academic software design philosophy here.
So my goal would be to keep hands off the LAME code as much
as possible. Ideally, the separation between the distributed
networking code and the encoding code should be strict, with
a well defind interface. Any changes I would make to LAME
would only be to improve its modularity to achieve that
well defined interface (and not to criticize LAME or its
author(s) - it may already be modular enough), and of course
it would be up the LAME maintainers if they wanted to
incorporate the changes back into LAME.
Further comments welcome, and no one has yet directly answered
my question - is the algorithm parallelizable?
-Steve
-----------------
Stephen J. Scheck
[EMAIL PROTECTED]
On Mon, 24 Jan 2000, Greg Maxwell wrote:
>
> I think that muddying up the codebase for this would be a loss esp when
> it's so easy to write a frontend script that encodes seperate files on
> seperate computers.
>
> Who has so much to encode that they need a cluster but only has a few
> files?
>
> On Mon, 24 Jan 2000, Takehiro Tominaga wrote:
>
> > I think WAN-distributed mp3 encoder is hard and not a good idea, too
> > because of the network data flow.
> >
> > But a computer cluster connecting with not WAN but LAN, the distributed
> > encoder would be a good plan.
> >
> > The latest GOGO-no-coder supports multi thread.
> > With this feature, it use multi CPU to encode and can do faster encoding.
> >
> > Maybe we can write the mp3 encoding cluster based on this.
>
> --
> MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
>
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
