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] LAME CRASHES / LAME in the PRESS
Thus spake Cavallo de Cavallis ([EMAIL PROTECTED]): 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 ?!? It is more difficult to hear the artifacts if you use higher bitrates. i.e. if you encode at 192, most people won't notice any difference between the encoders. I also used 112 and 128 and noted the results briefly, which were the same as for 96, only that all contenders sounded better. If you want to test encoders, use low bit rates. constant bitrate: Fraunhofer, lame, Xing, (long pause) bladeenc so blade is so shitty ? doh i have used it for a while, btw at 160, probably better than xing @128 i used before Comparing blade at 160 with Xing at 128 is like comparing warm pepsi to cold coke. Felix -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] sfBandIndex
Is the sfBandIndex Table B.8 messed up for MPEG2's lower frequencies? For long blocks the entries B.2.b (22.05kHz) are the same as for B.2.a (16kHz)! But the entries for short blocks differ. Robert -- Sent through Global Message Exchange - http://www.gmx.net -- 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] LAME CRASHES / LAME in the PRESS
Thus spake Don Melton ([EMAIL PROTECTED]): No, I didn't use higher bitrates. My rationale is that if you have the space for higher bitrates, you can also use Layer 2. I found recent Xing encoders not as bad as I expected from earlier Xing encoders, but if you use Xing, you use VBR, and the VBR mode in Xing is surprisingly good. Interesting. Did you try any apples vs. oranges comparison between the CBR and VBR samples? The CBR test should test the quality of the psychoacoustic model and bitrate allocation by encoding a very dynamic sound. Applause is a really evil kind of sound to encode because the left and right channels are different. I didn't constrain the bitrate for VBR. I expected encoders to allocate as much bitrate as needed to the applause part in the beginning and then use much less bitrate later on. The reason that I ask is that one of the whole points to VBR is higher quality through dynamic bit allocation over CBR with resulting file sizes and average bit rates that are similar. Anyway ... was VBR perceptually better than CBR in your test? Yes, lame and Xing hat no artifacts at all, but Fraunhofer was disappointing. They used no more than 160 kbps for the applause, which left audible artifacts, while lame and Xing used 224 and 256, respectively. By the way: has anyone of you noticed that mpg123 can't play lame encoded mp3s if they contain 320 kbps bitrates? Seems to be mpg123's fault, I'm going to complain to the author about it now ;) Felix -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] sfBandIndex
Is the sfBandIndex Table B.8 messed up for MPEG2's lower frequencies? For long blocks the entries B.2.b (22.05kHz) are the same as for B.2.a (16kHz)! But the entries for short blocks differ. A comparison between LAME's tables and MPGLIB's (mpg123) tables show a different value in Table B.2.c (24kHz) for long blocks LAME: ... 332 ... MPGLIB: ... 330 ... Robert -- Sent through Global Message Exchange - http://www.gmx.net -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: Re: [MP3 ENCODER] LAME CRASHES / LAME in the PRESS
Thus spake Robert Hegemann ([EMAIL PROTECTED]): By the way: has anyone of you noticed that mpg123 can't play lame encoded mp3s if they contain 320 kbps bitrates? Seems to be mpg123's fault, I'm going to complain to the author about it now ;) No, I haven't seen such faults. No problems with latest mpg123 (0.59r?) or xmms for me. Doesn't xmms use a different engine? I don't use xmms. I use mpg123 0.59r, too, and it repeatedly bombs on "-v -V 0" encoded songs. A friend of mine apparently likes -V 0 and he has had the same problems with mpg123, so it is not an isolated issue. 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/ )
Sv: [MP3 ENCODER] LAME CRASHES / LAME in the PRESS
constant bitrate: Fraunhofer, lame, Xing, (long pause) bladeenc so blade is so shitty ? doh i have used it for a while, btw at 160, probably better than xing @128 i used before Comparing blade at 160 with Xing at 128 is like comparing warm pepsi to cold coke. But isen't it a bit unfair to compare it at 96 when Blade always encode stereo with no band-21 cutoff, and no and all the others joint stereo with band-21 cutoff ? Peter -- 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: Re: Re: [MP3 ENCODER] LAME CRASHES / LAME in the PRESS
Doesn't xmms use a different engine? I don't use xmms. I use mpg123 0.59r, too, and it repeatedly bombs on "-v -V 0" encoded songs. A friend of mine apparently likes -V 0 and he has had the same problems with mpg123, so it is not an isolated issue. Felix That sounds strange. What version of Lame are you using exactly? One of the beta snapshots or CVS (date)? 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: Re: [MP3 ENCODER] LAME CRASHES / LAME in the PRESS
also mpg123 seems to not like catching a stream from stdin. The only way this works is if mpg123 gets a frame on stdin with nothing else before it, like a partial frame. If the encoding changes, like say if it wanted to change from 128k to 256k, mpg123 simply ignores the frames. so if mpg123 decides that it is receiving some kind of frame that it really isn't, it is necessary to restart mpg123 and hope it will sync up with the stream properly. _J In the new year, Felix von Leitner wrote: Thus spake Robert Hegemann ([EMAIL PROTECTED]): By the way: has anyone of you noticed that mpg123 can't play lame encoded mp3s if they contain 320 kbps bitrates? Seems to be mpg123's fault, I'm going to complain to the author about it now ;) No, I haven't seen such faults. No problems with latest mpg123 (0.59r?) or xmms for me. Doesn't xmms use a different engine? I don't use xmms. I use mpg123 0.59r, too, and it repeatedly bombs on "-v -V 0" encoded songs. A friend of mine apparently likes -V 0 and he has had the same problems with mpg123, so it is not an isolated issue. Felix -- 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: Re: [MP3 ENCODER] LAME CRASHES / LAME in the PRESS
also mpg123 seems to not like catching a stream from stdin. The only way this works is if mpg123 gets a frame on stdin with nothing else before it, like a partial frame. If the encoding changes, like say if it wanted to change from 128k to 256k, mpg123 simply ignores the frames. so if mpg123 decides that it is receiving some kind of frame that it really isn't, it is necessary to restart mpg123 and hope it will sync up with the stream properly. I have used mpg123 in stdin mode with my stupid RTP-to-stdout receiver on VBR streams successfully, so my experiences differ on this. Felix -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: Re: [MP3 ENCODER] LAME CRASHES / LAME in the PRESS
Your rtp thing probably encodes one frame per packet. My little utility grabs 1k of data and transmits it. _J In the new year, Felix von Leitner wrote: also mpg123 seems to not like catching a stream from stdin. The only way this works is if mpg123 gets a frame on stdin with nothing else before it, like a partial frame. If the encoding changes, like say if it wanted to change from 128k to 256k, mpg123 simply ignores the frames. so if mpg123 decides that it is receiving some kind of frame that it really isn't, it is necessary to restart mpg123 and hope it will sync up with the stream properly. I have used mpg123 in stdin mode with my stupid RTP-to-stdout receiver on VBR streams successfully, so my experiences differ on this. Felix -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
AW: [MP3 ENCODER] LAME CRASHES / LAME in the PRESS
I used the default settings for all encoders in the constant bitrate test. Actually, there are not many knobs for the Fraunhofer codec c't gave me (the one in MusicMatch). I don't like the Fraunhofer codec very much for music. It is excellent for speech, but it makes music sound flat. Well, I didn't look at the frames that Fraunhofer generated. I think that that should not be a criterion. It is perceptual audio compression, so it should only be judged by the perception of the listener. And the perception was that the applause part did not get enough bandwidth from Fraunhofer in VBR mode. lame and Xing are much more aggressive in the bandwidth distribution. Let me butt in at this point: Maybe you should have a look on the new Fraunhofer plugin, as used in Nero. It's very aggressively using higher bit rates in VBR (96...200 in medium quality setting, avg. about 140) and runs 8-10 faster that real time on a current CPU. The results in my opinion are brilliant. I've used Lame a lot in the meantime (mostly w. 128 and medium VBR setting) because the old (maybe v.1) Fraunhofer in the Audioactive Production Studio I had, would eventually ignore complex sounds completely and generate strong shortwave effects. I can hardly hear a difference between Lame and the new Fraunhofer, only the latter is faster (ripping and encoding together, still 6.5x on my machine). I'm not surprised at all about your tests, where 'audiophiles' couldn't tell MP3 from PCM. Psychoacoustics are often more psycho than acoustic ;-) I often catched myself unintentionally turning an AB comparison test into a double blind test because I was confusing the MP3 w. the PCM after switching forth and back several times, and was completely convinced I had heard some artifacts (but in the PCM!). Regards Rolf -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] LAME in the PRESS
I believe the fraunhofer codec in the new Musicmatch is identical to the one in Nero. I also remember reading that the new fraunhofer hi speed VBR is very shabby quality compared to the older versions. I would like to weigh in on the side of leaving VBR settings alone. LAME is different and better :) Personally, I use LAME 160 stereo for all my encodes, fast and sounds great to me. IS Xing VBR really considered good? I can hear artifacts in VBR normal/HQ simple stereo right away, and I am not very demanding. Indigo Girls, Swamp Ophelia, Song #8, Mystery. The voices warble and it is very noticeable to me. LAME 160 has no problem at all. Has anyone ever really done a good double blind test comparing Xing VBR -- Fraunhofer VBR -- LAME VBR? mark stephens - Original Message - From: "Rolf Hanich" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, February 02, 2000 7:33 PM Subject: AW: [MP3 ENCODER] LAME CRASHES / LAME in the PRESS Let me butt in at this point: Maybe you should have a look on the new Fraunhofer plugin, as used in Nero. It's very aggressively using higher bit rates in VBR (96...200 in medium quality setting, avg. about 140) and runs 8-10 faster that real time on a current CPU. The results in my opinion are brilliant. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
