[MP3 ENCODER] Re:

2000-10-05 Thread Albert Faber
Add the following proto-type just above the main() function int lame_decoder(lame_global_flags *gfp,FILE *outf,int skip); and you should be set Albert http://www.cdex.n3.net/ mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] - Original Message - From: "Nathan D. Blomquist" <[EMAIL PR

[MP3 ENCODER] Re: LAME 3.87 on freshmeat.net

2000-09-29 Thread jolan
That was written about a year ago by the authors not me.. I just notice the new versions & report them.. Submit the change to freshmeat or tell the lame guys to do it. peace, jolan On Sat, 30 Sep 2000, Takehiro Tominaga wrote: > Hello, jolan, from one of LAME developper. > > On the freshmeat.n

Re: [MP3 ENCODER] Re: 3.87b MMX and no MMX give different results + some 3.87 comments

2000-09-28 Thread Frank Baumgart
Dan Nelson wrote: > > In the last episode (Sep 28), Mark Powell said: > > BTW The gcc 2.95.2 options are perfectly valid for FreeBSD as well as > > Linux. Obviously :) Can they be copied into the FBSD section too? > > > > # these options for gcc-2.95.2 to produce fast code > > # CC_OPTS = \ > >

Re: [MP3 ENCODER] Re: 3.87b MMX and no MMX give different results+ some 3.87 comments

2000-09-28 Thread Mark Powell
On Wed, 27 Sep 2000, Dan Nelson wrote: > In the last episode (Sep 28), Mark Powell said: > > BTW The gcc 2.95.2 options are perfectly valid for FreeBSD as well as > > Linux. Obviously :) Can they be copied into the FBSD section too? > > > > # these options for gcc-2.95.2 to produce fast code > >

[MP3 ENCODER] Re: 3.87b MMX and no MMX give different results + some 3.87 comments

2000-09-27 Thread Dan Nelson
In the last episode (Sep 28), Mark Powell said: > BTW The gcc 2.95.2 options are perfectly valid for FreeBSD as well as > Linux. Obviously :) Can they be copied into the FBSD section too? > > # these options for gcc-2.95.2 to produce fast code > # CC_OPTS = \ > # -Wall -O9 -fomit-frame-po

[MP3 ENCODER] Re: problem with configure

2000-09-26 Thread Dan Nelson
In the last episode (Sep 26), Joshua Bahnsen said: > I don't have gtk-config on my system so when configure searches for > it it returns no like it should, but then it tries to run the program > "no", I assume to get the version # of gtk or something. So then in > the makefile HAVEGTK is defined e

Re: [MP3 ENCODER] Re: --voice

2000-09-15 Thread Gabriel Bouvigne
> I could not find the --voice page. is there a specific URL ?, - or which > section is it in ? > http://www.multimania.com/bouvigne/lame/voice.html -- Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3e

[MP3 ENCODER] Re: --voice

2000-09-14 Thread Eric Howgate
I could not find the --voice page. is there a specific URL ?, - or which section is it in ? Sorry to be a nuisance. Eric - Original Message - From: Gabriel Bouvigne To: [EMAIL PROTECTED] Sent: Tuesday, September 12, 2000 10:10 AM Subject: Re: [MP3 ENCODER] --voice --voice was made be

Re: [MP3 ENCODER] Re: MP3 Format

2000-09-10 Thread Frank Klemm
Presets: There are three blocks which can be selected via conditional compiling. Block 2: use low fs Block 3: do not use fsb21 if possible. Differences are: Block 2 Block phon+ (0...4 kHz) fs=8 kHzfs=11 kHz 700 KB 61

Re: [MP3 ENCODER] Re: MP3 Format

2000-09-09 Thread Robert Hegemann
Hallo Frank, > :: Als Du zu -mf und -mj den Bitverbrauch über mehrere Titel > :: verglichen hattest, so war LAME wahrscheinlich nicht mit > :: meinem extra Code RH_VALIDATE_MS übersetzt? Eigentlich > :: sollte nähmlich -mj weniger Bits verbraten als -mf. > :: > Die Korrelation heranzuziehen,

[MP3 ENCODER] Re: MP3 Format

2000-09-09 Thread Frank Klemm
Hallo Robert, :: :: > Kann man bei Layer III mehr Bits für das Differenzsignal als für das :: > Summensignal verbraten? :: :: Im Prinzip ja: :: * bei CBR hat Mark allerdings eine reduce_side() routine ::eingebaut die dem Differenzsignal immer weniger Bits ::zugesteht als dem Summe

[MP3 ENCODER] Re: Coding history report for each (non trivial) function

2000-09-05 Thread Dan Nelson
In the last episode (Sep 06), Frank Klemm said: > May be evry (non trival function should get a history header? > > /* > * Function: double sinc (IN double x); > * > * Purpose:calculates sin (pi x) / (pi x) > * > * Input: > * > * History: > *Person_1 2000-0

[MP3 ENCODER] Re: Message *bounced*

2000-08-27 Thread Dan Nelson
In the last episode (Aug 27), Guybrush Threepwood said: > At 09:01 PM 08/27/2000 +0100, you wrote: > >Erm, something screwy is happening to all my mail from this list. > >Here's a sample. Just started happening about 2-3 hours ago! Any > >ideas on what's going on? > > I'm getting the same problem

Re: [MP3 ENCODER] Re: Digital downsampling of mp3s?

2000-08-22 Thread Mark Taylor
> > In the last episode (Aug 22), Jaroslav Lukesh said: > > It should be maybe possible in wavelet transform, but not in discrete > > cosinus. You should wait for wavelet encoder and decoder... > > > > Or you should use ;-)) > > > > lame --decode x.mp3 - | mp3enc31 -sti -of x.small.mp3 -esr 22

[MP3 ENCODER] Re: Digital downsampling of mp3s?

2000-08-22 Thread Dan Nelson
In the last episode (Aug 22), Jaroslav Lukesh said: > It should be maybe possible in wavelet transform, but not in discrete > cosinus. You should wait for wavelet encoder and decoder... > > Or you should use ;-)) > > lame --decode x.mp3 - | mp3enc31 -sti -of x.small.mp3 -esr 22050 -qual 9 -bw 11

Re: [MP3 ENCODER] Re: [vorbis-dev] M/S encoding ?

2000-08-22 Thread Segher Boessenkool
> > From: Mark Taylor [mailto:[EMAIL PROTECTED]] > > > > MP3 does not allow mid/side stereo to be turned on and off on a band by > band basis (AAC does), > > Hmm, then what happens if a JS frame has both M/SS and IS enabled? In Layers > I and II, IS can be enabled across several fixed bands, I gu

RE: [MP3 ENCODER] Re: [vorbis-dev] M/S encoding ?

2000-08-22 Thread Mathew Hendry
> From: Mark Taylor [mailto:[EMAIL PROTECTED]] > > MP3 does not allow mid/side stereo to be turned on and off on a band by band basis (AAC does), Hmm, then what happens if a JS frame has both M/SS and IS enabled? In Layers I and II, IS can be enabled across several fixed bands, I guess something

[MP3 ENCODER] Re: RH_AMP Option

2000-08-22 Thread Keeshond
> If you make a "grep RH_AMP *.c" over all C-sources you will find out, > that it enables a different amp_scalefac_bands() in quantize.c and > makes a little psymodel tweak in psymodel.c. > > > Ciao Robert Thank you for your quick replay. Actually, most of the people might think 'thank you' mai

Re: [MP3 ENCODER] Re: Difficult examples, Lame fails, FhG not

2000-08-22 Thread Frank Klemm
:: >Another point: I notice you changed the encoding status display to :: >update every 2 seconds, rather than every 100 frames. Any reason for :: >this? I prefer 100 frames because I like looking and nice round :: >numbers, and it doesn't impact the speed. Also, to do the 2 second :: ::

Re: [MP3 ENCODER] Re: Difficult examples, Lame fails, FhG not

2000-08-21 Thread Robert Hegemann
Mark Taylor schrieb am Mon, 21 Aug 2000: > The -V option is scaled from 0=best to 9=worst because > originally, the value of 'n' was the number of bands for > which distortion was allowed to be > masking. > It is far too late to change this now! In my opinion you could think of it now as

Re: [MP3 ENCODER] Re: Difficult examples, Lame fails, FhG not

2000-08-21 Thread Robert Hegemann
Frank Klemm schrieb am Mon, 21 Aug 2000: > :: There are a lot of core dumps! > :: > Sorry. The results are not sooo bad. I switched to max quality via "-q 9". > "-q 9" seem to be not very good tested. in case of -q9, where we use no psy-model, some variables namely pe_MS[][] were not initiali

Re: [MP3 ENCODER] Re: Difficult examples, Lame fails, FhG not

2000-08-21 Thread Sigbjørn Skjæret
>Another point: I notice you changed the encoding status display to >update every 2 seconds, rather than every 100 frames. Any reason for >this? I prefer 100 frames because I like looking and nice round >numbers, and it doesn't impact the speed. Also, to do the 2 second I also noticed this, an

[MP3 ENCODER] Re: [vorbis-dev] M/S encoding ?

2000-08-21 Thread Mark Taylor
> Date: Mon, 21 Aug 2000 13:52:48 +0200 > From: David Balazic <[EMAIL PROTECTED]> > Content-type: text/plain; charset=iso-8859-2 > X-Accept-Language: en > Sender: [EMAIL PROTECTED] > Precedence: bulk > Reply-To: [EMAIL PROTECTED] > X-UIDL: V&"#!cKF!!#5S!!;+7"! > > Hi! > > I'm sending this messag

Re: [MP3 ENCODER] Re: Difficult examples, Lame fails, FhG not

2000-08-21 Thread Mark Taylor
> :: There are a lot of core dumps! > :: > Sorry. The results are not sooo bad. I switched to max quality via "-q 9". > "-q 9" seem to be not very good tested. > File is to be found in "http://www.uni-jena.de/~pfk/resample.tar.gz". > > Every Coder uses other command line switches with another

[MP3 ENCODER] Re: Difficult examples, Lame fails, FhG not

2000-08-21 Thread Frank Klemm
:: It's an example I found in my instrument directory. Several files from :: different sources (mostly Synth papers with CDs, i.e. Keys, Keyboards). :: :: On is the of a shaker. Lame fails, also at rates of 320 kbit/s. :: Lame 192 kbit/s sounds really bad. FhG (mp3encdemp31) is *much* better

[MP3 ENCODER] Re: About the Win32 Version Info

2000-08-15 Thread Nathan Blomquist
I am sorry, but I accidentally deleted the email about the Win32 Version resource. I was able to modify the source code (only added a file and changed the Makefile.MSVC) to enable win32 users to have a version tab in the properties page. Whoever wanted this I will be happy to email the new bina

[MP3 ENCODER] Re: you must include sourcecode when using GPL :(( ? (mpg123)

2000-08-10 Thread Takehiro Tominaga
> "M" == Monty <[EMAIL PROTECTED]> writes: >> are there precedents of an piece of GPL upgrading to LGPL? M> Sure! I changed all my own stuff from GPL to LGPL last year (I M> decided I mostly agreed with Bill Joy ;-). Send the author a M> letter; he may be willing. but it

[MP3 ENCODER] Re: 16-Bit DOS LAME Binaries

2000-08-09 Thread Dan Nelson
In the last episode (Aug 09), Nathan Blomquist said: > I was wondering if anyone would be or knows anyone who would be > interested in a 16-Bit DOS version of LAME? I have been able to > produce these by using a DOS extender called WDOSX. This allows > almost any Win32 console application to wor

Re: [MP3 ENCODER] Re: new psymodel / lame-0807-snapshot

2000-08-08 Thread Robert Hegemann
Takehiro Tominaga schrieb am Die, 08 Aug 2000: > > "R" == Robert Hegemann <[EMAIL PROTECTED]> writes: > > R> I just wanna let you know that it does not compile out of the > R> box mainly because your provided mathinline.h interferes with > R> the one installed in my Linux system.

Re: [MP3 ENCODER] Re: new psymodel / lame-0807-snapshot

2000-08-07 Thread Takehiro Tominaga
> "R" == Robert Hegemann <[EMAIL PROTECTED]> writes: R> I just wanna let you know that it does not compile out of the R> box mainly because your provided mathinline.h interferes with R> the one installed in my Linux system. umm,,, just remove the *MY* mathinline.h and delete the

[MP3 ENCODER] Re: new psymodel / lame-0807-snapshot

2000-08-07 Thread Robert Hegemann
Hi Takehiro! > Hi all, > > I just made my latest snapshot with a "whole new psymodel". > it uses always MAXNOISE and do not normalize the spread function. > and it always uses mixed block, subblock gain, scalefactor scale. > > The VBR mode of this code passes the "vbrtest.wav", and even more, >

[MP3 ENCODER] Re: "--nspsytune" really sounds (more than a fair amount) worse :-((

2000-08-07 Thread Roel VdB
Hello, RV> finding: "--nspsytune" sounds _a lot_ worse than the normal psymodel. RV> The graphs show a lower overall distortion amplitude, but there is RV> this noise that I can even clearly hear upto V1 (didn't test V0). I triple-checked this. Remember those noise graphs I made (original-decod

Re[2]: [MP3 ENCODER] Re: 3.86a, bug with -h ?

2000-08-07 Thread Roel VdB
Hello Mark, Sunday, August 06, 2000, 11:34:04 PM, you wrote: MT> I tend to agree with this, and I think we should disable MT> scalefac_scale for now (it can still be enabled with -q1 MT> for testing) after some re-consideration this seems wisest imo too. after some reports of -q1 producing poor

new psymodel (Re: [MP3 ENCODER] Re: 3.86a, bug with -h ?)

2000-08-06 Thread Takehiro Tominaga
Hi all, I just made my latest snapshot with a "whole new psymodel". it uses always MAXNOISE and do not normalize the spread function. and it always uses mixed block, subblock gain, scalefactor scale. The VBR mode of this code passes the "vbrtest.wav", and even more, the file size will be almost

Re: [MP3 ENCODER] Re: 3.86a, bug with -h ?

2000-08-06 Thread Mark Taylor
> > Robert Hegemann wrote: > >-h is always on by default if you use VBR modes like -v (default VBR mode), > >--vbr-old or --vbr-new. You can switch to a lower quality setting as -h > >(equals -q2) with -q3. But caution, the -q n switches are meant for internal > >testings only, they are not doc

Re: [MP3 ENCODER] Re: 3.86a, bug with -h ?

2000-08-04 Thread Robert Hegemann
Hi Gaby! > > For my ears, Takehiro's scalefac_scale feature will not give better > > results. > > The quality of many tracks is a little bit lower. I have found no > > tracks > > with better quality. The file size is reduced, but for my opinion, the > > quality is more important. So i think, sett

Re: [MP3 ENCODER] Re: 3.86a, bug with -h ?

2000-08-04 Thread Gabriel Bouvigne
> For my ears, Takehiro's scalefac_scale feature will not give better results. > The quality of many tracks is a little bit lower. I have found no tracks > with better quality. The file size is reduced, but for my opinion, the > quality is more important. So i think, setting this feature as defau

Re: [MP3 ENCODER] Re: 3.86a, bug with -h ?

2000-08-03 Thread ampex69
So, -q1 is theoretically the highest quality setting? What does it alter in 3.85? Begin Original Message From: Jack Davis <[EMAIL PROTECTED]> Sent: Thu, 03 Aug 2000 23:17:12 To: [EMAIL PROTECTED] Subject: [MP3 ENCODER] Re: 3.86a, bug with -h ? Robert Hegemann wrote: >-h is

[MP3 ENCODER] Re: 3.86a, bug with -h ?

2000-08-03 Thread Jack Davis
Robert Hegemann wrote: >-h is always on by default if you use VBR modes like -v (default VBR mode), >--vbr-old or --vbr-new. You can switch to a lower quality setting as -h >(equals -q2) with -q3. But caution, the -q n switches are meant for internal >testings only, they are not documented cos t

Re: [MP3 ENCODER] RE: Layer 2 vs Layer 3 (was RE: 2MP3 from cass

2000-07-30 Thread Bill Eldridge
A 4th factor (kind of related to the others) is that the chained CPU implementation generally means a greater delay for Layer 3, meaning in practice more than a 1/2 second delay - too much for doing a back-and-forth conversation, though often fine for one-way transfers. That's on equipment I had

Re: [MP3 ENCODER] RE: Layer 2 vs Layer 3 (was RE: 2MP3 from cass

2000-07-28 Thread mikecheng
On 28-Jul-2000 Bill Eldridge wrote: > I thought the biggest issue with Layer 2 vs. Layer 3 is that > Layer 2 holds together better over multiple generations. I agree with Bill here. Layer 2 survives re-encoding much better than Layer 3. Two other factors probably account for its widespread use

Re: [MP3 ENCODER] RE: Layer 2 vs Layer 3 (was RE: 2MP3 from cassette at LAME 3.85)

2000-07-28 Thread Bill Eldridge
> On MP2's allegedly higher quality than MP3 at high bitrates, I can hardly > ever tell the difference at such bitrates anyway. But looking at objective > measures, LAME @ 320kbit/s gives significantly lower noise than any MP2 > encoder I've seen, even at 384kbit/s. However, I don't have access to

[MP3 ENCODER] RE: Layer 2 vs Layer 3 (was RE: 2MP3 from cassette at LAME 3.85)

2000-07-28 Thread Mathew Hendry
> From: Jaroslav Lukesh [mailto:[EMAIL PROTECTED]] > > I put package for cooledit (it works > with cooledit > 2000, confirmed by friend) from syntrillium at our corporate web at > > www.k-net.cz/!/lossaud.zip (564k) > > Here are MP3 decoder, source, MP2 encoder and decoder, [...] Isn't

Re: [MP3 ENCODER] Re: Severe bug in lame (when using -k)

2000-07-25 Thread Robert Hegemann
Mark Taylor schrieb am Die, 25 Jul 2000: > -X: picks which of 7 algorithms will be used to determine if > one noise 'signature' sounds better than another. well, 0...7, seem to be 8 different ones ;-) > -X should now be considered a permanent option. -Y and -Z change > >from release to r

Re: [MP3 ENCODER] Re: Severe bug in lame (when using -k)

2000-07-25 Thread Arne Zellentin
Hi. On Tue, 25 Jul 2000, Mark Taylor wrote: >> >Thanks for finding this. This was a subtle & rare bug in CBR, >> >triggered by the -k option. >> Can you tell me when this bug was introduced? I listened to some of my recent >> encodings and found this blip in about every 20th track. >Were they al

Re[2]: [MP3 ENCODER] Re: Severe bug in lame (when using -k)

2000-07-25 Thread Roel VdB
Hello Mark, MT> I would guess it was introduced in 3.85: it requires a combination of MT> scalefac_scale (defaulted in 3.85, before that enabled with -Y ), and MT> not using enough low pass filtering for the amount of compression. If I believe the history log and my own tests, scalefac_scale was

Re: [MP3 ENCODER] Re: Severe bug in lame (when using -k)

2000-07-25 Thread Mark Taylor
> > >(-k, by the way, is *always* a bad idea. It overrides LAME's > >default lowpass filters. It will cause ringing and twinking > >at 128kbs) > > Are there examples for this? When I did some listening tests I noticed the > missing frequencies but nothing else. Does the FhG encoder still do th

Re: [MP3 ENCODER] Re: Severe bug in lame (when using -k)

2000-07-25 Thread Mark Taylor
> > Hi Mark, > > On Mon, 24 Jul 2000, Mark Taylor wrote: > >Thanks for finding this. This was a subtle & rare bug in CBR, > >triggered by the -k option. > > Can you tell me when this bug was introduced? I listened to some of my recent > encodings and found this blip in about every 20th track.

Re: [MP3 ENCODER] Re: Severe bug in lame (when using -k)

2000-07-25 Thread Abe Corrie
Just a quick question, when cdex refers to "high quality" that "may produce pinging" they are not using the -k option are they? Also this bug only applies to VBR right? Regards, Abe Corrie --- Arne Zellentin <[EMAIL PROTECTED]> wrote: > Hi Mark, > > On Mon, 24 Jul 2000, Mark Taylor wrote: > >Th

Re: [MP3 ENCODER] Re: Severe bug in lame (when using -k)

2000-07-25 Thread Arne Zellentin
Hi Mark, On Mon, 24 Jul 2000, Mark Taylor wrote: >Thanks for finding this. This was a subtle & rare bug in CBR, >triggered by the -k option. Can you tell me when this bug was introduced? I listened to some of my recent encodings and found this blip in about every 20th track. >(-k, by the way,

[MP3 ENCODER] Re: Severe bug in lame (when using -k)

2000-07-24 Thread Mark Taylor
Hi Arne, Thanks for finding this. This was a subtle & rare bug in CBR, triggered by the -k option. (-k, by the way, is *always* a bad idea. It overrides LAME's default lowpass filters. It will cause ringing and twinking at 128kbs) Note to developers and -X6 fans: The problem is in frame 232

[MP3 ENCODER] Re: zip#2

2000-07-19 Thread Roel VdB
Hello Mark, Wednesday, July 19, 2000, 5:14:31 PM, you wrote: MS> The site is dead for me also ... 768K DSL from Ohio USA. Murphy's law has MS> been strong this year. MS> mark stephens yes it seems. thanks for letting me know. So, this afternoon both sites are down. (1st time in 4 months) any

[MP3 ENCODER] Re FM

2000-07-14 Thread Eric.Howgate
Thanks to all who offered advice Eric -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )

Re: [MP3 ENCODER] Re: vorbis comment header patch

2000-07-10 Thread Don Melton
On Sun, Jul 09, 2000 at 03:40:29PM -0700, Ralph Giles wrote: > On Sun, 9 Jul 2000, Don Melton wrote: > > > Thanks. This fix is also in but in a slightly different way. I modifed > > the actual tagging routines in lame.c to check for Ogg Vorbis output > > rather than making the client code respo

Re: [MP3 ENCODER] Re: vorbis comment header patch

2000-07-09 Thread Ralph Giles
On Sun, 9 Jul 2000, Don Melton wrote: > Thanks. This fix is also in but in a slightly different way. I modifed > the actual tagging routines in lame.c to check for Ogg Vorbis output > rather than making the client code responsible, so we only have to do > the test in one place rather than in al

Re: [MP3 ENCODER] Re: vorbis comment header patch

2000-07-09 Thread Don Melton
Thanks. This fix is also in but in a slightly different way. I modifed the actual tagging routines in lame.c to check for Ogg Vorbis output rather than making the client code responsible, so we only have to do the test in one place rather than in all clients. On Fri, Jul 07, 2000 at 01:08:55AM

Re: [MP3 ENCODER] Re: vorbis comment header patch

2000-07-08 Thread Don Melton
OK, the patch (with several modifications) is in the CVS tree. On Thu, Jul 06, 2000 at 08:26:22PM -0700, Ralph Giles wrote: > On Thu, 6 Jul 2000, Don Melton wrote: > > > Cool! I didn't even think to add vorbis support when I landed the id3v2 > > stuff this week. Nice idea, Ralph! > > Thanks.

[MP3 ENCODER] Re: vorbis comment header patch

2000-07-07 Thread Ralph Giles
On Thu, 6 Jul 2000, Ralph Giles wrote: > Oops, on further investigation those 128 bytes are an id3 tag, so we > need an interlock of some sort. I'll take a look at this later. The attached patch should protect against id3 tags in ogg files. I now get a zero-length output file. -r -- [EMAIL P

[MP3 ENCODER] Re: vorbis comment header patch

2000-07-06 Thread Ralph Giles
On Thu, 6 Jul 2000, Don Melton wrote: > Cool! I didn't even think to add vorbis support when I landed the id3v2 > stuff this week. Nice idea, Ralph! Thanks. :-) > This is probably a stupid question, but are there docs online about the > comment header (he asks without even looking at the vor

[MP3 ENCODER] Re: Is Lame v3.85_ic 2 times faster than v.3.84_ic and v.3.70

2000-07-06 Thread Robert Hegemann
Hi Tonic! > >It looks like your LAME version 3.85 is an alpha version and not > >a released beta. In LAME we have currently two versions of VBR code: > >1 the "old" VBR code > >2 the "new" VBR code by Mark > > No this is beta I do not DL any alfa > I DL it on the day of release of 3,85 from rusi

[MP3 ENCODER] Re: legality (was: C++ LAME?)

2000-06-21 Thread Gabriel Bouvigne
> David Balazic wrote: > > > > Yeah , but what if someone in Germany wants to use it ? > > He can not , unless he breaks the law. > > Isn't that the same with LAME and even an MP3 decoder? All > you people using LAME in the US and Germany are currently > breaking the law :-). > > Erik If you only

Re: [MP3 ENCODER] Re: MP3 renaming/tagging util

2000-06-14 Thread Tilman Sauerbeck
> > I'm looking for a DOS/Win cmd line or even GUI util to do some or all > > of the following: you could also have a look at http://mp3renamer.de (it's english, too). This program (called MIR) has tons of features. Tilman -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )

[MP3 ENCODER] Re: MP3 renaming/tagging util

2000-06-12 Thread Dan Nelson
In the last episode (Jun 13), Dan Bridges said: > I'm looking for a DOS/Win cmd line or even GUI util to do some or all > of the following: > > Given: ARTIST_ -_ ALBUM_ -_ 01_ -_ TITLE.MP3 > use a cmd line like RENMP3 ARTIST_ -_ ALBUM_ -_ 01_ -_ TITLE.MP3 3 4 > to produce 01 - TITLE.MP3 or 0

Re: [MP3 ENCODER] Re: Vorbis (was Encode now or later?)

2000-06-07 Thread Gabriel Bouvigne
> > b: if using the pre-computed tree, the same codebook is always used? > > I'm not sure what you mean... The pre-computed tree is just an optimization to > shorten search time on a given codebook. Each codebook has a custom tree > generated for it. I was thinking that you were using a differen

Re: [MP3 ENCODER] Re: Vorbis (was Encode now or later?)

2000-06-07 Thread Monty
> Does that means that: > > a: if encoding time is not important, it should be possible to use a full > brute search > instead of the pre-computed tree? Yes. Brute forcing the LSP fit is the most beneficial part and actually not likely to increase encoding time a huge amount (not a factor of 2

[MP3 ENCODER] Re: Vorbis (was Encode now or later?)

2000-06-07 Thread Gabriel Bouvigne
> Specifically, Vorbis encodes its output using vector quantization; rather than > brute forcing the encoding process (by trying each of several hundred codeword > possibilities looking for closest fit), it uses a Monte-Carlo trained > partitioning tree to find best fit in a few comparisons rather

Re: [MP3 ENCODER] Re: Encode now or later?

2000-06-06 Thread Monty
> My first test of vorbis however was a bit disappointing. Testcase > was gspi*.wav from SQAM. It had a strange sounding tremolo > effect, but I consider vorbis still alpha. Perhaps something was > temporarly broken 8´\ Not temporarily broken, but you did get bit by a shortcoming already correct

[MP3 ENCODER] Re: Encode now or later?

2000-06-06 Thread Ingo Saitz
MoiN On Tue, Jun 06, 2000 at 10:30:36PM -0300, Leonardo Stern wrote: > But what about the player ??? > Anyone have a compiled vorbis encoder / player ? The xmms input plugin seems to work. After compilation just "cd xmms; make" and copy the lib*.so into /usr/lib/xmms/Input/. My first test of vo

Re: [MP3 ENCODER] Re: Cannot "make" LAME

2000-06-01 Thread Tilman Sauerbeck
> > Perhaps the makefile was modified when I decompressed it or somewhen else. > > But Make tells me this "separator" error which disappears when I insert > > tabs. And I am definately sure I use the cygWin "Make" because the djgpp > > make tells me a completely other bunch of error messages. > >

Re: [MP3 ENCODER] Re: Cannot "make" LAME

2000-06-01 Thread Tilman Sauerbeck
> Perhaps the makefile was modified when I decompressed it or somewhen else. > But Make tells me this "separator" error which disappears when I insert > tabs. And I am definately sure I use the cygWin "Make" because the djgpp > make tells me a completely other bunch of error messages. Now I got d

[MP3 ENCODER] Re: Cannot "make" LAME

2000-06-01 Thread Dan Nelson
In the last episode (Jun 01), Tilman Sauerbeck said: > > The Makefile should be correct as-is; you shouldn't have to fiddle with > > tabs. Try editing your path to only include the cygwin binary > > directory and run make again. > > Perhaps the makefile was modified when I decompressed it or som

Re: [MP3 ENCODER] Re: Cannot "make" LAME

2000-06-01 Thread Tilman Sauerbeck
> The Makefile should be correct as-is; you shouldn't have to fiddle with > tabs. Try editing your path to only include the cygwin binary > directory and run make again. Perhaps the makefile was modified when I decompressed it or somewhen else. But Make tells me this "separator" error which disa

Re: [MP3 ENCODER] Re: Cannot "make" LAME

2000-06-01 Thread Tilman Sauerbeck
> > Extraneous text after "ifeq" directive (this message appears for every > > "ifeq" in Makefile) > > and > > Missing separator (line 237) > I don't know what to say; I downloaded 3.70 myself and compiled it > without errors. Be sure that the "make" you're running is cygnus' > make, and not djg

Re: [MP3 ENCODER] Re: Cannot "make" LAME

2000-06-01 Thread Tilman Sauerbeck
> What version of cygwin, what version of Lame, and what errors do you > get? I just compiled the CVS version with cygwin 1.1 with no errors at > all. okay, thanks. I'll check my installation of CygWin (I'm new to this, perhaps I didn't setup CygWin correctly). Tilman -- MP3 ENCODER mailing li

[MP3 ENCODER] Re: Cannot "make" LAME

2000-05-31 Thread Dan Nelson
In the last episode (May 31), Tilman Sauerbeck said: > Hi everyone, > I just downloaded the LAME source code and tried to compile using the > CygWin software (CygWin is a port of the GNU tools to Windows). As > "make" failed when reading the makefile I wondered if you have to > make any changes to

[MP3 ENCODER] Re: -ouch-

2000-05-31 Thread Roel VdB
Hello r3mix.net, Wednesday, May 31, 2000, 1:40:37 PM, you wrote: rn> Hello , rn> Warning: Unable to connect to ORACLE (ORA-12154: TNS:could not resolve service name) in /usr/htdocs/mydomain-reds/index.php3 on line 241 rn> Fatal error: Call to unsupported or undefined function () in /usr/htdoc

[MP3 ENCODER] Re: lame-3.83beta

2000-05-29 Thread T.B.
Hello Kimmo, On 29-May-00, you wrote: > Usually the compiler (SAS/C at least) on m68k side can automatically check > and/or increase the stack size on the fly, if required and configured. But > I don't know if this works on PPC side or not. Anyone who knows better? I would prefer, if the User w

Re[2]: [MP3 ENCODER] Re: new scalefac_scale algorithm "-Z" - tested

2000-05-22 Thread Roel VdB
Hello Leonardo, Monday, May 22, 2000, 11:07:07 PM, you wrote: LS> How do you count frames of each bitrate ? LS> I want to do some stats myself (with diferentes settings and lame versions) LS> :o) win32: musicutter: http://macik.homepage.com click on mp3 file, and then "statistics - simple" >>

Re: [MP3 ENCODER] Re: new scalefac_scale algorithm "-Z" - tested

2000-05-22 Thread Leonardo Stern
How do you count frames of each bitrate ? I want to do some stats myself (with diferentes settings and lame versions) :o) > the stats about this: > > 3.80 > 32 - 0 - 0,0% > ||| 128 - 17066 - 54,1% > 160 -

Re[2]: [MP3 ENCODER] Re: Where did the VBR speed go?

2000-05-21 Thread Roel VdB
Hello Robert, Sunday, May 21, 2000, 9:05:19 PM, you wrote: RH> Hi Roel, RH> the speed drop in Version 3.83 is because of the noise calculation RH> in scalefactor band 21 (at 44.1 kHz samplerate it represents the RH> frequency range from 16 to 22.05 kHz). If there is some noise in that RH> scal

Re: [MP3 ENCODER] Re: new scalefac_scale algorithm "-Z" - tested

2000-05-21 Thread Roel VdB
Hello Takehiro, Sunday, May 21, 2000, 6:41:25 PM, you wrote: TT> I wrote; >>>I added a new scalefac_scale algorithm to CVS version of LAME, >>>which enables with -Y option. TT> Sorry, -Y option is used for Mark's new VBR routine TT> so I changed "new scalefactor_scale algorithm" from -Y to

Re: [MP3 ENCODER] Re: Where did the VBR speed go?

2000-05-21 Thread Robert Hegemann
Roel VdB schrieb am Son, 21 Mai 2000: > RV> To be clear, I don't mind, but am just curious: > RV> Lame 370 gave me 1.7 speed on my Cel400@450 (dkutsanov) > RV> Lame 383 gives me 1.0 speed on my Cel400@450 (dkutsanov) > RV> [Lame 384 -Z gave me 1.7 speed on my Cel400@450 (dkutsanov)] > > sorry sho

[MP3 ENCODER] Re: Where did the VBR speed go?

2000-05-21 Thread Roel VdB
RV> To be clear, I don't mind, but am just curious: RV> Lame 370 gave me 1.7 speed on my Cel400@450 (dkutsanov) RV> Lame 383 gives me 1.0 speed on my Cel400@450 (dkutsanov) RV> [Lame 384 -Z gave me 1.7 speed on my Cel400@450 (dkutsanov)] sorry should have been -Z : 0.7 speed :) -- Best regards,

[MP3 ENCODER] Re: new scalefac_scale algorithm

2000-05-21 Thread Takehiro Tominaga
I wrote; >>I added a new scalefac_scale algorithm to CVS version of LAME, >>which enables with -Y option. Sorry, -Y option is used for Mark's new VBR routine so I changed "new scalefactor_scale algorithm" from -Y to -Z option. --- Takehiro TOMINAGA // may the source be with you! -- MP3 ENC

[MP3 ENCODER] RE: mail list problems?

2000-05-21 Thread Ross Levis
Please ignore my previous message. I found the problem. Ross. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )

[MP3 ENCODER] Re: Encoding glitches with -mj

2000-05-16 Thread Ingo Saitz
MoiN On Tue, May 16, 2000 at 09:23:38PM +0200, Ingo Saitz wrote: > http://www.geocitites.de/brabanzu/BarbaraAnn.gz Hmm, well, it should have been written http://www.geocities.com/babanzu/BarbaraAnn.gz Ingo *ducks* -- I am the "ILOVEGNU" signature virus. Just copy me to your

RE: [MP3 ENCODER] Re: your mail

2000-05-14 Thread Ross Levis
Do you mean: what is EAC? It's a CD ripper. PAC is a Perceptual Audio Codec. Ross. Jeremy Hall wrote: > whatis pac? > > _J > > In the new year, [EMAIL PROTECTED] wrote: > > Why the lenght of the encoded music with LAME isn't the > same of the original > > track? EAC can detect the offset at

[MP3 ENCODER] Re: your mail

2000-05-14 Thread Jeremy Hall
whatis pac? _J In the new year, [EMAIL PROTECTED] wrote: > Why the lenght of the encoded music with LAME isn't the same of the original > track? EAC can detect the offset at the beginning of the track and fix it, but > the problem remains at the end of the file. Is it possible to correct this >

[MP3 ENCODER] RE: docs request

2000-05-10 Thread Alex Broadhead
Howdy, > -Original Message- > From: Adam Whitehead [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, May 10, 2000 6:14 AM > To: [EMAIL PROTECTED] > Subject: > Sorry for this not totally MP3-encoder-related mail, but I > was wondering > if anyone had some pointers to web sites, books etc. I

[MP3 ENCODER] Re: test

2000-05-07 Thread T.B.
Hello Jaroslav, try resubscribing. You should get a message then saying that you're already/still subscribed. Regards -- __ __ / / / / / / / / / / / / __ __ / / / / Better than ever! \ \ \ \/ / / / \ \ \/ / / / 730 kKeys RC5 (210MHz) \ \/

[MP3 ENCODER] Re: test

2000-05-07 Thread T.B.
Hello Jaroslav, On 05-May-00, you wrote: > All are killed by I-LOVE-YOU virus :-) The Amiga certainly not! Regards -- __ __ / / / / / / / / / / / / __ __ / / / / Better than ever! \ \ \ \/ / / / \ \ \/ / / / 730 kKeys RC5 (210MHz) \ \/ /

[MP3 ENCODER] Re: winamp quality

2000-04-29 Thread T.B.
Hello Pierre, On 28-Apr-00, you wrote: > I use WinAmp (2.62) to play my mp3 files encoded by lame (3.70), and I find it > rather bad. The mp3 files are not faulty, since they sound good with the > Windows Media Player. But Windows Media Player doesn't have playlists, so I'd > like to use WinAmp

[MP3 ENCODER] Re: best LAME options for high quality audio?

2000-04-27 Thread T.B.
Hello Shawn, On 25-Apr-00, you wrote: > reproduce them). I'm in serious doubt as to whether frequencies >13kHz really > contribute any musicality to the tracks on CDs. Wut? Then you obviously never heard of Heavy or Trash Metal, needs much Bandwidth or it will sound like a muffeled Sock. Or hav

Re: [MP3 ENCODER] Re: LAME370,380 BUG REPORT

2000-04-25 Thread Mark Taylor
> No, this is really a bug. I got bitten by it three or four times until > I just started using "- - < infile > outfile" to work around it. Like > this: > > $ ls -l infile.mp3 > -rw-rw-rw- 1 dan dan 2745849 Apr 20 20:48 infile.mp3 > $ lame -h -a -b3 2 infile.mp3 - > Could not find "2". > $

[MP3 ENCODER] Re: lame/mp3rtp produces skippy sound when encoding from stdin

2000-04-25 Thread Felix von Leitner
> Any ideas? Sorry, that was a mistake in the pipe, lame was innocent. Felix -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )

[MP3 ENCODER] Re: LAME370,380 BUG REPORT

2000-04-20 Thread Dan Nelson
In the last episode (Apr 20), Monty said: > > A bug report that arrived in my inbox - > > Seems like Mitya needs a "do not overwrite" mode. > > His shell already offers one, as does UNIX file permissions. Do we > really need... > > "Are you sure? [y/N] y" > > (Now if LAME is doing something pu

[MP3 ENCODER] Re: Lame vs Frau

2000-04-06 Thread Mark Taylor
Just to contrast with the last sample, here's another pre-echo related problem where LAME is reported to do better than FhG: Mark > From: [EMAIL PROTECTED] > Date: Thu, 6 Apr 2000 18:13:39 +0100 > Content-Type: text/plain; > charset="iso-8859-1" > X-UIDL: g"#"!cHY!!C+G!!6=`"! > > >

[MP3 ENCODER] Re: lame and patents

2000-02-06 Thread Mark Taylor
Here's something interesting about German patent law: --- Start of forwarded message --- Date: Thu, 3 Feb 2000 12:32:31 +0100 From: Patrick Goltzsch <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Subject: Re: lame and patents Though my original answer might be more c

Re: [MP3 ENCODER] Re: highq mode

2000-02-04 Thread Ross Levis
Actually you can extend a Win95/98 DOS window to 43 or 50 lines which then allows scrolling up. It is in the Properties/Screen tab. It doesn't completely help because there are more than 50 lines printed. It goes back as far as "--lowpass freq". I have the same problem. I have become rather s

RE: [MP3 ENCODER] Re: highq mode

2000-02-04 Thread Mark Stephens
. mark stephens -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Cavallo de Cavallis Sent: Friday, February 04, 2000 2:22 PM To: [EMAIL PROTECTED] Subject: Re: [MP3 ENCODER] Re: highq mode Wow what a f**kin useful remark !! so stop compiling lame for

  1   2   >