Re: Re[3]: [MP3 ENCODER] highq mode
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, especially for Windows where you cannon scroll up to see the beginning of the help. For Linux this is less important, because of the possibility to scroll up and down. Can windows users redirect stderr like us poor saps stuck using Free Software? Maybe he can try "lame 2 file.asc more file.asc". Well, it works here on OS/2 anyway. Dont know about Windows. Windows Command.com does not support stderr redirection AFAIK, but if you use 4DOS from JPSoftware you can write: Lame | more or better "Lame | List /s" -- Jose Mejuto http://www.cdngo.com CD Audio ripper compressor -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: Re: [MP3 ENCODER] highq mode
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, namely -quality 1 or -quality 9, whatever is decided, even if this makes lame run a little slower. I agree i dont think it could be so clever to switch the scale i use the DLL with ExactAudioCopy (www.exactaudiocopy.de) i cant think eac-coder can distribute a newer beta version everytime someone change the settings...(btw i still use CBR @160 hq) 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 Best regards, Cavallo de Cavallis [EMAIL PROTECTED] =-=--=--=--=--=--=--=--=--=--== = http://www.s0ftpj.org = = Digital Security for y2k = ==-=--=--=--=--=--=--=--=--=-== "Knowledge chases me, but i'm faster" "La Sapienza mi insegue, ma io sono piu' veloce" [Anonymous] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: Re[3]: [MP3 ENCODER] highq mode
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 very useful, especially for Windows where you cannon scroll up to see the beginning of the help. For Linux this is less important, because of the possibility to scroll up and down. Can windows users redirect stderr like us poor saps stuck using Free Software? -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: Re[3]: [MP3 ENCODER] highq mode
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 away" without seein the beginning of it Yes, that would be very useful, especially for Windows where you cannon scroll up to see the beginning of the help. For Linux this is less important, because of the possibility to scroll up and down. Can windows users redirect stderr like us poor saps stuck using Free Software? Maybe he can try "lame 2 file.asc more file.asc". Well, it works here on OS/2 anyway. Dont know about Windows. Paul -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: Re[3]: [MP3 ENCODER] highq mode
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 to Linux as my default boot if so many of my favourite toys weren't Windows-based. ;) 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 used to build the entire Mandrake distribution, I guess it's a pretty stable compiler now... -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: Re[3]: [MP3 ENCODER] highq mode
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 used to build the entire Mandrake distribution, I guess it's a pretty stable compiler now... I as well use pgcc (version 2.95.2) here on OS/2 with no noticable side-effects. Though when I tried compiling with -march=pentiumpro it generated MP3's with strange noises. -march=pentium produces normal mp3's though. So I guess it's not perfect :) Paul -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] highq mode
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 base is likely to explode soon. It would be good to get this sorted out ASAP. I still favour a reversed numbered approach rather than low/normal/high etc to enable far more flexibility in the future. -V3 -b160 -B320 when it might seem more obvious to do this: --vbr 192 --min 160 -max 320 I don't think this can work. Someone that always encodes classical music, for example, would find the average bitrate is nothing like someone who always encodes rock. It would be too confusing. For your example I still prefer "--vbr 6". My thoughts are wandering too far here but: it would be possible to use your format if the resulting average was forced to be close to the selected bitrate. This would take an extra dummy encoding pass through the file to establish which -V setting to use and then encode it. I suspect this would be possible but I don't know how useful it would be. Ross. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] highq mode
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" sound mp3s will now be horrid, and their horrid ones will sound great. A drop-in replacement for lame will do different things. I have no problems with adding new options, but changing existing options is a bit rough. For what it's worth, gogo uses higher numbers for better quality in VBR. That is IMHO another reason to do it that way. Felix -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] highq mode
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/mp3encoder/ )
Re: [MP3 ENCODER] highq mode
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 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 smallest possible bitrate. So I would not change the -V settings. Then change it's name to VNR. (n = noise) :) -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] highq mode
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 smallest possible bitrate. So I would not change the -V settings. We orignally used V to set the number of bands allowed to be 'over'. When we changed that, we should have V. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] highq mode
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/ )
Re: Re: [MP3 ENCODER] highq mode
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 = 0.01 : enables real filters (not yet) x = +inf : reserved for future tid bits Then we would have room for thousands of new features! Enough of that fun. I don't think that there will be so many new features we could add to LAME. And if there will be such a wonderful new thing, it will fit into one of our 0..9 scala. If, for one reason, it could not be used together with other settings, then there is the possibility to add an own switch for that. And, if people have the choice to select out of the range 0..100, most will say: "mmh, I don't know what to choose, maybe 100 will be good, or 30. Ok I take something inbetween. Yes 60." Robert -- Sent through Global Message Exchange - http://www.gmx.net -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] highq mode
-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 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 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 smallest possible bitrate. So I would not change the -V settings. Then change it's name to VNR. (n = noise) :) -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
RE: [MP3 ENCODER] highq mode
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://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] highq mode
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 the 10 levels are used, and that we have a new super-high-quality-fantastic-thing to add, using the current order, we'd have to add it on the 0th level, with the thing previously controlled by 0. Instead of this, using 9 as the highest setting, we could add a new level (ie 10 or more), remaining totally backward compatible with the options controlled by the switch. Just a personnal opinion... Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3tech.org (temporary down, alternative url is http://mp3tech.tsx.org ) -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] highq mode
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 lowest quality and 9 as the highest. This would allow some future extensions. If one day all the 10 levels are used, and that we have a new super-high-quality-fantastic-thing to add, using the current order, we'd have to add it on the 0th level, with the thing previously controlled by 0. Instead of this, using 9 as the highest setting, we could add a new level (ie 10 or more), remaining totally backward compatible with the options controlled by the switch. Just a personnal opinion... Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3tech.org (temporary down, alternative url is http://mp3tech.tsx.org ) -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
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://geek.rcc.se/mp3encoder/ )
RE: [MP3 ENCODER] highq mode
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: 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://geek.rcc.se/mp3encoder/ ) -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] highq mode
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 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 smallest possible bitrate. So I would not change the -V settings. Robert -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] highq mode
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: [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 release to another will find that their "great" sound mp3s will now be horrid, and their horrid ones will sound great. A drop-in replacement for lame will do different things. I have no problems with adding new options, but changing existing options is a bit rough. _J In the new year, Greg Maxwell wrote: 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/ ) -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] highq mode
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 numbers to denote bigger bitrate in VBR. 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 smallest possible bitrate. So I would not change the -V settings. Robert -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] highq mode
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 smallest possible bitrate. That makes sense now that you explain it. However I think that most users will think in terms of quality or filesize rather than in terms of noise. I think that larger numbers denoting higher quality will yield a more obvious user interface. Chris -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] highq mode
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, default and -h
modes.
highq=9enabled with -f (fast mode)
highq=5default
highq=2enabled with -h
A short description of all the options is in lame.h.
Some of the options are just things we have been talking about
and are not yet implemented:
filter_type=1 would turn on a true filter, rather than the current filter
which acts on the MDCT coefficients.
noise_shaping_stop=2 Iwasa's code to do a more thourough scalefactor search
use_best_huffman=2:use best_huffman code inside outer_loop.
from lame.c:
/* set internal feature flags. USER should not access these since
* some combinations will produce strange results */
if (gf.highq=9) {
/* 9 = worst quality */
gf.filter_type=0;
gf.quantization=0;
gf.psymodel=0;
gf.noise_shaping=0;
gf.noise_shaping_stop=0;
gf.ms_masking=0;
gf.use_best_huffman=0;
} else if (gf.highq=5) {
/* 5..8 quality, the default */
gf.filter_type=0;
gf.quantization=0;
gf.psymodel=1;
gf.noise_shaping=1;
gf.noise_shaping_stop=0;
gf.ms_masking=0;
gf.use_best_huffman=0;
} else if (gf.highq=2) {
/* 2..4 quality */
gf.filter_type=0;
gf.quantization=1;
gf.psymodel=1;
gf.noise_shaping=1;
gf.noise_shaping_stop=0;
gf.ms_masking=1;
gf.use_best_huffman=1;
} else {
/* 0..1 quality */
gf.filter_type=1; /* not yet coded */
gf.quantization=1;
gf.psymodel=1;
gf.noise_shaping=3; /* not yet coded */
gf.noise_shaping_stop=2; /* not yet coded */
gf.ms_masking=1;
gf.use_best_huffman=2; /* not yet coded */
exit(-99);
}
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] highq mode
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 quality? Seeing that 9 (low quality) contradicts the variable. -- Jeff Lightfoot --- jeffml at pobox.com --- http://thefoots.com/ === "I see the light at the end of the tunnel now ... someone please tell me it's not a train" -- Cracker -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] highq mode
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 quality? Seeing that 9 (low quality) contradicts the variable. -- Jeff Lightfoot --- jeffml at pobox.com --- http://thefoots.com/ === ok, i'll rename it right now. Mark -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
