Re: [MP3 ENCODER] Normalize audio input
On Sun, May 28, 2000 at 03:32:39PM -0600, Mark Taylor wrote: [...] Or am I just too paranoid about normalizing to 16bit integer values? -- Niklas I also worry about this, but usually there are much bigger problems to worry about :-) Right now, the resampling and the stereo-mono averaging in LAME is done with short ints because the encoding routines want short int's Is this stereo-mono averaging only for mono encoding, or does it also affect joint stereo? -- Niklas -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Normalize audio input
About the normalizing: The link was wrong. It should be this one: http://www.audiograbber.com/normalize.html Audiograbber has some advanced settings for normalization, but I have yet to find a program to use a sliding scale (equivalent to your father controlling the volume button, ensuring the volume is always about the same level). Gerben ([EMAIL PROTECTED]) -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re[2]: [MP3 ENCODER] Normalize audio input
Hello Gabriel, Saturday, May 27, 2000, 2:44:36 PM, you wrote: GB Good point here. If I'm not too wrong, a kind of normalization can be done GB by just changing the scalefactor value. In this case, such an option would not change the GB encoding process. Lame could encode each frame as usual, but could change GB this value during the frame packaging. I think this should not interfere GB much with the main goal of Lame, wich is mp3 encoding. This "scalefactor", would this touch the "non uniform quantization" as described in the Davis Yen Pan doc? free quote: LIII raises input to 3/4th power to get more consistent SN ratio over the range of quant values. I don't understand why you would raise a input level by 3/4th, encode and raise to 4/3th whilst decoding, but I take there was a reason for this, and maybe this is not something to tinker with? -- Best regards, Roelmailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: Re[2]: [MP3 ENCODER] Normalize audio input
This "scalefactor", would this touch the "non uniform quantization" as described in the Davis Yen Pan doc? free quote: LIII raises input to 3/4th power to get more consistent SN ratio over the range of quant values. It would be easier to try answering your question after looking at this doc, but it seems that I don't have it. Is it possible for you to send it to me? 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] Normalize audio input
Hello Gabriel, Sunday, May 28, 2000, 12:09:47 PM, you wrote: This "scalefactor", would this touch the "non uniform quantization" as described in the Davis Yen Pan doc? free quote: LIII raises input to 3/4th power to get more consistent SN GB ratio over the range of quant values. GB It would be easier to try answering your question after looking at this doc, GB but it seems that I don't have it. Is it possible for you to send it to me? There's not much in to be honest, just a quick intro to audio compression. I'll look up the url: you can find one doc here: http://www.bok.net/~pan/ and the one I quoted: (don't remember where I found the .pdf, so I put it up my page (temp)): http://users.belgacom.net/gc247244/extra/Digital_Audio_Compression_01oct1993DTJA03P8.pdf (only about 85kbytes) -- Best regards, Roelmailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: Re[2]: [MP3 ENCODER] Normalize audio input
- Original Message - From: Roel VdB [EMAIL PROTECTED] To: Gabriel Bouvigne [EMAIL PROTECTED] Sent: Sunday, May 28, 2000 4:06 AM Subject: Re[2]: [MP3 ENCODER] Normalize audio input Hello Gabriel, Saturday, May 27, 2000, 2:44:36 PM, you wrote: GB Good point here. If I'm not too wrong, a kind of normalization can be done GB by just changing the scalefactor value. In this case, such an option would not change the GB encoding process. Lame could encode each frame as usual, but could change GB this value during the frame packaging. I think this should not interfere GB much with the main goal of Lame, wich is mp3 encoding. This "scalefactor", would this touch the "non uniform quantization" as described in the Davis Yen Pan doc? free quote: LIII raises input to 3/4th power to get more consistent SN ratio over the range of quant values. I don't understand why you would raise a input level by 3/4th, encode and raise to 4/3th whilst decoding, but I take there was a reason for this, and maybe this is not something to tinker with? I don't really understand the real utility of this 3/4 power. If someone knows about it, please drop us a line. About this normalization thing, here is a quote from Mark some times ago: "One easy thing would be to change the value of global_gain. it's an 8bit int stored for each channel of each granule. Changing this +/-1 changes the volume by .75db." It's the thing that I think could be used, without affecting the encoding process. Regards, -- Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Normalize audio input
At 09:24 28/05/00 +0200, you wrote: Normalization consists of determining the output leven of the audio data, and then multiplying the audiodata with a certain factor so that the highest value becomes 95 or 99% of the absolute maximum (plus or minus 32768). The trick is twofold: First of all, determining the output level is not that obvious. Many programs just count the highest peak in the data, but one peak can thus influence the rest of the data considerably. Other programs calculate the maximum and the desired level with more sophisticated algorithms (root mean squared, which aproaches the human hearing better than a peak scan) You could consider an adaptive algorithm, which would divide the data in blocks, determine the highest peak in each block, and would then use a gradually sliding factor to multiply the samples with. Hello, Yes, but if you use RMS you must need compression to avoid clips, and compression means a reduction in the dynamic range, and less dynamic range reduces the "quality" but it sounds stronger. Recent CDs are RMS normalized (Usually around -8 db) and they sound really horrible (IMO). I think that MP3 coding for a -8 db RMSed song need more bits and is more difficult to detected masked freqs. Am I wrong ? I think that kind of normalization should be done in the decompression process (it means information destruction) like a radio station compressor does. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Normalize audio input
Hello Gabriel, Saturday, May 27, 2000, 2:44:36 PM, you wrote: GB Good point here. If I'm not too wrong, a kind of normalization can be done GB by just changing the scalefactor value. In this case, such an option would not change the GB encoding process. Lame could encode each frame as usual, but could change GB this value during the frame packaging. I think this should not interfere GB much with the main goal of Lame, wich is mp3 encoding. This "scalefactor", would this touch the "non uniform quantization" as described in the Davis Yen Pan doc? free quote: LIII raises input to 3/4th power to get more consistent SN ratio over the range of quant values. I don't understand why you would raise a input level by 3/4th, encode and raise to 4/3th whilst decoding, but I take there was a reason for this, and maybe this is not something to tinker with? I don't really understand the real utility of this 3/4 power. If someone knows about it, please drop us a line. I dont really know either, but I think it is to normalize the MDCT coefficients. For music, the amplitudes of these coefficients drop off sharply as the frequency is increased. Rasing them all to the 3/4 power before quantization has the effect of allocating more bits to the smaller coefficients. Mark -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Normalize audio input
I just want to know how can I normalize, and I didn't ask how about expand LAME to support normalization. But wouldn't a lame-integrated normalization (i.e. scaling of the sample values) improve quality over a seperately done normalization, because the intermediate results would be floating-point instead of 16bit (or lesser) integer? I think that a simple scaling option in lame would be useful (i.e. something like --pre-scale scalefactor). As an alternative, are there any sound formats that use floating-point values for samples? If so, maybe lame could be made to be able to read such a format. If not, it should be quite trivial to include a raw floating-point format for use by custom-written preprocessing tools. Or am I just too paranoid about normalizing to 16bit integer values? -- Niklas I also worry about this, but usually there are much bigger problems to worry about :-) Right now, the resampling and the stereo-mono averaging in LAME is done with short ints because the encoding routines want short int's for the input. This does result in some loss of precision, so it might be worth trying to convert "mfbuf" from short int to float. If the speed impact is negligible, I think all internal processing should be done in floating point. Mark -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] Normalize audio input
Hello, all. I would like to normalize (maxmize) and trim silent part from input audio data. I'm going to add both routine into get_audio.c (I don't use libsndfile). Does anybody know how to do that or such sound libraries? TIA -- Osamu Shigematsu mailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Normalize audio input
Hello, all. I would like to normalize (maxmize) and trim silent part from input audio data. I'm going to add both routine into get_audio.c (I don't use libsndfile). Does anybody know how to do that or such sound libraries? TIA -- Osamu Shigematsu mailto:[EMAIL PROTECTED] I think LAME is a MP3 encoder and not a general audio processing tool. If you think LAME would need them, why not going further and adding ie. a pitch control? The things you suggest are in my opinion better placed in tools like SoundForge. Or if you like, start writing a stand alone tool for normalization (there are already some out there) and a silence trimmer. Just my 2 Pfennige Robert -- Sent through GMX FreeMail - http://www.gmx.net -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
