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,
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 user
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 (
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 my opinion -V
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/ )
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
x
-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.
VBR
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 (
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 all
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 the
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/ )
: 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 list ( http
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 low
]
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 behavior. People upgrading from one
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 for big
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
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 of
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
20 matches
Mail list logo