Don't the bit reservoir and some other features add inter-frame
dependencies?
Perhaps you could distribute 100 frames or so at a time to minimize
inter-frame
dependencies (and the overhead of communications latency).
- Original Message -
From: "Takehiro Tominaga" <[EMAIL PROTECTED]>
To: <
On Mon, 24 Jan 2000, Stephen Scheck wrote:
> 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 st
get pvm and distribute processing of individual wav's.
Frank
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
and the purpose of this would be...
- Original Message -
From: "Stapp, Acy" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, January 24, 2000 10:12 AM
Subject: RE: [MP3 ENCODER] LAME: does the encoding code support distributed
processing?
> I've found the better solution is to
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
>I guess I should have specified the purpose. I'm a netcaster using
>Shoutcast and need to convert my source files to 24kbps. I am wondering
>which MP3-producing codec people think is the best for such low bitrates.
>
>Thanks,
>Graham Spice
>
>--
>MP3 ENCODER mailing list ( http://geek.rcc.se/mp3e
I guess I should have specified the purpose. I'm a netcaster using Shoutcast and need
to convert my source files to 24kbps. I am wondering which MP3-producing codec people
think is the best for such low bitrates.
Thanks,
Graham Spice
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/
I've found the better solution is to distribute the encoding
per song instead of per frame. No changes are required to whatever
encoder you are using.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Nick Burch
Sent: Monday, January 24, 2000 4:36 AM
To: [E
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 thin
On 24-01-00 07:55:14, "Joshua Bahnsen" wrote:
>Ok I compiled lame 3.61 with DJGPP and I also compiled it with MSVC++ 5 SP3. I
>encoded
>the exact same file with the same options but I used GNU diff and it said the the
>files differed.
>Is this because the DOS version input is handled by libsn
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 enco
>From: Joshua Bahnsen [mailto:[EMAIL PROTECTED]]
> Ok I compiled lame 3.61 with DJGPP and I also compiled it with MSVC++ 5
SP3. I encoded
> the exact same file with the same options but I used GNU diff and it said
the the files
> differed. Is this because the DOS version input is handled by libsnd
Hi
I'm not all that clued up on the algorithms, but I think there is a more fundamental
problem with your idea than
the encoder.
Distributed.net will dish out about 15k a day to a pII-300 running 24/7. Seti@Home
will dish out about 500k a
day to a 24/7 pII-300.
128kbps mp3 data is about 1mb
13 matches
Mail list logo
