Howdy Robert,
Thanks for the quick response.
2) In layer-II coding, the first band to code using
intensity is specified
by the mode extension - in layer-III it can by dynamically
varied and is
understood implicitly from the bitstream by the decoder.
But the spec gives
no suggestions
Title: RE: [MP3 ENCODER] realtime encoding specs ?
Mark Powell wrote:
That was with the options:
-V1 -b128 -mj -h
under FreeBSD. It wasn't a competition I was just giving him some
empirical evidence to work with :)
My reults were based on -V4 -b32 -mj -h
Ross.
Mark Taylor schrieb am Die, 26 Sep 2000:
I think we have to keep the old interface, since several applications
use it. So lame_global_flags will still have to be instantiated by the
calling program and exposed to the calling program. I dont think this
is incompatiable with a shared library?
I am looking to hire one or more mp3 programmers for a large and extremely
interesting project. The programmers must be very familar with one of the existing
cross platform open source players (like Xaudio or mpg123) and have lots of experience
with Mpeg player technology. We will be
:: Sigbjørn Skjæret schrieb am Die, 26 Sep 2000:
::Why do we need float at this point ??
::
:: Because several of the parsed arguments are floats?
::
:: ie. frequencies could be passed in Hertz as ints,
:: was just something to think about now while we
:: change the API
::
:: another thing that does not work:
::
:: lame -b640 --freeformat -g fatboy.wav fatboy.mp3
:: fatal error. MAXFRAMESIZE not large enough.
::
:: in mpg123.h MAXFRAMESIZE is defined as 1792, but a 32 kHz 640 kps MP3
:: consists of 2880 bytes per frame (2090
Hi Mark,
:: A couple of comments/questions:
::
:: :: Also, every transition from two different size windows is lossy. The
:: :: MDCT is only lossless for overlapping windows of the same size.
:: ::
:: Is this a problem of bad designed (asymmetric) window functions or a
::
Sigbjrn Skjret wrote:
This way there is no need to parse any strings, we don't pass
any pointers, the setup routine would just be a big switch/case.
This is basically the way TagItems work when passed on stack, in fact, that
combined with another identical function that does float
"R" == Robert Hegemann [EMAIL PROTECTED] writes:
R Mark Taylor schrieb am Die, 26 Sep 2000:
I think we have to keep the old interface, since several
applications use it. So lame_global_flags will still have to
be instantiated by the calling program and exposed to the
Yes, this is how the decoder figures out the break between M/S or L/R and
intensity. But how does the encoder decide where to put the break?
Clearly
it is a tradeoff between quality and bit usage. A naive algorithm would
exhaustively try all 13 or 21 possibilities for intensity start bands
IIRC, if you use varargs then the compiler can't detect if the supplied
parameters
are of wrong type. Example :
[...]
The compiler won't notice that the parameter is of wrong type
and when the function will try to extract an int from the stack,
it will get garbage.
This is indeed true, and
o main.c can't hold lame_global_flags, change lame_init() to allocate and
return a pointer to lame_global_flags.
o Move lame_global_flags out of lame.h, it should never be accessed
externally.
I think we have to keep the old interface, since several applications
use it. So
"G" == Gabriel Bouvigne [EMAIL PROTECTED] writes:
G With VC6 I got:
G warning C4307: '*' : integral constant overflow
Sun's CC(Workshop 4.2) on Solaris 2.6 says same warning, but the
binary runs fine.
---
Takehiro TOMINAGA // may the source be with you!
--
MP3 ENCODER mailing list (
and parsing gets abit more messy...
How ?
[...]
This is how it looks now, better than using va_arg() at each case imho...
void lame_set_int(lame_global_flags *gfp, lame_param_tag tag1, ...)
{
va_list ap;
int param; /* (varargs promotes integrals to int) */
va_start(ap, tag1);
This is how it looks now, better than using va_arg() at each case imho...
Why is it better ?
You wasted an additional variable and gained ( maybe ) some code space
by not doing a function call ( or maybe it is a macro , probably
platform dependant ) every time.
It's usually a (rather messy)
Hello,
first some data: (-V1 -mj -h -b128 -q1)
3.86 (nommx)
Encoding c.wav to c-386-nommx.mp3
Encoding as 44.1 kHz VBR(q=1) j-stereo MPEG1 LayerIII ( 6.0x estimated) qval=1
Frame | CPU/estimated | time/estimated | play/CPU | ETA
12498/ 12498(100%)| 0:04:07/ 0:04:07|
I had the same problem of MMX giving different results than the non-mmx.
Maybe the algorithms are different? Is that correct? Isn't MMX (assembly in
general) going to use a different algorithm, because if you are using the
same algorithm for assembly as you do in C, shouldn't the C compiler give
To avoid endless debates about the interface without clearifying the basic
concept I do introduce all possible methods I know (for C) with explaining
all pro and cons I know. I hope this is the best I can do.
+--X8X8---+
| [_] I do not vote|
:: /* Usage :
:: lame_set_parameters(gfp, LAME_SAMP_FREQ__INT, 44100 ,
:: LAME_NR_CHANNELS__INT , 2 ,
:: LAME_LOW_PASS_VALUE__FLOAT , 16.050 ,
:: LAME_LOW_PASS_WIDTH__FLOAT , 0.75,
:: LAME_COMMENT__STRING , "This is cool" ,
:: LAME_END_MARKER);
::
Frank Klemm schrieb am Mit, 27 Sep 2000:
To avoid endless debates about the interface without clearifying the basic
concept I do introduce all possible methods I know (for C) with explaining
all pro and cons I know. I hope this is the best I can do.
On Wed, 27 Sep 2000, Robert Hegemann wrote:
At least your 3.87 MMX version seems to be compiled with the
Makefile.MSVC I checked in, with RH_AMP and RH_VALIDATE_MS
enabled. Dmitry, is that right?
BTW Robert, are you recommending these options for improved quality? Would
that
On Wed, 27 Sep 2000, Roel VdB wrote:
1b)3.87 -V1 is 20% faster than 3.86 (thanks Robert!)
1c)3.87 -V1 MMX is 35% faster than 3.86 (thanks Takehiro!)
I'll second the thanks to you both :)
2) I miss the # of frames in each bitrate mode. The new real-time %
data looks really neat, but
22 matches
Mail list logo
