Mark wrote:
If no problems show up with 3.80, then in a few weeks I think
we should make another official release, and finally drop all
the dist10 patching stuff!
I think it's great that this could be done, but there must be something I've missed.
My understanding is that a licence would
On the site you recommend WinAMP for the listening,
while just recently a winamp bug was discussed on this
list, which add corruptions during playback of mp3s !
The bug is present in winamp 2.62 ( latest as of this writing ),
as reported on this list.
david balazic
George wrote:
Hi to
If you remember my question a while ago about crippling wavs so they sound bad at all
but the highest bitrates, this is a follow-up.
My band is recording its album in the near future. I know MP3 has its limitations, I
thought it would be useful for the band from a business perspective if we
David wrote-
On the site you recommend WinAMP for the listening,
while just recently a winamp bug was discussed on this
list, which add corruptions during playback of mp3s !
The bug is present in winamp 2.62 ( latest as of this writing ),
as reported on this list.
Can anyone say whether it
Shawn Riley wrote:
David wrote-
On the site you recommend WinAMP for the listening,
while just recently a winamp bug was discussed on this
list, which add corruptions during playback of mp3s !
The bug is present in winamp 2.62 ( latest as of this writing ),
as reported on this list.
Shawn Riley wrote:
Can anyone say whether it would be wise to use an earlier version of Nitrane's
decoder (distributed w/ Winamp version 2.1-something ) with Winamp ver2.6-something?
David wrote:
Note that some winamp versions ( early 2.x , I think ) didn't use
Nitrane , but Faunhofer !
I'll
haven't used those 2 earlier versions of Winamp for ages. So why would
Nullsoft (or whoever it is) abandon Fraunhofer for Nitrane?
Nitrane is based heavily on AMP. Or more accurately, it started as AMP.
It was supposedly rewritten and nitrane was "better".
In any case, Playmedia sued
LAME (LAME is After all a Mp3 Encoder)
I still like LAME (Lame ain't your momma's encoder)
jack.
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
I think your wasting your time Shawn. There have been problems in the past with LAME
and other encoders which may have been expoited to make bad sounding MP3's, but as
each distortion is isolated, it has also generally been worked on to overcome the
distortion. So I suspect your album would
Christian Schepke wrote:
What about the idea with the trial-version of LAME. AFAIK it's allowed to
distribute trialversions of mp3-encoders. We could include a little routine
that displays a WARNING TRIAL EXPIRED or something alike, when the 30 days
are over.
That is true BUT, the binary
Hi Ivo!
Woah, that's pretty big difference, isn't it??
YES
b) you use an older, slower version of LAME
Well, it was based on some older versions, I'm now testing it with the
version
I have now, which is Lame 3.69. Is there much difference in speed from
the
newer versions?
I can't
Well, I think the name LAME doesn't need to be changed whatever happenes... Now
we know LAME as "LAME Ain't an MP3 Encoder". Dropping the whole ISO code, LAME
may become "LAME is An MP3 Encoder". It's LAME either way! What do you say? :-)
PS- Would the name have to be changed to something like
AFIR you are not allowd to use VBR with free format. However, is that
another part of the standard lame can ignore (via option)?
It might simplify VBR if we 'threw out' the bir resviour and just used
free format frames.
On Sat, 6 May 2000, Mark Taylor wrote:
Mark Taylor wrote:
"R" == Robert Hegemann [EMAIL PROTECTED] writes:
R I can't remember, but I think there is a speed increase from
R 3.69 to 3.80
Yes there is. I made a more fast/efficient huffman coding.
but another coding change (for thread safe) vailed it...
"I" == Ivo [EMAIL PROTECTED] writes:
Michael Hare wrote:
I've noticed a HUGE reduction in the average bitrate between
version 3.70 and 3.80, using VBR with the highest quality setting.
I made some tests yesterday and I found that there was a
noticeable difference in size between 3.70 VBR and 3.80 VBR.
It seems that it
Well, it was based on some older versions, I'm now testing it with the
version
I have now, which is Lame 3.69. Is there much difference in speed from
the
newer versions?
I can't remember, but I think there is a speed increase from 3.69 to 3.80
Well, I noticed a speed DECREASE in 3.69
I am about to upgrade my motherboard and I am looking for suggestions
on what the minimum horsepower needed to do = real-time encoding on
a AMD or a Cyrix systems. !(Intel inside)
What is the encoding process bounded by? I/O operations or
computational speed?
computational speed
Computational speed, and cache size seem to be the most important
Cache size and speed are the only important factor if you have cache misses,
and you own an Intel processor. Cache misses are _extremely_ expensive.
The P166 MMX and up have a better cache than the P133 and down. But my
lowly
R I can't remember, but I think there is a speed increase from
R 3.69 to 3.80
Yes there is. I made a more fast/efficient huffman coding.
but another coding change (for thread safe) vailed it...
Hmmm... I encoded the same song twice, with the same parameters and it was
encoded slower
Segher Oh, by the way, anyone interested in better DCT's?
I made faster mdct_long and sent it to Takehiro.
--
Naoki Shibata e-mail: [EMAIL PROTECTED]
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
I tried to compile Lame 3.80 beta using MSVC 6.0 on
Windows NT, with the included makefile.msvc. Two things
:
1. brhist.c includes "termcap.h", which does not
exist on the platform. Removing the include fixes it.
2.At link time, I get the following errors
:
main.obj : error LNK2001:
Hello Alberto,
Monday, May 08, 2000, 5:37:55 PM, you wrote:
AG By the way, LAME 3.80 puts a lot of "informative message" when
AG encoding (the file is reservoir.c), and I find it a little annoying.
AG Is this information useful? Is there any way to disable it? (apart from
AG commenting the
The ISO spec says that free format bitstreams are limited
to 320kbs, but lame will allow you to specify any bitrate over 8kbs.
(lame prints warnings when using freeformat)
According to my ISO doc (section 2.4.2.3), for layer III, decoders are not
required to support higher free format higher
Segher Oh, by the way, anyone interested in better DCT's?
Naoki I made faster mdct_long and sent it to Takehiro.
and it was merged to my tree.
maybe tomorrow, CVS tree will get it.
it's very swift :)
---
Takehiro TOMINAGA // may the source be with you!
--
MP3 ENCODER mailing list (
I tried to compile Lame 3.80 beta using MSVC 6.0 on Windows NT, with the
included makefile.msvc. Two things :
1. brhist.c includes "termcap.h", which does not exist on the platform.
Removing the include fixes it.
2. At link time, I get the following errors :
main.obj : error
What is the encoding process bounded by? I/O operations or
computational speed?
computational speed
On an embedded system with a K6-200 (without L2 cache!) and
gogo 2.31 there was still CPU power left for other things.
...which means you are *not* cpu bound.
My comment was
Hello Mark,
Monday, May 08, 2000, 9:37:38 PM, you wrote:
MT So lame3.81, which ignroes the 7680 bit buffer limitation will
MT be out in a few hours. If you dont like the "informative message"
MT try it out.
mmm... but lame3.81 was already released...
Best regards,
Dmitry
Hello Mark,
Monday, May 08, 2000, 9:37:38 PM, you wrote:
MT So lame3.81, which ignroes the 7680 bit buffer limitation will
MT be out in a few hours. If you dont like the "informative message"
MT try it out.
mmm... but lame3.81 was already released...
Best regards,
Dmitry
On Mon, 8 May 2000, Mark Taylor wrote:
[snip]
From discussions here, I think it is safe to remove this restriction
but make an option to turn it back on. I liked the one suggestion
of something hard to type like: "--strictly-enforce-ISO" :-)
[snip]
How about --iso-me-harder ?
--
MP3
Mark Taylor schrieb am Mon, 08 Mai 2000:
From discussions here, I think it is safe to remove this restriction
but make an option to turn it back on. I liked the one suggestion
of something hard to type like: "--strictly-enforce-ISO" :-)
I tested a couple of players and they didn't have
Mark Stier wrote:
-BEGIN PGP SIGNED MESSAGE-
Hello,
have you ever thought of setting up a distributed Genetic
Programming network which lets you optimize or even find algorithms
suitable for music/speech compression 'automatically'?
Maybe one could find algorithms that are
What do You recommend to me? Use the in_mp3.dll of v2.22?
I stand to use Winamp because is the most extended Mp3 player. But I accept
ideas.
George
- Original Message -
From: "David Balazic" [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Monday, May 08, 2000 9:55
OK, all mpg123 based players have trouble with such encoded files:
lame -b320 -h -mj t.wav t.mp3
resulting in lots of drop outs while playing back.
But not only mpg123 based ones like xmms have trouble,
freeamp doesn't like them too.
Maybe we have to force using stereo on
Hi, I found '-F' switch not working in LAME 3.80.
It's just a silly bug: in line 628 of parse.c the '=1' assingment
is missing.
By the way, I've just found a little sample where, after
enconding, there's a 48 kbps frame, and I used the '-b 96' setting
(without '-F'). Is
34 matches
Mail list logo
