You're right Mark, compared to Lame 387 MMX --abr 128 Xing is only two
times faster Bo)
Regards,
Wim Speekenbrink
- Original Message -
From: "Mark Taylor" [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Saturday, September 30, 2000 6:19 AM
Subject: Re: [MP3 ENCODER] MP3 encoding speed :
Hi, I have used lame for 1 day now, and I really
like it, except for the following 2 'issues':
- Lame does not support outputting to a wav file
with mp3 compression (a mp3 with wav header). Since these files are needed for
programs like virtualdub (for combining video and audio), this
- Lame does not support outputting to a wav file with mp3
compression (a mp3 with wav header). Since these files
are needed for programs like virtualdub (for combining
video and audio), this feature would make lame even more
complete.
Don't use LAME - use CDEx with its LAME plugin:
- Lame does not support outputting to a wav
file with mp3 compression (a mp3 with wav header). Since these files are
needed for programs like virtualdub (for combining video and audio), this
feature would make lame even more complete.
I agree about this. I'd also like to see this feature
Gabriel,
I don't think is very complicated to add the CDex Riff-Wav
code to Lame front-end, maybe later this week I have some time to implement this
Albert
- Original Message -
From: Gabriel
Bouvigne
To: [EMAIL PROTECTED]
Sent: Sunday, October 01, 2000 3:42 PM
Subject: Re: [MP3
I think the mp3 encoding library should do what it is
supposed to do, encode pcm samples into mp3 frames.
BTW, Robert and everyone, how should we treat with mpglib and lame_mp3_XX
routines in frontend/get_audio.c and amiga_mpega.c ?
I think these routine should be another library,
Mark Taylor schrieb am Son, 01 Okt 2000:
I think the mp3 encoding library should do what it is
supposed to do, encode pcm samples into mp3 frames.
BTW, Robert and everyone, how should we treat with mpglib and lame_mp3_XX
routines in frontend/get_audio.c and amiga_mpega.c ?
I
Sorry to write to this board, but it was my last resort to reach the authors
of the project... I wrote an email regarding this bug, and it's been already
one or two weeks, no response. So as i know Monty and the other developers
read this, i thought i'd share this with you...
I don't know if
In reply to Robert Hegemann [EMAIL PROTECTED]:
Second: With some (usually high) bitrates, LAME seems to mangle the
bitstream. The effect is usually to hear short bursts of garbage in the
left channel, but it seems to depend on the input file as well as the
bitrate. Not all frames are
Please pardon the question if naive but I couldn't find the answer
elsewhere...
I encode the same .wav to 2 different .mp3's - first one CBR (-b256 -ms -h),
second one VBR (-V1 -b128 -mj -q1).
Then I decode (--decode) the 2 .mp3's back, and the resulting .wav's have
different sizes, both of them
Hi Robert,
This just seems like a lot of work for no real gain since all 4
libraries are samll and closely related. To build LAME we would need
a ./configure setup which builds 4 different libraries. so I guess I
just dont see any reason to seperate them.
Special applications, like embeded
11 matches
Mail list logo
