Hi Frank,
>
> 1. FFT filters are strictly speaking no filters (they are not a LTI system),
>so they have some nasty properties, which are more or less audible. The
>audibility depends on the steepness of the filter. So high passes should
>never be made by FFT filters. Never ever.
>
Hello Liviu,
Once you encoded the wave into MP3, the originality is lost forever. The first
wave you'll get will have exactly the same quality of the MP3 of "CBR (-b256 -ms
-h)" and the second wave will have exactly the same quality of "VBR (-V1 -b128
-mj -q1)". Think about it for some time, and
> > I think this should be a seperate utility outside of lame? Most people
> > encode from CDs, which usually are already correctly filtered for stuff
> > below 20 Hz.
> >
> For pop music this is (mostly) true. I will test several CDs. Next week.
> The psycho part I would nevertheless filter wi
> > Is there any application for this?
> >
> May be applications where an exact synchronization is necessary (video?
> duplex MP3 encoding/decoding?). I don't know. But if it is necessary it is
> hardly to fix. Otherwise we need additional 4 or 8 bytes of RAM to store
> a double or long double in
Robert> You can add --raise-smr 1 to 1.) and compare again
I've also compared using --raise-smr 1.
As far as I tested, --nspsytune also gives better result with this
setting.
--
Naoki Shibata e-mail: [EMAIL PROTECTED]
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/
>
> 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.
>
> 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 si
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 en
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
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 frame
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 i
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.
>
> >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 li
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
Hello Frank,
Sunday, October 01, 2000, 4:43:12 PM, you wrote:
FL> - Lame does not support outputting to a wav file with mp3
FL> compression (a mp3 with wav header). Since these files are needed
FL> for programs like virtualdub (for combining video and audio), this
FL> feature would mak
>- 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
> - 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:
htt
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 featu
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
19 matches
Mail list logo
