There are two possiblities for display update frequency:
1st)
#define I_HAVE_NEVER_SEEN_LAME_ON_A_486_100_OR_A_ATHLON_1000
and display updates every 50 frames (MPEG-1) or 100 frames (MPEG-2)
(Why this differences?)
This difference is probably because in mpeg-1 there are
May be too difficult for end users, but nice for development.
I don't think that it may be annoying for end users.
Another question would be, what is best:
* Showing the percentage relative to the number of already coded frames
I would personnaly vote for this one.
Regards,
--
Jaroslav Lukesh wrote:
| Another question:
| What is ETA? A basque terror organization? I don't found it in any
printed
| dictionary, also not in the big webster I bought in England. But you find
| nearly all C keywords in it ;-)
|
|
| eta: the 7th letter of the Greek alphabet -- H or n
Frank Klemm wrote:
On Tue, Sep 12, 2000 at 12:25:46PM +0200, Gabriel Bouvigne wrote:
FhG forces 48 kHz on 320 kbps. Maybe to bring the bits/granule ratio to the
right place.
But in VBR mixed sampling rates are fordidden.
Also in CBR.
I recall seeing a test bitstream with
Thanks - I'll revisit your website.
Another question :) Is there a preferred (or even mandatory)
sequence to command-line opions for Lame ? I remember how quirky
DOS could be in this respect
The only problem is if you use incompatiable options - LAME
does not check for
Mark Taylor schrieb am Mit, 13 Sep 2000:
Thanks - I'll revisit your website.
Another question :) Is there a preferred (or even mandatory)
sequence to command-line opions for Lame ? I remember how quirky
DOS could be in this respect
The only problem is if you
On 12 Sep 2000, Frank Klemm wrote:
RPC support, SMP support and distributed computing would be a very nice
thing for LAME and would be an outstanding feature.
Are there are plans and interests to support this? Not this year, but
starting with this things in spring next year, not earlier.
Frank, your are missing a third option:
PROJECT_MAINTAINER_DOES_NOT_CARE_AND DOES_NOT_WANT_THIS_CODE_IN_LAME
The display is updated every 50 frames. It is simple
and works well enough.
I want this type of code kept to an absolute minimum since this kind
of stuff really belongs in the front
I'm monitoring the encoding of material originally recorded in the
30's (now on CD). When I look at the MDCT and scale band info:
Left and Mid Channels closely match.
Right Channel shows very little energy.
Side Channel shows very little energy.
In CoolEdit LR "appear" to be almost
::
:: Frank, your are missing a third option:
::
:: PROJECT_MAINTAINER_DOES_NOT_CARE_AND DOES_NOT_WANT_THIS_CODE_IN_LAME
::
:: The display is updated every 50 frames. It is simple
:: and works well enough.
::
:: I want this type of code kept to an absolute minimum since this kind
::
:: This also prevents lame from update frequencies in the range of
:: 50...60 Hz
:: (resulting in additional hum!) on Athlon 1000 systems coding mono,
:: low
:: quality MPEG-2 files. Sounds worse.
::
:: Are you saying (I hope say is correct) that on fast systems,
[Charset iso-8859-2 unsupported, filtering to ASCII...]
:: Frank Klemm wrote:
::
:: The following outputs have the following meanings:
::
::[ ] p = 0.00%, never used
::[%..] 0.00% p 0.01%
::[%.0] 0.01% p 0.05%
::[%.1]
12 matches
Mail list logo
