Hello Robert,
Friday, January 21, 2000, 2:09:55 AM, you wrote:
oops, sorry. it was my small but stupid mistake and now lame3.61 is not
twice slower 3.60.
RH what kind of mistake was it?
code was optimized for minimum size... 8"( . sorry.
P.S. so it is not necessary to reencode mp3
Best
From: Mathew Hendry [EMAIL PROTECTED]
Date: Thu, 20 Jan 2000 14:30:52 -
Maybe I'm on completely the wrong track here, but could they be recomputing
masking thresholds after each quantization?
I would guess it is slower because it does a more thorough
search for the best
X-Authentication-Warning: geek.rcc.se: majordom set sender to
[EMAIL PROTECTED] using -f
Date: Thu, 20 Jan 2000 21:47:58 +1300
From: Ross Levis [EMAIL PROTECTED]
Organization: http://soulfm.cjb.net
X-Accept-Language: en
Content-Type: text/plain; charset=us-ascii
Sender: [EMAIL PROTECTED]
"R" == Ross Levis [EMAIL PROTECTED] writes:
Before 3.61 was released there was some writing about faster
VBR-performance, is that gone because of the Huffmann-search ?
R I thought it was added to CVS but Takehiro has only added it to
R his snapshot version. The source is
- Original Message -
From: Peter Olufsen [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, January 20, 2000 7:31 PM
Subject: Sv: [MP3 ENCODER] VBR-speed
I thought it was added to CVS but Takehiro has only added it to his
snapshot version. The source is downloadable if you can
Dmitry schrieb am Don, 20 Jan 2000:
Hello Peter,
Thursday, January 20, 2000, 10:40:33 PM, you wrote:
PO I've done some testing on Lame, Mp3Enc31 and BladeEnc, encoding a 262sec. song
(45.2Mb).
PO I used a 600Mhz pentium III with Win-98, and the EXE from the russian site.
PO CBR,
Hello Peter,
Thursday, January 20, 2000, 10:40:33 PM, you wrote:
PO I've done some testing on Lame, Mp3Enc31 and BladeEnc, encoding a 262sec. song
(45.2Mb).
PO I used a 600Mhz pentium III with Win-98, and the EXE from the russian site.
PO CBR, high quality (-h / qual 9), full freq. range
I've done some testing on Lame, Mp3Enc31 and
BladeEnc, encoding a 262sec. song (45.2Mb).
I used a 600Mhz pentium III with Win-98, and the
EXE from the russian site.
CBR, high quality (-h / qual 9), full
freq. range (-k)
Mp3Enc31 BladeEnc
Lame3.61 Lame3.60
192
(-ms)
586
166
118
60
From: Meister [mailto:[EMAIL PROTECTED]]
Which are the best MP2 encorders ??? (at 320 kb/s)
Q-Design i-Media and Philips Power Library seem both to be highly regarded.
MP2 supports bitrates up to 384kbps, BTW.
-- Mat.
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Date: Wed, 19 Jan 2000 23:05:13 -0700
From: Mark Taylor [EMAIL PROTECTED]
Reply-to: [EMAIL PROTECTED]
Iwasa Kazmi recently sent me some scfsi fixes to the *decoding*
library, mpglib. It took me few days to add the patch, and
by the time I tried to commit the changes to CVS, it looks
I want to convert a CD to mp3 files with a good quality and a reasonable
file size. I played around with the VBR setting and found that using the
follwing switches ...
.
I am not a Pro, but have a similar question :
I use CDex including Lame 3.58, BUT
I use CDex including Lame 3.58, BUT only at 320 bitrate,
to get the best quality.
Which are the right options ?
VBR=0? stereo mode ? ..
Best quality is PCM at ~1400kb/s :) . Using 320kb/s which is only 4:1
compression, you may as well use ADPCM format which takes
X-Sender: [EMAIL PROTECTED]
Date: Wed, 19 Jan 2000 11:12:31 +0100
*NOTE* No psy-model is perfect, so there can often be distortion which
is audible even though the psy-model claims it is not! Thus using a
small minimum bitrate can result in some aggressive compression and
audible
Hi,
You might get a pop if you told the ripping program to produce a wav, then
told lame it was a raw headerless file. The pop could be the wav header
information. This also can happen if using cdrecord.
_J
In the new year, Doug Wood wrote:
I just did an experiment with Windows 98. Using
Iwasa Kazmi recently sent me some scfsi fixes to the *decoding*
library, mpglib. It took me few days to add the patch, and
by the time I tried to commit the changes to CVS, it looks like
I find this disturbing, since it means decoders based on mpglib
will not handel scfsi correctly. I think
I just did an experiment with Windows 98. Using Windows Media Player, if I
stopped playing something in the middle of a sound, it would start the next song
with a distinctive pop (either flushing a buffer or else it is setting the
output DAC from its last output value to the first output value
It is automatically activated with -h.
Ross.
-Original Message-
Nils Faerber
Hi!
Silly question since I obviously missed the posting:
I read that lame now can use full huffman search. But which option toggles
it? Or is it default now?
Thanks!
CU
nils
--
MP3 ENCODER mailing list (
Hi!
Silly question since I obviously missed the posting:
I read that lame now can use full huffman search. But which option toggles
it? Or is it default now?
Thanks!
CU
nils
--
Nils Faerber (Linux Nils)eMail: [EMAIL PROTECTED]
Student of computer science
I want to convert a CD to mp3 files with a good quality and a reasonable
file size. I played around with the VBR setting and found that using the
follwing switches ...
.
I am not a Pro, but have a similar question :
I use CDex including Lame 3.58, BUT only at 320
Is it a better choice to encode the CD on CBR 192 kbps?
to ensure quality you can use -b switch(minimum bitrate).
Something like -B320 -b160 -V3 -ms -k -h gives 180-200kbps avg with Lame3.61 and I
didn't noticed any flaws (except fatboy.wav :-/ ).
If there is silence in wav, bitrate falls to
I want to convert a CD to mp3 files with a good quality and a reasonable
file size. I played around with the VBR setting and found that using the
follwing switches (lame 3.60):
-h -k -lowpass 999 -b 32 -B 224 -v -V 3
results in mp3 files in stereo with a means bitrate of about 182 kbps. I
A)Use a high-quality time domain filter instead of fast MDCT ("Soft
time-domain filtering")
The fast MDCT filter must be what we have in lame: the filter acts
directly on the MDCT coefficients - I always considered this a hack,
but now that I know it has a fancy name "soft time-domain
Has anyone else compiled Lame 3.57+ using DJGPP? I used pgcc-2.95.3 that
I compiled myself. Lame is the only thing that I've had problems with...
The latest version that I compiled is 3.61Beta and it compiles without
many problems, I've had to tweak a few things, but all in all, nothing
major
Date: Tue, 18 Jan 2000 22:35:38 +0100
From: Mutation/Ivo [EMAIL PROTECTED]
I was wondering why the mode is set to stereo by default with bitrates higher
than 160 kbit and not to joint stereo. Does it not make sense anymore with such
high bitrates or is there some other reason for this?
On Tue, 18 Jan 2000, Paul F. Johnson wrote:
I am currently using 0.59-q. No problems so far, apart from some unaligned
traps when using the -z or -Z params. I haven't played with 0.59-r at all,
since it seg-faulted the first time I had ever tried it (machine is an Alpha
164SX)
struct timeval
what material produced artifacts? i havent heard any artifacts as such.
- Original Message -
From: "Mathew Hendry" [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, January 18, 2000 7:38 AM
Subject: RE: [MP3 ENCODER] the new fraunhofer codec
From: Ampex [mailto:[EMAIL
I was wondering why the mode is set to stereo by default with bitrates higher
than 160 kbit and not to joint stereo. Does it not make sense anymore with such
high bitrates or is there some other reason for this?
Ivo
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Hello,
Just a little question : when using constant bit rate above 160 kbit/s
(i.e. = 192), are the "-h" "-k" switches still irrelevant ? I
ask this question because of the modifications introduced in
version 3.60 (concerning lowpass filtering visible or not) and the "-h"
switch discussion...
In article [EMAIL PROTECTED],
Mark Taylor [EMAIL PROTECTED] wrote:
[snip]
#4 is by far your biggest problem. It is a German company that holds
the mp3 encoding patents, and has attempted to enforce them in
the past. You will need to pay them $15,000 per year
plus other fees to
Ampex wrote:
how is the quality of the new fhg codec, the one included in
musicmatch jukebox, cool edit 2000 and nero? encoding time is very
very slow at highest quality, is this any indication of a higher
quality encode taking place, or simply bad programming? has anyone
done any
From: Ampex [mailto:[EMAIL PROTECTED]]
how is the quality of the new fhg codec, the one included in
musicmatch
jukebox, cool edit 2000 and nero? encoding time is very very
slow at highest
quality, is this any indication of a higher quality encode
taking place, or
simply bad
how is the quality of the new fhg codec, the one included in musicmatch
jukebox, cool edit 2000 and nero? encoding time is very very slow at highest
quality, is this any indication of a higher quality encode taking place, or
simply bad programming? has anyone done any benchmarks of the codec as
From: David [EMAIL PROTECTED]
This is an example of peak normalization (correct me if I am wrong)..
We have a song in a (stereo 16bit)wavfile called mysong.wav
we scan the wav files and find these values..(they are fake of course)
MaxRightSample = 16000;
MinRightSample = -8000;
MaxLeftSample
Good idea but this would cause to play songs with a high amplitude (this
are "normal" songs as the amplitude should use the full range of 16 bits)
with a low output gain, to catch up songs with a low amplitude. The output
gain of my soundcard is quiet low and I would receive more noise from
You are right if you are talking of mixing lots of tracks. But for one
time normalization of a final track (that what we are talking about) it is
absoulutely irrelevant, where my samples are from (single sample from
analog or mixed from 256 sources). I have 16 Bit Samples and I introduce
an
This is nearly what I would understand of normalization except don't use
different factors for left and right channel. This would change balance in
the soundfile. Instead use the lower value of the amplification factors
for left and right channel.
Thomas Marschall
David [EMAIL
From: "Gabriel Bouvigne" [EMAIL PROTECTED]
Date: Mon, 17 Jan 2000 18:02:13 +0100
The 4 things are:
A)Use a high-quality time domain filter instead of fast MDCT ("Soft
time-domain filtering")
The fast MDCT filter must be what we have in lame: the filter acts
directly on the MDCT
Hi,
Check out ecasound at http://www.wakkanet.fi/ecasound. It has a nice
compresser that is tunable. Perhaps you may find it useful.
_J
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
I agree with -h n option.
So I list the some quality depending settings and some summury.
Any comment welcomed.
1 about Huffman code searching
I think mp3enc has 3 mode of huffman code searching.
(1) the aproximated best Huffman code.(older LAME code)
(2) after last loop run, perform a full
Hi all!
I made a new subblock gain and scalefactor_scale implementation.
Here's it. Any comment welccomed.
The test code is available at my snapshot.
http://www.isoternet.org/~tominagag/lame-beta/lame-0116.tar.bz2
1. scalefactor scale
The current LAME can treat with scalefactor_scale
This is an example of peak normalization (correct me if I am wrong)..
We have a song in a (stereo 16bit)wavfile called mysong.wav
we scan the wav files and find these values..(they are fake of course)
MaxRightSample = 16000;
MinRightSample = -8000;
MaxLeftSample = 15876;
MinLeftSample =
On Mon, 17 Jan 2000 14:12:20 -0500, Mark Stephens wrote:
everything else equally. Normalization is like turning up the volume, no
dynamic range is lost. The difference between the quietest sounds and the
loudest sound is the same. If you change the difference (dynamics) of the
music then you
Howdy
You mentioned the limited value of normalization that only looks at peak
levels to normalize, especially if there are just a couple of loud passages
in a song. If you first applied peak limiting, the loud passages would be
compressed to be just a little louder than the normal passages.
On Mon, 17 Jan 2000 11:03:57 -0500, Mark Stephens wrote:
Wouldn't that be compression, instead of normalization?
I don't really know. I don't have much experience with compressors.
Will a compressor boost a quiet waveform and allow it to clip?
I still have an old DBX compressor/expander box
Date: Mon, 17 Jan 2000 15:47:52 +0100
From: [EMAIL PROTECTED]
I think performance loss due to rounding errors can be ignored because:
You do mean _quality_ loss ?
rounding errors are _very_ small
(if we take 16 it samples we have values from -32767 to +32768
if we assume we have a
Wouldn't that be compression, instead of normalization?
I still have an old DBX compressor/expander box where I can choose to
compress over the whole range, or set it to peak limiting mode and only
compress over a certain threshold. It sounds like it might be valuable to
have a routine that can
On Mon, 17 Jan 2000 14:41:05 +0100 (MET), DAVID BALAZIC wrote:
From: Ross Levis [EMAIL PROTECTED]
I can't help you directly but I always normalise before encoding music for my FM
radio
station. I use the CD rippers Audiograbber and CDex which both have this option.
By normalizing 16 bit
I think performance loss due to rounding errors can be ignored because:
rounding errors are _very_ small
(if we take 16 it samples we have values from -32767 to +32768
if we assume we have a sample around +-16000 and double
the amplitude we get around +-32000 with an error of
From: Ross Levis [EMAIL PROTECTED]
I can't help you directly but I always normalise before encoding music for my FM radio
station. I use the CD rippers Audiograbber and CDex which both have this option.
CDex being freeware, you may be able to obtain code from the author
(mailto:[EMAIL
49 matches
Mail list logo
