[EMAIL PROTECTED] wrote:
>
> 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 'automatical
Gabriel> Winamp 2.6, new in-mpg123 for winamp, Nad 0.93, Sonique 1.51, AudioActive
Gabriel> 1.93b, K-Jofol 0.6, Digideck 0.82, Winplay3 2.3, ActiveMovie/MediaPlayer
Gabriel> 6.4, Xing MPEG player : all failed (quite disappointing)
Sorry, next version of in_mpg123 will support free format bitst
Mark Stier schrieb am Son, 07 Mai 2000:
> 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 even better t
Alberto García schrieb am Die, 09 Mai 2000:
> 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.
is fixed already in 3.81
>
> By the way, I've just found a little sample where, after
> enconding, the
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
Mark Taylor schrieb am Die, 09 Mai 2000:
> I was able to reproduce this, and it looks like it is not ISO buffer
> related (thankfully!). The side channel reduction algorithm which
> moves bits from the side channel to the mid channel, was letting the
> mid channel exceed 4095. (which is a limit
>
> 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 st
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
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 t
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 ha
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 ENC
>
> 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,
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 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
>
> > > 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
>
> 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 : e
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 (
here's the 3.80 doc
Regards,
Gabriel Bouvigne - France
[EMAIL PROTECTED]
icq: 12138873
MP3' Tech: www.mp3-tech.org
html.zip
> 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 hig
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 t
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:
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/ )
> 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 sl
> > 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
> > 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?
>
> comput
> > 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 DECREAS
On Sun, 7 May 2000, Mark Stier wrote:
> 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 even better than Frainhofe
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 i
> "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 PROTECTE
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:
> >
>
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 lik
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?
Hello Christian,
Monday, May 08, 2000, 11:06:47 AM, you wrote:
>> Mark wrote:
>>My understanding is that a licence would probably be required
>> to keep this project out of trouble if the patching was removed & Lame
>> really became an MP3 encoder. [...]
CS> What about the idea with the trial-ve
Allright, my (hopefully ;)) final word on my Pentium 133MHz bad MP3 encoding
performance... I just compiled the released 3.80 and it's slower (CBR) than
what I just encoded with 3.69, as you can see below:
Linux shell> lame -h track_07.wav
LAME version 3.80 (www.sulaco.org/mp3)
GPSYCHO: GPL psy
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
Shawn Riley wrote:
> So why would Nullsoft (or whoever it is) abandon Fraunhofer for Nitrane?
As others mentioned, they only used FHG's encoder for a short time while being sued.
I would say the main reason for switching back is the cost. The license requires a
payment to FHG for each MP3 pl
> > The ~0.3x I get on my Pentium 133Mhz is with -h and CBR, but my surprise
> Linux, gcc 2.95.2 compiled, Pentium 166 MMX (200MHz):
> duration 6:30, rate 0.9744
> Win95, Intel4.5 compiled, Pentium 166 MMX (200MHz):
> duration 6:47, rate 0.9345
> Win95, Intel4.5 compiled, Pentium 133:
> duration 1
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 b
> 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
> probably be required to keep this project out of trouble if the
> patching was removed & Lame really became an MP3 encoder. Wouldn't
> that defeat one of the main pur
> 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/ )
> 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 Null
This is the FhG plugin for WinAmp:
http://www.chat.ru/~dkutsanov/in_mp3.zip
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
>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 !
> Mark wrote:
> [...]
> 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 probably be required
> to keep this project out of trouble if the patching was removed & Lame
> really became an MP3 encoder. [...]
What about
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 t
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
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 me
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 ever
48 matches
Mail list logo
