I cleaned up the highq mode, and implemented what was suggesting
in the mailing list last week.
The variable highq is now used to set verious internal options. Valid
ranges are 0(high quality) ... 9(low quality), but only 3 values are
really working right now, which coorespond do the -f, defau
> As the voice of reason (as a user), why highq instead of quality?
>
> Seeing that 9 (low quality) contradicts the variable.
I would suggest something before the 3.62 is out on the website:
Using 0 as the lowest quality and 9 as the highest. This would allow some
future extensions. If one day al
but then you're in conflict with VBR.
_J
In the new year, Gabriel Bouvigne wrote:
> > As the voice of reason (as a user), why highq instead of quality?
> >
> > Seeing that 9 (low quality) contradicts the variable.
>
> I would suggest something before the 3.62 is out on the website:
> Using 0 as
On Tue, 1 Feb 2000, Jeremy Hall wrote:
> but then you're in conflict with VBR.
VBR should be changed. It makes more sence for big numbers to denote
bigger bitrate in VBR.
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
I disagree. From a functional standpoint, changing an option to cause it
to do the exact opposite of what it once did is confusing at best, and
disrupts expected behavior. People upgrading from one release to another
will find that their "great" sound mp3s will now be horrid, and their
horrid on
: Wednesday, 2 February 2000 09:51
To: [EMAIL PROTECTED]
Subject: Re: [MP3 ENCODER] highq mode
On Tue, 1 Feb 2000, Jeremy Hall wrote:
> but then you're in conflict with VBR.
VBR should be changed. It makes more sence for big numbers to denote
bigger bitrate in VBR.
--
MP3 ENCODER mailing lis
Greg Maxwell schrieb am Die, 01 Feb 2000:
> On Tue, 1 Feb 2000, Jeremy Hall wrote:
>
> > but then you're in conflict with VBR.
>
> VBR should be changed. It makes more sence for big numbers to denote
> bigger bitrate in VBR.
Well, in my opinion -V reflects the following behaviour:
-V0:allow
gt;
To: <[EMAIL PROTECTED]>
Sent: Tuesday, February 01, 2000 11:34 PM
Subject: Re: [MP3 ENCODER] highq mode
> I disagree. From a functional standpoint, changing an option to cause it
> to do the exact opposite of what it once did is confusing at best, and
> disrupts expected behavi
ok, and so that -H is consistent with -V, make it do likewise.
_J
In the new year, Robert Hegemann wrote:
> Greg Maxwell schrieb am Die, 01 Feb 2000:
> > On Tue, 1 Feb 2000, Jeremy Hall wrote:
> >
> > > but then you're in conflict with VBR.
> >
> > VBR should be changed. It makes more sence fo
On Wed, 2 Feb 2000, Robert Hegemann wrote:
>
> Well, in my opinion -V reflects the following behaviour:
> -V0: allow low amount of noise
> :
> -V4: allow mid amount of noise
> :
> -V9: allow large amount of noise
>
> That's it what VBR does, allocate as much noise
> as allowed to achieve t
Yes, please don't change the current set of options. Rename "lame" if
you do something that drastic. :-)
Instead, perhaps we could migrate to a new set of options that is easier
for novices to understand at the command line. Then we could slowly
deprecate the options we have now. This could be
Don Melton wrote:
> --qual low equivalent to highq=9
> --qual normal " " " 5
> --qual high " " " 2
The idea to create secondary options may be a good way to avoid confusion.
LAME is starting to take off as a quality encoder so the us
Thus spake Jeremy Hall ([EMAIL PROTECTED]):
> I disagree. From a functional standpoint, changing an option to cause it
> to do the exact opposite of what it once did is confusing at best, and
> disrupts expected behavior. People upgrading from one release to another
> will find that their "great
On Tue, 1 Feb 2000, Jeremy Hall wrote:
> I have no problems with adding new options, but changing existing options
> is a bit rough.
Hmm.. I was still in the VBR is beta mindset. This is unfortunate, as the
current situation is not very intutive.
--
MP3 ENCODER mailing list ( http://geek.rcc.se
On Wed, 2 Feb 2000, Robert Hegemann wrote:
> Greg Maxwell schrieb am Die, 01 Feb 2000:
> > On Tue, 1 Feb 2000, Jeremy Hall wrote:
> >
> > > but then you're in conflict with VBR.
> >
> > VBR should be changed. It makes more sence for big numbers to denote
> > bigger bitrate in VBR.
>
> Well, in
On Wed, 2 Feb 2000, Robert Hegemann wrote:
> Well, in my opinion -V reflects the following behaviour:
> -V0: allow low amount of noise
> :
> -V4: allow mid amount of noise
> :
> -V9: allow large amount of noise
>
> That's it what VBR does, allocate as much noise
> as allowed to achieve the
Oops, I said that with gogo the VBR setting was higher -> more quality.
This is apparently wrong. The latest version uses a newer lame engine
and thus has the same meaning for that switch as lame.
Sorry!
Felix
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
-H 0 : run as slow as possible
-H 9 : run as fast as possible
_J
In the new year, Greg Maxwell wrote:
> On Wed, 2 Feb 2000, Robert Hegemann wrote:
>
> > Greg Maxwell schrieb am Die, 01 Feb 2000:
> > > On Tue, 1 Feb 2000, Jeremy Hall wrote:
> > >
> > > > but then you're in conflict with VBR.
>
not for stdin/stdout it wouldn't be useful.
_J
In the new year, Ross Levis wrote:
> Don Melton wrote:
>
> > --qual low equivalent to highq=9
> > --qual normal " " " 5
> > --qual high " " " 2
>
> The idea to create secondary options
Jeremy Hall wrote:
>ok, and so that -H is consistent with -V, make it do likewise.
But as Gabriel Bouvigne argued, you are limiting best quality to the lowest
number available -- 0. What do you do if a better quality mode is created?
Go negative? :)
Ross.
--
MP3 ENCODER mailing list ( http://ge
On Wed, 2 Feb 2000, Ross Levis wrote:
> But as Gabriel Bouvigne argued, you are limiting best quality to the lowest
> number available -- 0. What do you do if a better quality mode is created?
> Go negative? :)
Shift them all up. Newer lames will be a bit slower for people not taking
the best q
Mark Taylor wrote:
> The variable highq is now used to set verious internal options. Valid
> ranges are 0(high quality) ... 9(low quality), but only 3 values are
> really working right now, which coorespond do the -f, default and -h
> modes.
As the voice of reason (as a user), why highq instead
>
> Mark Taylor wrote:
> > The variable highq is now used to set verious internal options. Valid
> > ranges are 0(high quality) ... 9(low quality), but only 3 values are
> > really working right now, which coorespond do the -f, default and -h
> > modes.
>
> As the voice of reason (as a user),
> We orignally used V to set the number of bands allowed to be 'over'.
> When
> we changed that, we should have V.
Why? Only to confuse users?
And the idea of V hasn't changed.
btw, what about a "-h x" setting with x in R?
x = -inf : nothing but speed counts
x = 0: best quality we can do now
On Wed, 2 Feb 2000, Robert Hegemann wrote:
> > We orignally used V to set the number of bands allowed to be 'over'.
> > When
> > we changed that, we should have V.
>
> Why? Only to confuse users?
> And the idea of V hasn't changed.
But it's meaning did change. V used to mean: The number of scal
Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Robert Hegemann
Sent: Wednesday, February 02, 2000 8:15 AM
To: [EMAIL PROTECTED]
Subject: Re: Re: [MP3 ENCODER] highq mode
> We orignally used V to set the number of bands allowed to be 'over'.
> When
>
> People will select
> the quality based not on what features are enabled/disabled
> (which is unimportant, really) but on what their perceived
> gain will be:
> 0 = lowest quality, regardless of actual implementation
> 9 = highest quality
> If we add something that improves quality over the curre
>
> Exactly! That's the first really sensible thing I've heard on this subject.
> If quality improves dramaticly, it should not be activated with a -quality 10
> or actually, a -quality 0, but the better quality should be provided using
> the same 'use best quality' setting from previous versions
Hello,
> oh one stupid suggestion for the stand alone executable : it could be a good idea to
>allow
> "| more" or "/page" or "> file.asc" to see the command help, now it "goes away"
>without seein
> the beginning of it
Yes, that would be very useful, especially for Windows where you
cannon scr
On Thu, 3 Feb 2000, Joerg Hevers wrote:
> Hello,
>
> > oh one stupid suggestion for the stand alone executable : it could be a good idea
>to allow
> > "| more" or "/page" or "> file.asc" to see the command help, now it "goes away"
>without seein
> > the beginning of it
> Yes, that would be ver
On Thu, 3 Feb 2000 17:48:15 -0500 (EST), Greg Maxwell wrote:
>On Thu, 3 Feb 2000, Joerg Hevers wrote:
>
>> Hello,
>>
>> > oh one stupid suggestion for the stand alone executable : it could be a good idea
>to allow
>> > "| more" or "/page" or "> file.asc" to see the command help, now it "goes aw
> From: "Greg Maxwell" <[EMAIL PROTECTED]>
>
> Can windows users redirect stderr like us poor saps stuck using Free
> Software?
9x users can't. NT users can; and the NT console has scrollback anyway.
I'm currently running a triple boot system (Linux, Win98, Win2k). I might be
tempted to switch t
> > oh one stupid suggestion for the stand alone executable : it could be a good idea
>to allow
> > "| more" or "/page" or "> file.asc" to see the command help, now it "goes away"
>without seein
> > the beginning of it
Learn your shell; the output is going to stderr, not stdout. You're only
On Thu, 3 Feb 2000 23:39:10 -, Mathew Hendry wrote:
>BTW, the Linux distribution I have (Mandrake 6.x) uses pgcc (a
>Pentium-specific branch of gcc) as its default compiler. Gives a noticable
>speed improvement for LAME, and I haven't noticed any glitches with it.
>Since pgcc was apparently u
At 17:13 03/02/00 -0600, you wrote:
>>> > oh one stupid suggestion for the stand alone executable : it could be a
>good idea to allow
>>> > "| more" or "/page" or "> file.asc" to see the command help, now it
>"goes away" without seein
>>> > the beginning of it
>>> Yes, that would be very useful
35 matches
Mail list logo
