On Wed, 27 Sep 2000, Frank Klemm wrote:
> +--X8X8---+
> | [_] I do not vote|
> | [_] pointer to a public structure|
> | [_] private struct |
> | [X] pointer to a private struct |
> | [_] lame handle
Hello Robert,
Thursday, September 28, 2000, 1:14:17 AM, you wrote:
RH> At least your 3.87 MMX version seems to be compiled with the
RH> Makefile.MSVC I checked in, with RH_AMP and RH_VALIDATE_MS
RH> enabled. Dmitry, is that right?
yes. i used your defult Makefile.MSVC, b
In the last episode (Sep 28), Mark Powell said:
> BTW The gcc 2.95.2 options are perfectly valid for FreeBSD as well as
> Linux. Obviously :) Can they be copied into the FBSD section too?
>
> # these options for gcc-2.95.2 to produce fast code
> # CC_OPTS = \
> # -Wall -O9 -fomit-frame-po
> "M" == Mark Powell <[EMAIL PROTECTED]> writes:
M> BTW The gcc 2.95.2 options are perfectly valid for FreeBSD as
M> well as Linux. Obviously :) Can they be copied into the FBSD
M> section too?
silly thing. you had better detect CPU/Compiler by configure and
output the option to
> "M" == Mark Powell <[EMAIL PROTECTED]> writes:
M> How did you get the Linux version to assemble the MMX code?
M> I've had no luck with GNU as v2.10.0 under FreeBSD. I'm
M> obviously missing something?
you are missing NASM.
---
[EMAIL PROTECTED] // may the source be with you!
-
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 pl
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
th
On Wed, 27 Sep 2000, Robert Hegemann wrote:
> On my Linux Box with a Pentium 166 MMX the MMX and non-MMX
> version produce bit identical results.
How did you get the Linux version to assemble the MMX code? I've had no
luck with GNU as v2.10.0 under FreeBSD. I'm obviously missing some
> 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?
Should they be considered as default switches? In this case, why aren't they
defined in the VC project?
Regards,
--
Gabriel Bouvigne -
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.
>
> +--X8
Roel VdB schrieb am Mit, 27 Sep 2000:
> 3.86 (nommx)
> > average: 235 kbs
>
> 3.87 nommx:
> > average: 225.8 kbps
>
> 3.87 MMX
> > average: 224.6 kbps
>
> remarks:
> 1) 3.87 MMX is smaller, yet it sounds better (???) (velvet JS noise)
does it sound better than 3.87 non-MMX or 3.86?
>
:: /* 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);
::
:
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|
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
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| 0:
>> 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
Sigbjřrn Skjćret wrote:
>
> >> and parsing gets abit more messy...
> >How ?
> [...]
>
> 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
>> 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);
Sigbjřrn Skjćret wrote:
> >there is not other way to determine whether all the args has been read
> >the __FLOAT and __INT attachments are there only to help illustrate my
> >idea,
> >but could be helpful in the actual implementation too
>
> Yes, but this still requires the parameters to be corre
> "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
>> 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 lame_gl
>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
With VC6 I got:
D:\Prog\lame\quantize_pvt.c(932) : warning C4307: '*' : integral constant
overflow
D:\Prog\lame\quantize_pvt.c(933) : warning C4307: '*' : integral constant
overflow
D:\Prog\lame\quantize_pvt.c(934) : warning C4307: '*' : integral constant
overflow
D:\Prog\lame\quantize_pvt.c(935)
Here is the 3.87 html doc. Some files of the old doc are now useless
Regards,
--
Gabriel Bouvigne - France
[EMAIL PROTECTED]
mobile phone: [EMAIL PROTECTED]
icq: 12138873
MP3' Tech: www.mp3-tech.org
html.zip
> 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 ba
> "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 t
Sigbjřrn Skjćret 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 tha
::
:: 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 at
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
:: >
:: 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
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 working
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 libra
> > I'm not surprised, considering you are probably only the 3rd
> > person to ever use freeformat :-)
>
> first is Mark, who is the second person?
Not the second, but, I find free-format *really* useful.
However, I am using it for very *low* bitrates.
ie: 8 to 32.
Owen
--
MP3 ENCODER
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.
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 su
35 matches
Mail list logo
