Re: Re[2]: [MP3 ENCODER] MS switching
This point is debatable. I am in the clan of the people using -B 256, and here is why: I choosed to keep strict ISO compatibility (--strictly-enforce-iso), because if in the future I use an hardware player, I would be worried to have some of my mp3 becoming unplayable. The ISO standard specifies a strict limit for the data size (btw this limit was choosed too low in the standard) so 320k frames can't use the bit reservoir, and if there were some available bits in the reservoir, if a 320k frame is used, the reservoir is definitely wasted. As I don't want to have too much unused space in my files, I choosed to use -B 256, even if I might be sacrifying a little of quality. The 4 examples I brought were POSSIBLE information you have after coding a PCM file. These are possible scenarios after you have coding files. You've tried to do your very best and you see after coding it wasn't. Real world examples and exercises: After coding with -V0 you got: Frame | CPU time/estim | REAL time/estim | play/CPU | remain 8453/8453 (100%)|6:54/6:54|6:55/6:55| 0.5325x|0:00 32 [ 2%] 40 [ ] 48 [ ] 56 [ ] 64 [ 0%]* 80 [ 0%]* 96 [ 0%]* 112 [ 1%]* 128 [ 1%]*** 160 [ 7%] 192 [32%]** 224 [29%]** 256 [15%]* 320 [12%]*** average: 219.0 kbps Calculate the file increase for the options '-b160', '-b192' and '-b192 -F'. Is this tolerable? What to you expect about coding quality? Frame | CPU time/estim | REAL time/estim | play/CPU | remain 8453/8453 (100%)|7:44/7:45|7:45/7:45| 0.4749x|0:00 32 [ 2%] 40 [ ] 48 [ ] 56 [ 0%]* 64 [ 0%]* 80 [ 0%]* 96 [ 1%]*** 112 [ 9%]*** 128 [18%]** 160 [30%]** 192 [22%] 224 [10%]** 256 [ 4%]*** 320 [ 3%]** average: 169.0 kbps Calculate the file increase for the options '-b112', '-b128' and '-b128 -F'. Is this tolerable? What to you expect about coding quality? In the past, when Lame was using strict iso, because of this reason the default for -V1 was -B 256. The Xing vbr encoder also limit up to 256k frames in order to not waste bits. (I don't know about the FhG vbr). FhG forces 48 kHz on 320 kbps. Maybe to bring the bits/granule ratio to the right place. Also I extended the brhist function to display percentages between 0.05 and 1 more accurate. [%.5] Can be read as 5 %. (%. = parts per thousand) or as .5 % = 0.5 % -- Frank Klemm -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: Re[4]: [MP3 ENCODER] MS switching
On Mon, Sep 11, 2000 at 07:12:24PM +0200, Robert Hegemann wrote: ISO says maximum buffer size is 7680 bit: kHz kbps bpf wasted -- 856 8064384 11.02580°) 8359679 1280°) 7680 0 16 112 8064384 22.05160 8359679 24 160 7680 0 32 224 8064384 44.1 320 8359679 48 320 7680 0 -- kHz kilo Hertz kbps kilo bits per second bpf bits per frame That's why FhG switches to 48 kHz on 320 kbps. But: A lot of players and soundcards have problems with 48 kHz Upsampling of lame is worse (downsampling is good, but not very good) -- Frank Klemm -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re[2]: [MP3 ENCODER] MS switching
Hello Frank, Sunday, September 10, 2000, 11:38:40 PM, you wrote: FK This model is much better than the hard switch to forced LR frames. I agree that JS has benefits. Big issue was what your criterium will be. FK Currently there is a lot of music out there where 160 kbps with default FK settings has the same or less quality than 128 kbps. Ditto 192 sounding poorer than 128. Mostly high-queeling artifacts due to JS. FK The 160 coding suffers from the lack of MS frames. Stereo separation is a FK little bit better than the 128 coding, but there are a little bit more FK distortions. The 160j coding sounds not perfect, but a lot better. Try the Velvet track on http://r3mix.50g.com . Try 192S VS 192JS. There S sounds acceptable, while JS totally messes up. You see? you find some cases of the one, I some of the other. There simply is not too much logic in this. I agree that something could be done to the JS issue, but while you try to tweak current criterium for case A, it'll worsen for case B and loose generality. Simply encode both the MS as RL frames, and measure afterward which one introduces least artifacts. I think measuring distortion like VBR does is a good way to start. It would be a general approach for all bitrates, for all music pieces for cbr96, cbr256, vbr9 and vbr1. If you work with static extra leniences, it would work for some pieces on the bitrate you had in mind, but for example it would be worthless for someone using -V9. what is the use of sacrificing kbits in trade for assumed quality gains? There will always be pieces where even -mS 100 will not be enough, and you loose a lot of the use of JS. FK Currently we have total loss of the advantage of MS for bitrates 128 kbps, FK even on digital mono files (L and R are 100% identically). I don't understand how you can conclude that? FK Pro/Cons LR: FK + more constant and predictable bitrate than MS FK - often higher bit rate demand than MS yep FK Pro/Cons MS: FK + often lower bit rate than LR FK - very unpredictable and varying bitrate, so sometimes you FK must switch to LR which it doens't at the moment. It says: MS nomather what if criterium ok. (FK - switching artefacts) want to see more on this. FK The best parameter you know after coding, for instance: FK OptionAdditional Info after coding FK -b256 * nevertheless use MS, there are nearly no problems with MS, mask and FK signal correlation is high, so NMR can be increased by "-mj" I disagree. Once I saw what JS could do to 192, I stopped advicing people to use JS on 256. It's supposed to be ok, and the current JS model, nor what you suggest, has no way of guaranteeing it will sound better than S. FK -b128 * use LR, there is nearly no advantage of MS frames, only low FK signal correlation, masks are often very different, reduce FK upper frequency limit from 15 kHz to 14 kHz ? I quote: FK Currently we have total loss of the advantage of MS for bitrates 128 kbps, FK even on digital mono files (L and R are 100% identically). ? sounds contradictive to me. I for one believe MS usage can be beneficial in _all_ cases, yet there needs to be a check if it didn't hurt quality afterward. If you could get the encoder pick the best out of LR or MS, both our problems would be solved. FK -V0 * file size is increased by 1.2% by setting -b128, so use this option FK * only two frames are 320 kbps, so also use -B256 to avoid problems FK with some players I am fundamentally agains crippling an encoder to fit the needs of an inept decoder. If 320 is chosen by LAME on -V1, it is there for a reason! Or you try to archive using mp3 = best quality, no compromises, use VBR for size benefit Or you want to have a practical size file for a portable player or so = do whatever you want, even take WMA@64 -- Best regards, Roelmailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: Re[2]: [MP3 ENCODER] MS switching
FK -V0 * file size is increased by 1.2% by setting -b128, so use this option FK * only two frames are 320 kbps, so also use -B256 to avoid problems FK with some players I am fundamentally agains crippling an encoder to fit the needs of an inept decoder. If 320 is chosen by LAME on -V1, it is there for a reason! This point is debatable. I am in the clan of the people using -B 256, and here is why: I choosed to keep strict ISO compatibility (--strictly-enforce-iso), because if in the future I use an hardware player, I would be worried to have some of my mp3 becoming unplayable. The ISO standard specifies a strict limit for the data size (btw this limit was choosed too low in the standard) so 320k frames can't use the bit reservoir, and if there were some available bits in the reservoir, if a 320k frame is used, the reservoir is definitely wasted. As I don't want to have too much unused space in my files, I choosed to use -B 256, even if I might be sacrifying a little of quality. In the past, when Lame was using strict iso, because of this reason the default for -V1 was -B 256. The Xing vbr encoder also limit up to 256k frames in order to not waste bits. (I don't know about the FhG vbr). Regards, -- Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re[4]: [MP3 ENCODER] MS switching
Hello Gabriel, Monday, September 11, 2000, 5:43:55 PM, you wrote: I am fundamentally agains crippling an encoder to fit the needs of an inept decoder. If 320 is chosen by LAME on -V1, it is there for a reason! GB This point is debatable. GB I am in the clan of the people using -B 256, and here is why: I choosed to GB keep strict ISO compatibility I didn't know ISO only allowed up to 256. Then I understand you. It's too late anyway for my huge amount of vbr albums, so I guess I'll have to buy myself a player anyway that supports up to 320. -- Best regards, Roelmailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: Re[4]: [MP3 ENCODER] MS switching
Roel VdB schrieb am Mon, 11 Sep 2000: Hello Gabriel, Monday, September 11, 2000, 5:43:55 PM, you wrote: I am fundamentally agains crippling an encoder to fit the needs of an inept decoder. If 320 is chosen by LAME on -V1, it is there for a reason! GB This point is debatable. GB I am in the clan of the people using -B 256, and here is why: I choosed to GB keep strict ISO compatibility I didn't know ISO only allowed up to 256. Then I understand you. It's too late anyway for my huge amount of vbr albums, so I guess I'll have to buy myself a player anyway that supports up to 320. -- Best regards, Roelmailto:[EMAIL PROTECTED] ISO says maximum buffer size is 7680 bit: kHz kbps bpf wasted -- 856 8064384 11.02580°) 8359679 1280°) 7680 0 16 112 8064384 22.05160 8359679 24 160 7680 0 32 224 8064384 44.1 320 8359679 48 320 7680 0 -- kHz kilo Hertz kbps kilo bits per second bpf bits per frame °) note in MPEG-2.5 ISO/FhG allows only up to 64 kbps So in strictly ISO mode larger frame sizes than the above mentioned would make no sense, except you wanna use the ancillary data section for some information. At these frame sizes the bitreservoir would not be used. Ciao Robert -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: Re[4]: [MP3 ENCODER] MS switching
GB This point is debatable. GB I am in the clan of the people using -B 256, and here is why: I choosed to GB keep strict ISO compatibility I didn't know ISO only allowed up to 256. Then I understand you. It's too late anyway for my huge amount of vbr albums, so I guess I'll have to buy myself a player anyway that supports up to 320. I didn't said that ISO only allows up to 256k. You changed the meaning of what I said by cutting text of my post (unintentionnally I think) . What I said is that ISO does not allows 320k frames to use bit reservoir, this thing leads to wasted bits when there is a 320k frame, and that's why I choose to limit to 256k. This rectification seems important to my mind. Regards, -- Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] MS switching
Currently there are the following options to control channel frame coding: -ms only LR frames allowed -mf only MS frames allowed -mj both are allowed But there are no controls to affect the switching more sensitively. So, for instance, a switch can be added to set a penalty bitrate for the MS coding theme: -mS 10 use MS coding if it saves 10 kbps -mS 20 use MS coding if it saves 20 kbps -mS 200 use always LR coding scheme Also the threshold can be adjusted due to the average bitrate. -q1-q2-q5-q7 96 uses -mS 3 uses -mS 3 uses -mS 3 uses -mS 3 112 uses -mS 6 uses -mS 6 uses -mS 6 uses -mS 6 128 uses -mS 10 uses -mS 10 uses -mS 10 uses -mS 10 144 uses -mS 15 uses -mS 15 uses -mS 15 uses -mS 200 160 uses -mS 20 uses -mS 20 uses -mS 200 uses -mS 200 192 uses -mS 30 uses -mS 200 uses -mS 200 uses -mS 200 224 uses -mS 40 uses -mS 200 uses -mS 200 uses -mS 200 256 uses -mS 50 uses -mS 200 uses -mS 200 uses -mS 200 320 uses -mS 200 uses -mS 200 uses -mS 200 uses -mS 200 So the usage of the MS frames becomes more and more unlikely for high bitrates. This is better than a sharp break. -- Frank Klemm -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] MS switching
Hello Frank, Sunday, September 10, 2000, 6:39:22 PM, you wrote: FK But there are no controls to affect the switching more sensitively. FK So, for instance, a switch can be added to set a penalty bitrate for FK the MS coding theme: FK -mS 10 use MS coding if it saves 10 kbps FK -mS 20 use MS coding if it saves 20 kbps FK -mS 200 use always LR coding scheme this is just what I was afraid of: fighting symptoms instead of a fundamental change. (-mx thread) what is the use of sacrificing kbits in trade for assumed quality gains? There will always be pieces where even -mS 100 will not be enough, and you loose a lot of the use of JS. An algorhytm needs to be adaptive: you put in music, and what comes out should be the best possible: M/S or LR. If it takes encoding all double and measuring distortion or so, it takes encoding all double. I'd still prefer it than a patched-up fundamentally inept model. With all these settings, won't you loose a great deal of universality? Why not look more at JS (-mx) as a sort of variable switching algorhytm , like vbr-old iirc, rather than a, becoming increasingly complex, condition to switch to MS. Adding -mS xx will weaken the benefits of JS (saving space), and what is there to gain? A hack for some music pieces, while you're even further off shore since you're left a less powerfull algo with still no form of assuring quality. just my 2c, not trying to stop a creative process, but simply giving my reflection on this. -- Best regards, Roelmailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] MS switching
Have someone measured the coding delay for FhG and lame ??? How many PCM samples must be feeded to achieve the first MP3 frame? May be FhG have a longer delay to see more of it's "future"? mp3enc3.1 high quality (default): encoding delay 1160 For other modes it is slightly different. LAME: 576 (but you can set this to any value = 48 in encoder.h) Note that most decoders have an additional delay of 573, so be sure to add that. lame --decode will remove the first 576+573 samples when decoding. Mark -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
