Re: [MP3 ENCODER] Please stop breaking LAME... ;)
C can't cast from type A to type B. There is only the possibility to cast every shit to type B. And this is dangerous. So you write a int ifreq; double dfreq; ifreq = (int) ( dfreq ); and now dfreq changes the type to 'struct bla*'. C converts this without batting an eyelid. ...but doing anything different from address arithmetic won't compile. So if you do anything useful with dfreq, the compiler will catch the error; if you don't do anything useful with it, then a) you don't do _anything_ with it, so no worries, mate or b) it is only part of an API interface, so it's types should be well defined and documented. The example of the X11 problem you give, is typical of X11, and not so much of C typecasts, IMHO. The example X11 implementation is full of evil ineteger - pointer conversions. Ciao, Segher -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] VBR, distortion, and CBR
What do you think sounds uglier: 20 distorted bands, each 0.1 dB or 1 distorted band by 2 dB ??? I would say that 20 distorted bands at 0.1dB is preferable, and assume that this is the choice of lame's algorithms. Is this assumption wrong ? Depends. If it is maximum distortion, you're right (don't think you would notice 2dB, though), but if it is mean (or total) distortion, it would depend. Max distortion is what gets _really_ annoying artifacts (blips). More or less noise just changes the "ambience" of the music a bit; artifacts is a much worse problem, IMHO. Ciao, Segher -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] lame source C++ compatible?
How to compile lame on a system where only a C++ compiler is available (the
C compiler costs extra money)? Currently lame generates nearly uncountable
errors with a C++ compiler.
Put
extern "C" {
}
around everything? (Around a whole file is ok, I believe).
Ciao,
Segher
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Re: [vorbis-dev] M/S encoding ?
From: Mark Taylor [mailto:[EMAIL PROTECTED]] MP3 does not allow mid/side stereo to be turned on and off on a band by band basis (AAC does), Hmm, then what happens if a JS frame has both M/SS and IS enabled? In Layers I and II, IS can be enabled across several fixed bands, I guess something similar happens in Layer III? The lower bands get MS stereo and the upper bands get IS stereo. It is in the doc (11172-3). Ciao, Segher -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Optimization
i mean in terms of speed like using faster algo like Lee's IDCT for faster implementation. rgds soyeb Ok. Yes, been there, done that. The 32 point dct II, as well as the 18 point dct IV. Both with a Lee -like algorithm. Works like a charm :-) The slowest part is the polyphase windowing, and I haven't found a way to speed it up. Ciao, Segher -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Optimization
You can use NamLing's algorithm for that instead og 512 mul for each iteration it will take 256 + 32 mul, i am not able to figure out how to implement recursive formulla. The Namling's paper is available at "Two polyphase filter architecture for MPEG audio",Namling,Shih, IEEE trans. speech and audio processing and another useful paper for this is "Fast implementation of MPEG audio coder using recursive formula with fast DCT", Cahn, YAng, Fang IEEE trans. speech and audio process Thanks! Can I get these papers online? Ciao, Segher rgds soyeb -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Optimization
Has anybody tried optimizing filter banks? What do you mean exactly? Ciao, Segher -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Decoder delay
I looked up in my notes and found that when I was first looking into this, I measured the layer II (ISO code, encode, decode) delay: it was about 480 (plus or minus a few samples). Layer II uses *only* the polyphase filterbank (same one used in layer III) so this further sugested the filterbank delay is 480 (+/- 1). 511 - 32 = 479, so I would go for the -1. So I think a value of 481 agrees with both observations and Can you try to find out if 479 agrees? It sounds more reasonable :-) my analysis. But if you have evidence that it really 511, it would be important to resolve this. Mark Dag dag, Segher -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] efficiently do multiple bitrates at once?
I'm probably going to use lame for icecast and I'd like to stream multiple bitrates of the same live music coming in the soundcard. Yep... Liveice does the multiple bitrate thing with enough coercion, but it does it by firing off multiple encoders. The thing is - unless the different bitrates have the same frequency and number of channels then surely they are too dissimilar after the resampling to gain very much? Well, the psycho acoustics should be the same :-) Ciao, Segher -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] efficiently do multiple bitrates at once?
You first filter and _then_ do the psycho acoustics? That's broken, IMHO. The filtering is done before. In psychoacoustic, (and also in psychovision) what is more annoying is not artifacts themselves, but changes in artefacts. High frequency limit change IS an annoying artefact. If the filtering was done after psycho acoustic, it I second that. would mean that the high freq limit could change from a granule to another, leading to a kind of high freq fluttering. Why would it change? You can fix the frequency... So I'm quite sure you wouldn't gain 50% in re-using computations. I think it could be... ...but it's not worth it. I'm not going to code it, anyway. This is my opinion, perhaps others could tell us what they think about it. Ciao, Segher -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] efficiently do multiple bitrates at once?
On Mon, 19 Jun 2000, Segher Boessenkool wrote: [snip] is different and frequency distribution is different due to filters. You first filter and _then_ do the psycho acoustics? That's broken, IMHO. [snip] I don't agree, in MP3 the psycho acoustics are there to determine masking of distortion. I.e. I can handle 3db of noise in SFB4 because SFB5 is X loud and the distortion will be inaudiable. If you calculate the psycho acoustics before filtering you might assume masking that doesn't exist. Ok. But then, you really should do the psychoacoustics _after_ you have done the quantization. Oops, did I just here the universe implode? ;-) Dagdag, Segher -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Mixing to mono
Hi Shawn, Is there a way to mix a JS MP3 to mono VBR by discarding all side information in M/S frames, downmixing all L/R frames, re-writing as mono VBR? You can't downmix without decoding. Ciao, Segher -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Mixing to mono
You can't downmix without decoding. Except that the M/S format has a single good channel which can be used without the decoding cycle. I thought he meant 44.100kHz -- 22.050kHz. Ciao, Segher -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] bringing down one (more) mp3 restriction [LAME case projection]
Couldn't it be so that user can (with some command) determine if he wants to remove the samples or not (or specify the number of samples he wants to remove)? When you decode mp3's made by other encoder (or older version of Lame perhaps), the delay is different... Caster It can't be solved in the encoder. What you _could_ do is: Encode the tracks with some overlap, and in the decoder, start decoding the 2nd while still playing the 1st, throw away the last frames of the 1st track the first frames of the 2nd track, and then try to find the closest match between the 1st end the 2nd start (something like cdparanoia/cdda2wav does; only not perfect matching, but least squares should do nicely, I think), and lastly, glueing those two streams together (fade em in/out so click will be annihilated). Solving in the encoder is impossible; mpeg audio works at frame level, what you need is sample level. Ciao, HTH, Segher -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] bringing down one (more) mp3 restriction [LAME case projection]
It's not the fade that is the problem, it's the mdct aliasing. I disagree. There may be some problems created by the *filterbank*, but the only attenuantion caused by the MDCT will be the first 96 samples. Here's an example: [...SNIP...] granule 2 is the first granule that is encoded. granule 1 is I assume you mean 1+2 is the first encoded? 1 granule = 1152 samples. Overlapping and stuff. the ficticious previous granule that doesn't really exisit, except that the output of the decoder for granule 2 is going to be combined with the data in the buffer which would have held the decoded output of granule 1. I will assume the decoder initializes this buffer with zeros. Lets ignore quantization. The lapped MDCT followed by the IMDCT is lossless. That means that the IMDCT output from granule 2 when added to the IMDCT output from granule 1 is indentical to the input. Ok. But, unfortunately, we _can't_ ignore quantization, because we have a _terribly_ bad granule-pair to encode: granule 2 contains sound which is not just fading in, granule 1 is zeroed, so our encoding will be decoded quite badly if there is _any_ quantization. And in the 1st block you output, you don't have any bitreservoir to save you, either, I'm afraid. In our case, the decoder just sets the granule 1 IMDCT output to all 0's because it never actually computes this and is just initializing a buffer. But the output of granule 2 IMDCT is computed correctly. output = granule_1_ouput + granule_2_output granule_1_output: encoder uses all 0's, which is incorrect since the MDCT (if it was performed) would have seen some of the data in granule 2. granule_2_outptu: correct Therefor, the output will be correct *except* where it uses data from granule 1, but this can effect at most the first 96 samples. I don't understand this. I would think it would affect 0 samples? However, the polyphase filterbank is another story, and this is something I hadn't thought about when I claimed only the first 96 samples will be attenuated: The data (with first 96 samples corrupt) is then sent to the inverse polyphase filterbank. I dont know much about how this albatross works, but I think it has an effective window length of 512. So the bad data in the first 96 samples can corrupt samples up to 96+512. You can eliminate the poly bank delay as well, I think. Any idea how bad this corruption is? The poly phase bank uses quite steep filters. Basically, the poly bank is a 512 point fft, then a window (almost rectangular), fft back, dct. btw, you cant check in it lame because it looks like the filterbank (although the delay is only 48), is not "primed" correctly, so the first 286 samples will be ignored. I will fix this and post more about it next... Mark -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] default high pass filtering
_very_ few. Every mdct sample is about 38 Hz wide, so you wouldn't even cut away the first (or zeroeth, whatever) sample. There is no such thing as 'zeroeth' ! Remember the "when does the millenium start" problem ? :-) Hey, C and Perl both start arrays with index 0. I trust them more than I trust historians. The reason ISO recommends highpass filtering is to cut away the DC portions, which mp3 can't directly represents (it is a combination of the 0'th and 575'th sample. The 575'th normally gets set to zero, especially if you're lowpass filtering). You get DC in a long block, if the sound contains some components 19 Hz. DC leads to high-frequency echoes. (Some kind of phantom image of the true sound at lower freqs). Hmm , can you explain why this happens ? Okay, here comes: - If you take the formulae for encoding and decoding 1 mdct block, and combine them, it gives the original output + a half bandwidth modulated mirror image. _If_ quantization would be perfect, overlapping blocks would cancel this. (The mdct is a tdac transform (time domain alias cancellation)). But of course, quantization is _not_ perfect. This is a general problem, not only DC related. - mdct works on the odd frequencies; this makes the problem worse for DC. - If your frame is DC shifted, you typically get huge samples at mdct index 0. Because the maximum sample value (after quant) is 8191+15, you end up with the rest of that subband quantized not nearly good enough. The 0'th subband is indices 0..3, i.e. 0..153 Hz (at 44.1 kHz samplerate). I guess you can here 153 Hz... - scalefactor allocation uses mean error, so if 1..3 can be reasonably represented, the fact that 0 can't doesn't mean that much to the iteration loops. Doesn't seem logical to me, but I'm no mp3/mdct expert. david balazic It's just some math observations. Ciao, Segher -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] default high pass filtering
Perhaps someone could find a wav wich produces this disturbing high frequency echos while encoding with lame due to low frequency signals. This could be bassNN_N.wav from SQAM (at low bitrates). about anything from "Grotus" as well (_very_ fat bass) Ciao, Segher -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] default high pass filtering
Hello I would vote for a default 14Hz high pass filter, removable with the -k option. Why an high pass filter: *theorical minimum audible freq for humans is 20Hz (also very discutable) *most soundcards are unable to reproduce less than 20Hz frequencies *most speakers are unable to reproduce less than 19Hz freq *most (if not all) headphones are unable to reproduce such low freq (even if their specs tell they are) *ISO doc recommends an high pass filter At 5 Hz, IIRC. *even if it's a small part of the spectrum, it's still a few bits usable for other more critical parts. _very_ few. Every mdct sample is about 38 Hz wide, so you wouldn't even cut away the first (or zeroeth, whatever) sample. The reason ISO recommends highpass filtering is to cut away the DC portions, which mp3 can't directly represents (it is a combination of the 0'th and 575'th sample. The 575'th normally gets set to zero, especially if you're lowpass filtering). You get DC in a long block, if the sound contains some components 19 Hz. DC leads to high-frequency echoes. (Some kind of phantom image of the true sound at lower freqs). Dag dag, Segher -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Hardware reccomendation
I am about to upgrade my motherboard and I am looking for suggestions on what the minimum horsepower needed to do = real-time encoding on a AMD or a Cyrix systems. !(Intel inside) What is the encoding process bounded by? I/O operations or computational speed? computational speed On an embedded system with a K6-200 (without L2 cache!) and gogo 2.31 there was still CPU power left for other things. ...which means you are *not* cpu bound. Ciao, Segher -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Hardware reccomendation
Computational speed, and cache size seem to be the most important Cache size and speed are the only important factor if you have cache misses, and you own an Intel processor. Cache misses are _extremely_ expensive. The P166 MMX and up have a better cache than the P133 and down. But my lowly K5-100 beats the P166 hands down. Hey, it doesnt matter if your fmul takes 4 instead of 3 cycles, if the competitor first has to wait 60+ cycles until its data finally arrives... This is why I encode both channels separately in PEM. (i.e., a granule mid channel, a granule side channel, a granule mid, etc.) Oh, by the way, anyone interested in better DCT's? Nou dag dag, Segher -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] MPEG layers
This may be a stupid question, but isn't it fun to learn (or teach) new things? :) What, roughly, are the technical differences between layer 2 and layer 3? The only thing I know, is that they work with different bitrates (layer 3 supporting lower bitrates). Layer II does _not_ have: window switching (short blocks) hybrid transform (mdct stuff) bit reservoir It _does_ have: much better scalefactors (more finegrained) The layer II scalefactors are a lot cheaper most of the time, and sometimes you pay a lot for saving too much :-( Any other differences I'm forgetting? Ciao, Segher -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] MPEG layers
Any other differences I'm forgetting? MS Stereo and entropy coding in Layer III. -- Mat. Yes, huffman. Knew I forgot something. But doesn't layer II have mid/side stereo (as well as intensity stereo)? Dagdag, Segher -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] MP3 licencing
The MP3 licencing terms are updated. A new website about it is available: www.mp3licencing.com licensing -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] side channel starving
Segher Boessenkool a écrit : At high frequencies, humans only decide direction of the sound by the relative left/right intensity, not by phase difference. So this idea seems like the intensity stereo. In this case, why not implementing intensity stereo? No, it's totally different :-) Intensity stereo == panned mono. Side channel starving == leaving out side channel samples that convey no useful information. Totally different :-) IS sounds horrible, is only useful at very low bitrates. But it would be nice to have it implemented, of course. Ciao, Segher -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Decoder quality comparison [quite detailed - so rry if repeat]
[snip] There was also a bug in the ISO encoder which could easily be in the decoder: It was reversing the order of the individual quadruples in the count1 region. This bug only effects the highest frequencies, and is particularly insidious because it produces small flaws which could be attribted to compression artifacts. [snip] Could something like this be one of the reasons so many people were (and still are) singing the prases of the almighty blade encoder? :) Don't think so... The iso decoder doesn't have the bug, I believe. The encoder does. But, alas, bladeenc screws up its high frequencies anyway, so it's not a real problem for it :-Z Ciao, Segher -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] side channel starving
Hi all, Does lame implement side channel starving? If not, I'll volunteer :-) Ciao, Segher Boessenkool LAME has crude algorithm which allocates bits based on the energy contained in the side channel vs. mid channel. It definatly needs work: I have some test cases where LAME allocates too many bits to the side channel, and other test cases (like ftb_samp.wav) where it allocates too few. You could try allocating bits per sfband... sounds reasonable to me. I tried the side channel "sparsing" algorithm described in the ISO docs a long time ago, and it does not work at all. That's strange... for me, it does work. Saves about 30% of bits as well. I'll look into it tonight or something. Dagdag, Segher -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] informative message / VBR
we might add a "relaxed" option which would not waste these bits). ... and we would choke many hardware players from playing LAME encoded mp3s! I think, we shouldn't ignore the buffer considerations as stated in the ISO documentation. Mark Robert -- I think that if it's only an option, then it's ok. If you're not going to be iso-mpeg compliant, you can change other things as well. So why not just use vorbis or something? Standards are good, use them. Even if some parts are braindead, they're at least standard. Ciao, Segher -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] side channel starving
Hi all, Does lame implement side channel starving? If not, I'll volunteer :-) Ciao, Segher Boessenkool -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] the road to next(v4.00?)
wich stupidness are you reffering to? Hahahah :) There's lots of stupid things that mp3 does. It's just an old model designed under considerations that aren't always valid anymore. I don't understand this? Did the physics change, or the human ear/brain? Mark has said a few times that there are several rather obvious things you could change that may increase sound quality. jack. -- Lossless coding is really bad, can be way smaller -- Dynamic range of the scalefactors is much too small -- Short blocks is an awful hack Just look at AAC, it's much better than mpeg-1 Ciao, Segher -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] the road to next(v4.00?)
I'm planning some 3D Now!, SSE code, but I have no K6-2/3, Athlon, PIII. does someone donate me a machine or shell account :-) ? 3D now and SSE are fine, but why not some MMX code? A lot more people got mmx processors. Are 3D Now and SSE really faster than MMX? MMX is integer, 3dnow is float. and these have not written yet, but may improve the LAME 5 mixed_block support Thus Lame would be the first encoder able to produce mixed blocks FhG does as well. Ciao, Segher -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] using lame363 for shuttle transmission
0x805e2cc calc_xmin+460: fldl 0xfff0(%ebp)
It loads from stack, offset -0x10; so it's a local variable.
-- for ( sfb = 0; sfb cod_info-sfb_lmax; sfb++ ){
Don't think so, no floats involved here.
Ciao,
Segher
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] region0/1/2 dividing
and dividing region0/1/2 is determined by looking up the subdv_table[]. However, I am afraid this method is not the best. It is indeed not best. Does the MP3 standard says that we *must* use this dividing method ? Or is it only the recomendation ? It's not in the standard at all; it's in the example implementation. If it is only the recomendation, I hope it will be dramatically improvement the bit allocation to change the dividing method. Better subdv tables gain you about 8% Exhausive search gets you about 5% more Ciao, Segher -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Status of noise quantization
Hiya, I dont think it was ever in doubt that xr is an amplitude? xr(i) is the i'th the MDCT coefficient in the expansion of the original wave form in terms of cosine functions with wave number i. Not exactly... Term i in the mdct corresponds to sine/cosine waves number i _and_ i+1, added together. And of course we have two overlapping mdct blocks, _both_ of which give some i and i+1 waves... sigh. I think we should use energy difference in db, so the noise formula should be sum (10 log (xr^2 - ix^(8/3))) or 10 log (sum(xr^2 - ix^(8/3))) For the psy model we should use whatever the model was made for; I think energy difference is better, but a model that relies on amplitude diff. should be implemented that way. and I think the latest quantization method will do the best aproximation even when we use this noise formula. However, quantization comes _after_ the psy model, and energy difference quantization gives the best result (theoretical in listening tests). Hope I hurt no-ones feelings, Ciao, **Segher -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] quantization formula
Segher, shouldn't the formula be: if (x (0.5 * (pow(i, 4.0/3.0) + pow(i+1, 4.0/3.0)) i++; Mark No, if you use 4/3, you optimize for sample amplitude; but we'd like the sample _energy_ to be optimal, so 8/3. Ciao, Segher -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] quantization formula
Hi, all. One problem: The code is now about 50% slower, mostly because the old quantize_xrpow had some hand rolled asm for gcc and MSVC. No problem :) This is ASM implementation. Hey, my own implementation does 1 table lookup, that's all. You guys figure it out yourself, or I'll post something tomorrow or something. Hint: don't do floating point, int is so much nicer... (hehehe). Ciao, Segher -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] quantization formula
From: Segher Boessenkool [EMAIL PROTECTED] Date: Mon, 29 Nov 1999 12:44:30 +0100 (CET) Segher, shouldn't the formula be: if (x (0.5 * (pow(i, 4.0/3.0) + pow(i+1, 4.0/3.0)) i++; Mark No, if you use 4/3, you optimize for sample amplitude; but we'd like the sample _energy_ to be optimal, so 8/3. Ciao, Segher hmm, I'm not so sure about this. The noise measure used in LAME is based *not* on the error in the energy fabs(i^8/3 - x^2) but instead on the energy of the error: ( i^4/3 -x ) ^2 Since LAME picks scalefactors to try to minimize the second quantity, I think we should use a quantization consistant with this error measure? Ahah. I think the scalefactor picking should be consistent with the first formula instead :-) But seriously, what the ear hears is energy, not amplitude; so the second formula is not an accurate description of the audible error. Ciao, Segher -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] quantization formula
Okay, here it is, the quant formula I promised some time ago: We got a sample x, floating point, positive (put the sign back on later, if you like). Calculate i = floor(pow(x, 0.75)) as usual. i is integer. Now: if (x pow(0.5 * (pow(i, 8.0/3.0) + pow(i+1, 8.0/3.0)) , 0.375)) i++; and i is the quantized value. Rationale: minimize the quantization noise per sample. The iso formula merely minimizes the average case, and not really good either. The 2nd step can be done per table lookup, of course :-) Hope you like it, Segher -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] ATH bug
On Thu, 18 Nov 1999, Robert Hegemann wrote: Has anyone ever considered tossing the stupid bands as far as psycoacoustics are concerned, it seems much more sensible to do all calculations over the non-segmented frequence space and breakup into bands just for packing into the file. This would probably also make more sophicated masking (like temporal masking) easier to impliment. Bands are ok, but the layerIII bands are too wide for good psycho acoustics. Take the bands smaller (about 1/4 bark), do your calculations, and take for calculation of the scalefactors the minimum of the calculated allowable distortions for the psycho bands that match that scalefactor band. Ciao, Segher -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
