> 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
> I wrote that article ;)
Oh oh ^_^
> I took a few "hard to encode" samples and had the contenders encode them
> at 96 kbps. The most prominent sample was from a live CD of Herbert
> Grönemeyer, basically lots of applause.
Sorry but why did u use 96 ?!?
Most of normal dudes around use 128 while
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
I would like to voice my opinion in support for 0=low 9=high. However,
reversing the numbers would make -V4 change to -V5 so the default setting
will have to reflect this.
Ross.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Greg Maxwell
Sent: Wednesda
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
I also think 9 for high and 0 for low is a more natural. Lame has a lot of
options, so whoever uses it
would know to use it correctly or at least check the usage file. Besides, it
seems to me that lame is al about change.
- Original Message -
From: Jeremy Hall <[EMAIL PROTECTED]>
To: <[E
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
On Tue, Feb 01, 2000 at 12:30:17PM +0100, Felix von Leitner wrote:
> Thus spake Don Melton ([EMAIL PROTECTED]):
> > > constant bitrate:
> > > Fraunhofer, lame, Xing, (long pause) bladeenc
> > Did you do any testing at higher bit rates as well? I'd be curious what
> > the results would be at
Thus spake Don Melton ([EMAIL PROTECTED]):
> > constant bitrate:
> > Fraunhofer, lame, Xing, (long pause) bladeenc
> Did you do any testing at higher bit rates as well? I'd be curious what
> the results would be at 160 or 192. (My wife, who has hearing a tall
> dog would envy, can pick out
13 matches
Mail list logo
