Home |
Search |
Today's Posts |
#1
![]() |
|||
|
|||
![]()
Lord Hasenpfeffer wrote:
wrote: I would be somewhat surprised that any current CD was not NORMALISED to somewhere around (just below) 0dbfs. Yes, as that has apparently been "all the rage" for several years running now. Actually, *abuse* of the 0dBFS threshold is really "all the rage" these days. I personally am only interested in "normalizing" older, quieter CDs mastered during the stone and middle ages before encoding them as MP3s so that my final files sound somewhat "modern" to my ears and not all tinny and weak when juxtaposed with MP3s encoded from more recently mastered CDs. I would be somewhat surprised to learn that any mainstream commercial release has ever gone out without being normalised (using the strict definition of the term) to somewhere within 1db of FS. Given this, it sounds like you are actually compressing or limiting to raise the RMS level. In no way am I interested in brutally forcing any RMS levels to go "through the roof". Anywhere from strictly normalized to "slightly hot" levels (depending on genre) are all that I seek. Well, if you are going for 'slightly hot' then you must be limiting or clipping somewhere to keep within the actual hard limit of 0dbFS, so irrespective of what the tool calls itself this cannot be said to be normalising. I would also observe that a track which is quieter will tend to sound 'tinny & weak' when compared to a louder track even without being coded to MP3 first, it is just how humans work. I am sure that lots of people here have stories of finding the 'extra something' at the end of a long mix session by tweaking the control room monitor volume up a db or two for the benefit of a client. Many times I've encountered WAVs from CDs that are, according to my standards, mastered too loudly. When this is the case, I _do_ simply "rip-and-encode" the unmodified, original WAVs (contrary to what dip**** said of me earlier when he said I seek to indiscriminately normalize every CD I own). If that were the case, I'd end up making half of what's in my library *quieter* than it is on the original CDs, not louder! ![]() Making them quieter does not undo the compression used to make them boring to start with! If normalization is _needed_ for a "mix-CD" sporting tracks by various artists from various sources, I will "normalize" all the tracks individually to bring them to a common loudness, across-the-board. Well, this will get all the tracks to the same peak level, but they are unlikely to all sound the same volume, as to a first approx, we hear RMS not peak. What you probably want to do is (being careful that no intermediate file clips (32 bit signed int may be a good intermediate format for this)), is to equalise the average RMS levels (which will make the peak level end up all over the place), then normalize the entire collection to put the peak level into range. Your choice of averaging function matters if you want good results. However, depsite its name, the "normalize" application I use is capable of doing more than just "textbook normalization" if I tell it to do so. This has been a major stumbling block for me when I've previously attempted to discuss its behaviour amongst others who've not used nor even heard of it before. Do you have a URL for a tarball? "Normalize" can be made to limit the peaks when instructed by the user to boost an RMS level beyond the textbook normalization level. One of the guys over in the other newsgroup suggested that we call this "limitizing" because there is no other, readily available, predefined textbook term to describe it. Sounds like fast attack hard knee limiting (Possibly with compression) to me? Have you seen that compressor Dyson wrote when he was at free BSD? It is excellent for this sort of thing. Further the phycoacoustic model IIRC derives 'too quiet' threshold from the RMS level of the signal, not an absolute threshold (IE at some frequency it may be 30db below curent RMS level, NOT 40db below 0dbFS). Mmm-HMMM.... Now *that's* something of which I was not previously aware. If that's true then my hypothesis for boosting amps to save freqs may indeed be fatally flawed. Are you sure you're not thinking of frequency masking when you say this? Yes, to a first approx, frequency masking weights towards energy in nearby bands when calculating thresholds, what I am thinking of looks at overall energy. It is worth noting that whatever you do to the input data, it is only possible to fit a fixed amount of information into the output stream, Now, I do understand that, however, I haven't contemplated it very much. It is worth working thru the implications of this as it really brings home the absence of a free lunch. if you force the encoder to include more frequency data (higher resolution or more bands active, then time or ampletude resolution MUST necassarily suffer). Excellent information. By time resolution you mean in that the file would have to be made to play slower in order to accommodate the increased amount of data? No, not slower (which would imply a higher effective bit rate), but that the information about when something happens may have to be stored less precisely. Also, would not such effects be greater at lower bitrates than at higher ones? All the compromises apply more at lower bitrates! And if so, would this not mean that my hypothesis would actually become more appropriately applied towards higher bitrate MP3s than at lower ones? Because I'm guessing here, by reversing your logic, that a large enough bitrate could eventually be employed which would cause the encoder to either "pad the file with zeroes" or store the additional data depending on the normalized status of the WAV being encoded. Depends on if your hypothesis holds at all, I am yet to be convinced that anything beyond psycological effects are at play here (Louder is usaually perceved as better). Consider that a 'perfect' data compression tool would simply store the gain used in the normalisation once (after all it does not change during playback), thus normalising has little effect on the amount of *information* in the .wav file. And if that's true, what bitrate may I be talking about? There are a few lossless wav file compression tools around, some of them are even reasonably good, find one then see how much it can reduce the size of a typical wave file. This will give you some idea of how much data is actually redundant in a wav file and of how much *information* is required to represent that file. It will be program dependent, a file containing a single 1Khz tone can be losslessly represented in very few bits, a thrash metal gig will take rather more (but why anyone would bother....). Regards, Dan. -- ** The email address *IS* valid, do NOT remove the spamblock And on the evening of the first day the lord said........... ..... LX 1, GO!; and there was light. |
#2
![]() |
|||
|
|||
![]()
WBRW wrote:
The MP3 ENCODING is fine -- it's just the DECODER that adds its own extra clipping upon playback. I've seen downloaded MP3s where the file had to be knocked down by 6 dB, just to get it below the level of clipping during playback! Do you know if winamp works the same way? Would setting the volume slider to 80% or 50% help in this case? Erwin Timmerman |
#3
![]() |
|||
|
|||
![]()
Do you know if winamp works the same way? Would setting the volume slider
to 80% or 50% help in this case? No, that doesn't change the actual content of the MP3 file. I recommend you use the "MP3GAIN" utility, which will let you losslessly normalize your MP3 files to a "safe", non-clipping volume level. If you try to increase the loudness value too much, it will warn you that the MP3 file will start to clip. And in automatic mode with the "/r" switch, it will normalize all of your MP3 files to a nearly constant RMS volume level (again, always below the level of clipping) so that you don't have to turn the volume up for a dynamic '70s or '80s song and then have your ears blasted away by a modern "hyper-compressed" song. Or, you have the option of applying a constant volume change to an entire collection of songs, so that the relative loudness differences between the tracks of an album will be maintained, for example. MP3GAIN is available for download he http://www.geocities.com/mp3gain/ Windows GUI, Windows command line, and Linux versions are available (sorry, Mac users!). |
#4
![]() |
|||
|
|||
![]()
In rec.audio.pro, Erwin Timmerman wrote:
WBRW wrote: The MP3 ENCODING is fine -- it's just the DECODER that adds its own extra clipping upon playback. I've seen downloaded MP3s where the file had to be knocked down by 6 dB, just to get it below the level of clipping during playback! Do you know if winamp works the same way? Would setting the volume slider to 80% or 50% help in this case? Winamp's volume slider just controls the 'wave' volume on the Windows 'volume control' mixer, and so does nothing to affect the digital playback. On my system with a Delta 66 card (which has it's own mixer/control panel), the Winamp volume control does nothing. So no, it wouldn't help. Erwin Timmerman |
#5
![]() |
|||
|
|||
![]() "Lord Hasenpfeffer" wrote in message ... Whoa! Do you mind discussing this with me a bit via private email? I think you've got, if not *the* answer I've been looking for, the overall *better idea* which I've been looking for and have been trying and probably failing to "correctfully" solve on my own. Some of the things you've said in this post could start a flame war in other newsgroups. I know this. I've seen it happen. It even happened to me once. But that's beside the point. I've got some questions for you if you don't mind answering. Someone has finally popped up with information reagrding actions that can be taken on the MP3s themselves. How does this relate? Odd that you should be so taken by this, as it is a totally subsequent matter to the encoding process. He is in reference to actions taken on the MP3 file itself... *after* the encoding process in which the frequencies that you sold blazenly desire to KEEP, are already gone !!! Taking it off-group is perfectly fine, but terribly unfair to those of us that want to learn something. -- David Morgan (MAMS) http://www.m-a-m-s.com http://www.artisan-recordingstudio.com And with regard to MP3 compression, an MP3 file can be LOSSLESSLY NORMALIZED on a frame-by-frame basis in 1.5 dB increments. The actual compressed data is NOT changed -- only an ancillary "loudness scale-factor". You can even LOSSLESSLY add fade-ins and fade-outs to MP3 files, by changing the scale-factor on a frame-by-frame basis. (The "MP3Trim" utility can do that.) So, if you're concerned about this whole issue, simply pre-normalize the incoming WAV file by a multiple of 1.5 dB, and then use a utility like "MP3GAIN" to losslessly normalize it back down to the originally intended level. In fact, you should be doing this anyway with any MP3 files you might download, as today's over-compressed pop music often drives MP3 decoders into extreme amounts of clipping unless the level of the MP3 file is reduced to a "safe" value. (The MP3 ENCODING is fine -- it's just the DECODER that adds its own extra clipping upon playback.) I've seen downloaded MP3s where the file had to be knocked down by 6 dB, just to get it below the level of clipping during playback! |
#6
![]() |
|||
|
|||
![]()
WBRW wrote:
I recommend you use the "MP3GAIN" utility, which will let you losslessly normalize your MP3 files to a "safe", non-clipping volume level. If you try to increase the loudness value too much, it will warn you that the MP3 file will start to clip. And in automatic mode with the "/r" switch, it will normalize all of your MP3 files to a nearly constant RMS volume level (again, always below the level of clipping) so that you don't have to turn the volume up for a dynamic '70s or '80s song and then have your ears blasted away by a modern "hyper-compressed" song. Or, you have the option of applying a constant volume change to an entire collection of songs, so that the relative loudness differences between the tracks of an album will be maintained, for example. MP3GAIN is available for download he http://www.geocities.com/mp3gain/ Anyone compared this with replaygain? They seem to be doing similar things, but replaygain is doing it with tags rather than modification of the data itself http://replaygain.hydrogenaudio.org/ |
#7
![]() |
|||
|
|||
![]()
WBRW wrote:
I would be somewhat surprised to learn that any mainstream commercial release has ever gone out without being normalised (using the strict definition of the term) to somewhere within 1db of FS. How about this: Snip list of tracks Well, 89.1% (depending on if that is power or voltage) is about 1 percent or so below FS. "The Sign" was Ace Of Base's biggest U.S. hit ever, reaching #1 on the Billboard chart in 1994 -- yet, on the album, it actually has the LOWEST peak level of all the tracks, only hitting 56.2% of full scale, or -5.0 dB! Sounds like they normalled the whole album to retain relative levels across the tracks. This is a perfectly reasonable thing to do. And with regard to MP3 compression, an MP3 file can be LOSSLESSLY NORMALIZED on a frame-by-frame basis in 1.5 dB increments. The actual compressed data is NOT changed -- only an ancillary "loudness scale-factor". You can even LOSSLESSLY add fade-ins and fade-outs to MP3 files, by changing the scale-factor on a frame-by-frame basis. Indeed, I had forgotten what the resolution was, but was aware of this functionality, not that it makes any difference if the hypothesis that spawned this discussion holds, the damage is done by then. However the very presence of this gain factor in each frame hints that any competent codec should not be sensitive to input level except in so far as it modifies this value (Otherwise you have more less entropy in the output file then you could have, and that is bad in a compressed stream). In fact, you should be doing this anyway with any MP3 files you might download, as today's over-compressed pop music often drives MP3 decoders into extreme amounts of clipping unless the level of the MP3 file is reduced to a "safe" value. (The MP3 ENCODING is fine -- it's just the DECODER that adds its own extra clipping upon playback.) I've seen downloaded MP3s where the file had to be knocked down by 6 dB, just to get it below the level of clipping during playback! Ouch, but I suppose some overshoot in the reconstructed audio is going to be present.... Regards, Dan. -- ** The email address *IS* valid, do NOT remove the spamblock And on the evening of the first day the lord said........... ..... LX 1, GO!; and there was light. |
#8
![]() |
|||
|
|||
![]()
I recommend you use the "MP3GAIN" utility, which will let you
Anyone compared this with replaygain? They seem to be doing similar The following text at the MP3Gain website makes me suspect that MP3Gain implements Replay Gain for MP3 files. :-) --8-- For a further explanation of Replay Gain (the statistical analysis done by MP3Gain), see replaygain.hydrogenaudio.org --8-- /Jonas |
#9
![]() |
|||
|
|||
![]()
WBRW wrote:
if you _must_ use MP3, you might as well make the best of it May I add that to my tagline? ![]() You really can make something so easy sound *so easy*!! I'm reminded of the conclusion of "Breaker Morant" where the executee says, "Don't make a mess of it, you *******s!" -- and utilities like MP3Trim and MP3GAIN will definintely help. Kewl and noted. Thank you, thank you. ![]() People also apparently fail to realise that this "quiet sounds will be eliminated" feature is RELATIVE, not ABSOLUTE. To what does the "Absolute" in "Absolute Threshold of Hearing" refer? It doesn't mean that "sounds at xx dB below full scale will be cut out". Instead, it means something along the lines of "sounds at xx dB below the peak level OF THAT PARTICULAR FRAME will be cut out". What is your source for this information, if you don't mind me asking? I'm not challenging you. I'd simply like to read more about it. Any good "lossy" audio compression scheme is based upon the principles of NMT and TMN -- "Noise Masks Tone" and "Tone Masks Noise", which are pretty much self-explanatory for anyone with a little insight. If these two parameters were based on FIXED levels, then the end result would be sheer GARBAGE. Instead, they are always RELATIVE, within the frequency ranges and instantaneous peak and RMS loudness levels of any particular split-second instant (i.e. "frame") in the song. OK, we seem to be dealing with the "masking" side of lossy compression methods, not the Absolute Threshold of Hearing side of them. Correct me if I'm wrong but ATH and masking are not the same. Masking is indeed relative but, as I understand it, the Absolute Threshold of Hearing is absolute - hence the inclusion of the word "Absolute" in its name. And I am interpreting that to mean "absolute in reference to digital Full Scale". Also, this scheme actually works BACKWARDS compared to what people seem to think. Take a piano solo with tape hiss in the background, for example. When the piano is silent or very quiet, you can hear the background hiss, so the MP3 encoder KEEPS the hiss. But when the piano becomes loud enough to effectively "mask" the background hiss, the encoder starts CUTTING OUT the "inaudible" hiss, since it is more important to expend the available data bandwidth upon encoding the piano's sound. I don't see how people could naturally think the opposite of this to be true - unless they're confusing the effects of masked audio removal with standard noise reduction practices. The beginning of "Steppin' Out" by Joe Jackson is a good example -- I have this and will check it out ASAP. some MP2/MP3 encoders will cause particularly nasty artifacts in the piano track as it fades in, in order to capture the intense high-frequency percussion that's going on. What do these nasty artifacts sound like? It will help me if I know for what to listen. Myke -- -================================- Windows...It's rebootylicious!!! -================================- |
#10
![]() |
|||
|
|||
![]() Lord Hasenpfeffer wrote: To what does the "Absolute" in "Absolute Threshold of Hearing" refer? Not much any more. It is continuously adapted to the current "loudness" so has become rather an oxymoron. For a sketch of the thrashing that has occured in Lame development relative to this rather crucial issue see: http://ee1.bradley.edu/~jodaman/dev/mp3/lame.html I suggest again that you subscribe to the mp3encoder mailing list where you can pose your questions to those who know exactly what goes on and how your modifications will affect the encoding process. You can subscribe at: http://minnie.tuhs.org/mailman/listinfo/mp3encoder It doesn't mean that "sounds at xx dB below full scale will be cut out". Instead, it means something along the lines of "sounds at xx dB below the peak level OF THAT PARTICULAR FRAME will be cut out". What is your source for this information, if you don't mind me asking? I'm not challenging you. I'd simply like to read more about it. You can ask the developers yourself. They are pretty good with questions. I'm not sure whether they pay too much attention to statements. :-) Bob -- "Things should be described as simply as possible, but no simpler." A. Einstein |
#11
![]() |
|||
|
|||
![]()
Bob Cain wrote:
To what does the "Absolute" in "Absolute Threshold of Hearing" refer? Not much any more. It is continuously adapted to the current "loudness" so has become rather an oxymoron. If the ATH does not use Full Scale as its point of reference what else does it use? For a sketch of the thrashing that has occured in Lame development relative to this rather crucial issue see: http://ee1.bradley.edu/~jodaman/dev/mp3/lame.html OK, lemme click Send first. I suggest again that you subscribe to the mp3encoder mailing list where you can pose your questions to those who know exactly what goes on and how your modifications will affect the encoding process. You can subscribe at: http://minnie.tuhs.org/mailman/listinfo/mp3encoder Your phrase "I suggest again" will undoubtedly be interpreted by others in this group as "I suggested before and you have apparently ignored my suggestion". However, this is your first post to this thread in this newsgroup and I have not been checking in with the other thread in the other newsgroup very much lately so this is the first I've heard of it from you. This would seem to be a very fine place to go for further information. I can take my list of conclusions posted earlier here to over there and see what they have to say about it. Myke -- -================================- Windows...It's rebootylicious!!! -================================- |
#12
![]() |
|||
|
|||
![]()
Bob Cain wrote:
Lord Hasenpfeffer wrote: To what does the "Absolute" in "Absolute Threshold of Hearing" refer? Not much any more. It is continuously adapted to the current "loudness" so has become rather an oxymoron. For a sketch of the thrashing that has occured in Lame development relative to this rather crucial issue see: http://ee1.bradley.edu/~jodaman/dev/mp3/lame.html OK, so there's the answer, at least for the LAME encoder. The ATH level is dynamically adjusted to content. I must say that some other websites are not too clear about it, and just talk about the FM-curve and that they apply it. To what? To FS? That seemed strange to me all along with all the varying playback levels that can occur. And indeed now it shows that the effect is dynamically applied. Thus changing the volume of a wave file does nothing but change the ATH level with it. No difference whatsoever. No frequencies kicked out. End of story. Erwin Timmerman |
#13
![]() |
|||
|
|||
![]() "Lord Hasenpfeffer" wrote in message ... Bob Cain wrote: You can ask the developers yourself. They are pretty good with questions. I'm not sure whether they pay too much attention to statements. :-) http://minnie.tuhs.org/mailman/listinfo/mp3encoder This would seem to be a very fine place to go for further information. I can take my list of conclusions posted earlier here to over there and see what they have to say about it. Myke, with all due respect... so far (to me) it would appear that your communication problem is that you had rather push your conclusions onto others, rather than to seek their validity through questioning. Please heed Bob's last statement as repeated above. Good luck to you. -- David Morgan (MAMS) http://www.m-a-m-s.com http://www.artisan-recordingstudio.com |
#14
![]() |
|||
|
|||
![]()
To what does the "Absolute" in "Absolute Threshold of Hearing" refer?
It is the standard "hearing sensitivity curve" that I believe Dolby used to help develop their Noise Reduction systems. It is a curve showing how the ear is most sensitive to mid-range frequencies (around 1-2 kHz) and how the sensitivity decreases quite a bit above 10 kHz (in order words, high frequency sounds have to be LOUDER in order to he heard). This curve attempts to show the QUIETEST sound levels that the average human ear can detect across its frequency range (20 - 20,000 Hz). Also, this spectral graph might help explain how MP3 encoding behaves: http://rvcc2.raritanval.edu/ktek9053/noisetest.gif The top half is the spectrum analysis of an uncompressed WAV file containing white noise that fades out gradually, with a constant 2000 Hz triangle wave applied on top at a constant level (the "bars" are the harmonics that this triangle wave generates). The lower half is this same audio, as run through the popular Fraunhofer "Fast" MP3 encoder at 96 kbps. You can see how it starts to increasingly "cut out" the white noise as the tone begins to "mask" more of it. What do these nasty artifacts sound like? It will help me if I know for what to listen. It almost sounds like dead spots on magnetic tape -- the piano will simply drop out momentarily, creating a "chattering" effect which is actually quite common in low-quality lossy audio compression. |
#15
![]() |
|||
|
|||
![]()
Erwin Timmerman wrote:
http://ee1.bradley.edu/~jodaman/dev/mp3/lame.html OK, so there's the answer, at least for the LAME encoder. The ATH level is dynamically adjusted to content. I must say that some other websites are not too clear about it, and just talk about the FM-curve and that they apply it. To what? To FS? That seemed strange to me all along with all the varying playback levels that can occur. And indeed now it shows that the effect is dynamically applied. Thus changing the volume of a wave file does nothing but change the ATH level with it. No difference whatsoever. No frequencies kicked out. End of story. This is definitely a good lead. This page does seem to indicate that at least the _point of reference_ for the scale changes on a frame-by-frame basis based upon the loudness of the maximum peak within each frame rather than remaining fixed at digital Full Scale. The implications of this, however, I do not yet fully comprehend therefore as far as I'm concerned it is still a bit premature to declare "End of story" as you so eagerly have. Nevertheless, I hope you are correct. Myke -- -================================- Windows...It's rebootylicious!!! -================================- |
#16
![]() |
|||
|
|||
![]() Lord Hasenpfeffer wrote: Your phrase "I suggest again" will undoubtedly be interpreted by others in this group as "I suggested before and you have apparently ignored my suggestion". However, this is your first post to this thread in this newsgroup and I have not been checking in with the other thread in the other newsgroup very much lately so this is the first I've heard of it from you. I suggested it to you very early in the thread that you originally began in alt.audio.minidisc nearly a week ago. Maybe it wasn't that long ago but it's begun to feel like it. :-) Bob -- "Things should be described as simply as possible, but no simpler." A. Einstein |
#17
![]() |
|||
|
|||
![]() Erwin Timmerman wrote: That seemed strange to me all along with all the varying playback levels that can occur. And indeed now it shows that the effect is dynamically applied. Thus changing the volume of a wave file does nothing but change the ATH level with it. No difference whatsoever. No frequencies kicked out. End of story. To be fair to Myke, it shows that his hypothesis does in fact make sense and has long been a major consideration among the codec developers. Perhaps he is using an older version of Lame in which it was in fact a fixed function and he can perceive the subtleties involved. A little research, however, would have shown that he was reinventing the wheel. Bob -- "Things should be described as simply as possible, but no simpler." A. Einstein |
#18
![]() |
|||
|
|||
![]() |
#19
![]() |
|||
|
|||
![]()
Bob Cain wrote:
It shows that you were on the right track. It also says that if you use a modern version of Lame you will get a more effective application of the principle than you can effect by global level changes of the file since they reconsider and try to optimize the masking thresholds on a frame by frame basis. I absolutely agree with you and I appreciate your honest and fair assessment of my situation. All of this talk about newer versions of LAME has indeed made me excited about upgrading for the first time in 2 years. If it can indeed - with the combined use of MP3Gain - eliminate my perceived need to always normalize my older, quieter WAVs then *great* - as it reduces both the time and effort required to do what I have to do. ![]() Myke -- -================================- Windows...It's rebootylicious!!! -================================- |
#20
![]() |
|||
|
|||
![]()
Well, 89.1% (depending on if that is power or voltage) is about 1 percent
or so below FS. In this context, 100% is referenced to a digital sample value of +/- 32767, which is the maximum level that 16-bit audio can handle, and is commonly referenced as "full scale" or "0 dB". Working backwards from this benchmark, 89.1% represents 1.00 dB below full scale, or "-1.00 dB". That is a good "safety margin" to ensure that no clipping occurs, however, even as far back as 1986, CDs were commonly mastered with peak levels reaching exactly full-scale, or "100%". However, that is only "acceptable" if a SINGLE digital sample is at the 100% mark. If two or more samples in a row reach full scale, that is defined to be "clipping", and on some equipment, it will actually cause a "clip" light to illuminate when that occurs during recording or playback. In order to prevent this while still allowing for MASSIVE increases in loudness, modern "hyper-compressed" CDs typical limit their maximum level to something like 98% or 99%, or -0.1 or -0.2 dB. That way, you can have 10 or 20 samples in a row all "slammed" against this arbitrary limit, resulting in a "hacked-off" waveform that is essentially a square wave -- but since it's not TECHNICALLY "clipping" since it doesn't reach the 100% mark, the proper term for this is "hard-knee limiting" -- which has become so common on CDs within the past decade that it is the NORM... very few popular music CDs are NOT subjected to large amounts of "hard-knee limiting" these days. For more information on this, please see the following well-illustrated web site: http://rvcc2.raritanval.edu/ktek9053/cdpage Note that on this web site, only the term "clipping" is used, because that's merely what "hard-knee limiting" is an euphemism for (sort of like putting extra chrome on a Toyota and calling it a "Lexus"). |
#21
![]() |
|||
|
|||
![]()
Bob Cain wrote:
So *this* is what a train-wreck looks like! ;-) ;-) Not necessasarily. I'm still considering the part that says that mild compression, that I would otherwise avoid, may have a benefit relative to lossy encoding. I was merely kidding with that comment - hence the wink, wink... As for the mild compression... It was not my point to say that compression itself is beneficial to the encoding but rather the higher levels of the entire remainder of the song at the expense of perhaps 5 short peak bursts that seem to me to be more due to happenstance than deliberation. Then again, I am conducting some tests which do seem to confirm Geoff's position on how much of a level boost is required before an aurally detectable difference is produced in the sound of a resulting MP3. At least with these tests I am getting some "hard numbers and examples" which may be useful for supporting his position. At this point I've been using "normalize" to shove the gain down on copies of that "Sunday Bloody Sunday" WAV in -5dB increments to see how far down I have to go before it flatlines. At -40dB it's just barely identifiable. At -50dB it's no longer there. Encoding 128kb/s MP3s of it at -5dB, -10dB, -15dB, and -25dB down from it's original level and then importing the MP3s and amplifying them back to just under Full Scale with Audacity reveals no appreciable difference at least to my ears - even though the animated close-ups I've been able to create from various screenshots of these "loudness-restored" WAVs do reveal visual discrepancies. Then again, (1) I'm not listening to these WAVs with expert ears, (2) I'm probably not using good source test material, and (3) I still don't know if my version of notlame (which uses the LAME v3.70 engine) uses fixed or relative ATH positioning. I downloaded and installed a Linux sine tone generator and have been able to get it to play some tones, but it's idea of "writing to a file" on the hard drive involves dumping values to a text file instead of creating a WAV file with which I can conduct more appropriate tests. And, yes, I do recall the R.A.P. 5 suggestion... Myke -- -================================- Windows...It's rebootylicious!!! -================================- |
#22
![]() |
|||
|
|||
![]() "Lord Hasenpfeffer" wrote in message At this point I've been using "normalize" to shove the gain down on copies of that "Sunday Bloody Sunday" WAV in -5dB increments to see how far down I have to go before it flatlines. Mayber it would help to give "normalise" a capital "N", as it is the name of an appplication, and thus aproper noun. It would lead to less confusion, as would them giving it a sensible name in the first place. geoff |
#23
![]() |
|||
|
|||
![]() Lord Hasenpfeffer wrote: Encoding 128kb/s MP3s of it at -5dB, -10dB, -15dB, and -25dB down from it's original level and then importing the MP3s and amplifying them back to just under Full Scale with Audacity reveals no appreciable difference at least to my ears - even though the animated close-ups I've been able to create from various screenshots of these "loudness-restored" WAVs do reveal visual discrepancies. You should at least hear signifigant increases in the noise level when you get as far as -25 dB. Don't you? Or are you working at greater than 16 bits for these trials? Bob -- "Things should be described as simply as possible, but no simpler." A. Einstein |
#24
![]() |
|||
|
|||
![]()
Bob Cain wrote:
Lord Hasenpfeffer wrote: Encoding 128kb/s MP3s of it at -5dB, -10dB, -15dB, and -25dB down from it's original level and then importing the MP3s and amplifying them back to just under Full Scale with Audacity reveals no appreciable difference at least to my ears - even though the animated close-ups I've been able to create from various screenshots of these "loudness-restored" WAVs do reveal visual discrepancies. You should at least hear signifigant increases in the noise level when you get as far as -25 dB. Don't you? Or are you working at greater than 16 bits for these trials? That was *my* assumption to, however, I cannot. Then again, I'm listening to a rather loud rock song. ![]() ever been compelled to stick my ear this close the floor either. So I really don't know what one sounds like. My best guess would be something kinda like the natural electronics noise my sound card makes whenever I turn the volume on my speakers all the way up - only a lot smoother (aka pink noise?). I could not tell an aural difference between any of the attenuated and subsequently amplified MP3s although the visual differences of the original attenuated WAVs is readily apparent - so I know I'm working with the correct set of files. At -25dB, the WAV was as thin as a toothpick in Audacity, yet after reamplification, no difference! That's why I jumped down to -50dB next and discovered it to be "flatlining" or whatever that would be called. "Silent" might be more appropriate - except for the noise of my soundcard at full vol. I went back up to -40dB and could just barely make out the music at full volume. So I reason that somewhere between -25dB and -40dB there *should* be some kind of obvious drop-off point in terms of the resultant MP3 quality but I haven't made it that far in my testing yet. I got so bored with that I went off trying to find a sine wave tone generator that could write a WAV to my hard drive. I found the generator. But it doesn't write a WAV. I kept looking but haven't found anything else yet. Have you a suggestion for a better music source? What besides rock? I could use A.L.W.'s "Phantom Of The Opera"... I could use the obligatory Mozart, "Eine Kleine Nachtmusik" by way of Sir Neville Marriner & Academy of St. Martin-In-The-Fields'... Vivaldi's a favourite. Or how about a little Shoenberg or Berg on Deutsche Grammophon? Or Cage, maybe? I have some Cage. He's usually pretty quiet. ![]() Oh, there's the required "Beethoven: Complete Symphonies" thing put out via Musical Heritage Society. Or how about Elvis? (Presley or Costello, take your pick.) The Sex Pistols? Naaaah. That's getting too far back to where I am right now... Hmmm... Myke -- -================================- Windows...It's rebootylicious!!! -================================- |
#25
![]() |
|||
|
|||
![]()
P.S. And does anyone here object to my use of the non-word "limitize"
when describing the standard behaviour of Normalize in terms of both To me the word "limitize" looks like an unusual way of saying "limiting". It does not look like a shorter way of saying "RMS normalization with limiting". So, yes, I object. If you use "limitize" in this discussion I know what you mean, but if I see the same word used by someone else in another discussion I would probably interpret it as "limiting". I think calling the process "RMS normalizing" is fine. Regards /Jonas |
#26
![]() |
|||
|
|||
![]()
take your favorite piece of music, something fairly rich and compressed
already - i.e. without so much dynamic range. Then take 10 second slices and attenuate each by 5 or 10 db or so, intersperse them with silence. This way you only have to run that 1 file and encode it and you'll have a wide range of volumes right there. Re-boost them back and you're done. I.e. 10 seconds: 0db 5 seconds: silence 10 seconds: -10db 5 seconds: silence 10 seconds: -20db etc. Should be easy to create in any audio program. Regards, Mark -- http://www.marktaw.com/ http://www.prosoundreview.com/ User reviews of pro audio gear |
#27
![]() |
|||
|
|||
![]()
Bob Cain wrote:
You should at least hear signifigant increases in the noise level when you get as far as -25 dB. Don't you? Or are you working at greater than 16 bits for these trials? 16-bit's all I'm working with here. Here are the readings for the 8 source WAVs I've used so far... level peak -18.7053dBFS -5.9999dBFS N01-05.wav -23.7053dBFS -11.0000dBFS N02-10.wav -28.7053dBFS -16.0004dBFS N03-15.wav -33.7048dBFS -21.0011dBFS N04-20.wav -38.7053dBFS -26.0013dBFS N05-25.wav -43.7052dBFS -30.9956dBFS N06-30.wav -48.7052dBFS -36.0054dBFS N07-35.wav -53.7048dBFS -41.0011dBFS N08-40.wav In all 8 cases so far, I've copied an original source WAV, adjusted each copy via "Normalize -g -5dB", "Normalize -g -10dB", etc., on down to -40dB. Then I've encoded each attenuated WAV to MP3 at 128kb/ps. Then I've imported each of the resulting MP3s into Audacity where I've then amplified them up to "-0.5". Audacity shows Full Scale as +/- 1.0 with '0' in the middle, so -0.5 is just slightly below FS. I then save the final decompressed MP3-WAV files back as WAVs to my hard drive. Despite all of this processing, all 8 final WAVs sound "normal" to me. By the time I got to -40dB, I'd have expected the final MP3-WAV to sound pretty crappy but it doesn't - at least not by any degree which I would expect it to sound. level peak -14.0943dBFS -0.9601dBFS N01-05.mp3.wav -13.7098dBFS -0.7672dBFS N02-10.mp3.wav -14.2900dBFS -1.0749dBFS N03-15.mp3.wav -14.1163dBFS -0.9832dBFS N04-20.mp3.wav -13.9006dBFS -0.9975dBFS N05-25.mp3.wav -13.9302dBFS -1.0002dBFS N06-30.mp3.wav -14.1153dBFS -0.9492dBFS N07-35.mp3.wav -14.1134dBFS -1.0802dBFS N08-40.mp3.wav Myke -- -================================- Windows...It's rebootylicious!!! -================================- |
#28
![]() |
|||
|
|||
![]()
Jonas Eckerman wrote:
I think calling the process "RMS normalizing" is fine. I think this is a good term for it as well but I think a few days ago the term "RMS normalizing" caused someone to believe that I was attempting to set the RMS level to -0dBFS. (What a noise *that* would make!) Since textbook-styled "peak normalizing" involves setting the maximum peak level to -0dBFS. IIRC, this caused a major uproar as everybody thought I was a *really* deaf, dumb and blind kid then. ![]() Myke -- -================================- Windows...It's rebootylicious!!! -================================- |
#29
![]() |
|||
|
|||
![]()
Mark T. Wieczorek wrote:
Re-boost them back and you're done. Sorry... Caught it the 2nd time around (post-Send)! ![]() Myke -- -================================- Windows...It's rebootylicious!!! -================================- |
#30
![]() |
|||
|
|||
![]() "Lord Hasenpfeffer" wrote in message ... Jonas Eckerman wrote: I think calling the process "RMS normalizing" is fine. I think this is a good term for it as well but I think a few days ago the term "RMS normalizing" caused someone to believe that I was attempting to set the RMS level to -0dBFS. (What a noise *that* would make!) Since textbook-styled "peak normalizing" involves setting the maximum peak level to -0dBFS. IIRC, this caused a major uproar as everybody thought I was a *really* deaf, dumb and blind kid then. ![]() "RMS normalising" is not sufficient is one is implying that limiting or compression is also being applied to prevent the otherwise likely clipping. geoff |
#31
![]() |
|||
|
|||
![]() "Lord Hasenpfeffer" wrote in message ... Bob Cain wrote: You should at least hear signifigant increases in the noise level when you get as far as -25 dB. Don't you? Or are you working at greater than 16 bits for these trials? 16-bit's all I'm working with here. Here are the readings for the 8 source WAVs I've used so far... level peak -18.7053dBFS -5.9999dBFS N01-05.wav Stop right there ! In the interests of not confusing people even further, dont't label the first column 'level" . Label it correctly - "Average RMS level". geoff |
#32
![]() |
|||
|
|||
![]()
Mark T. Wieczorek wrote:
etc. Should be easy to create in any audio program. Definitely easier. Thanks. I tried attenuating the segments with Audacity this time and got dramtically different (i.e. noticeably worse) results with each post-encode reamplification. There was a big difference especially between what I believe (from memory) were the -20dB and -25dB segments. I then listened back to just the first and last segments and could tell a definite difference in the clarity of the vocals - but this is not a time during which I can really pump it up for better detection of artifacts or whatever. I'll have to continue later. Interesting to see how Audacity's concept of a -5dB is so much more severe than Normalize's. I guarantee you I was getting virtually identical results everytime when I was attenuating with Normalize and reamplifying with Audacity. But with Audacity alone, things were noticeably different at each step along the way. This Normalize seems to have some rather odd properties about it. I'm starting to get the impression that what equates to -10dBFS RMS to me using Normalize ain't nothing like what -10dBFS RMS means to you guys using CoolEdit Pro or whatever. I sure am wishing there was another Normalize user in here with whom I could compare results because I'm *really* at a loss now to explain the differences I have now witnessed. Myke -- -================================- Windows...It's rebootylicious!!! -================================- |
#33
![]() |
|||
|
|||
![]()
Geoff Wood wrote:
level peak -18.7053dBFS -5.9999dBFS N01-05.wav Stop right there ! In the interests of not confusing people even further, dont't label the first column 'level" . Label it correctly - "Average RMS level". Sorry. That's what the program itself displays in my shell as it's running. What you're seeing is exactly what I'm seeing. Perhaps this is why the first time you asked me if I knew what "Average RMS level" meant, I said "no" when really I apparently did by way of experience; just not by name. Myke -- -================================- Windows...It's rebootylicious!!! -================================- |
#34
![]() |
|||
|
|||
![]()
Lord Hasenpfeffer wrote:
Despite all of this processing, all 8 final WAVs sound "normal" to me. By the time I got to -40dB, I'd have expected the final MP3-WAV to sound pretty crappy but it doesn't - at least not by any degree which I would expect it to sound. What does this tell you? Exactly. Good to learn a thing or 2 though about the background process. But the end result doesn't seem to suffer as much as you've thought. If 40 dB doesn't matter much (although I'd say that amount should even matter with uncompressed 16 bit audio!), think about how insignificant a change 5 dB would make to the sound. As a side-topic: on your own web site you write: "MykecEdit, MykecView and all original content used to render this webpage is copyright 2001-2003 by Myke Carter. All rights reserved. Unauthorized duplication and/or use of any content contained herein is a violation of applicable laws and just plain rude, so don't do that" I hope you will treat your generated mp3's the same way, as far as the original copyright owners are concerned... Erwin Timmerman |
#35
![]() |
|||
|
|||
![]()
This Normalize seems to have some rather odd properties about it.
Just looked up the docs. There are some things about your Normalize application that makes it different from the majority of simple normalizers used by CD rippers. If anyone else is interested in reading about what the app does, the docs are at: http://www1.cs.columbia.edu/~cvaill/...ze/README.html This text shows that the application does in fact not "normalize" based on a file's (or batch's) RMS. It does some more stuff in an effort to not completely destroy the sound. Quote: --8-- The volumes calculated are RMS amplitudes, which correspond (roughly) to perceived volume. Taking the RMS amplitude of an entire file would not give us quite the measure we want, though, because a quiet song punctuated by short loud parts would average out to a quiet song, and the adjustment we would compute would make the loud parts excessively loud. What we want is to consider the maximum volume of the file, and normalize according to that. We break up the signal into 100 chunks per second, and get the signal power of each chunk, in order to get an estimation of "instantaneous power" over time. This "instantaneous power" signal varies too much to get a good measure of the original signal's maximum sustained power, so we run a smoothing algorithm over the power signal (specifically, a mean filter with a window width of 100 elements). The maximum point of the smoothed power signal turns out to be a good measure of the maximum sustained power of the file. We can then take the square root of the power to get maximum sustained RMS amplitude. --8-- I think that if you will ever again enter a discussion where the behaviour of this application is a fundamental piece of the puzzle, you should post a link to the applications documentation so that other participants have a chance of knowing what it's doing with the sound. If we had all known what the apps documentation says, a lot of misunderstandings might could have been avoided. Another important quote from the docs: --8-- Please note that I'm not a recording engineer or an electrical engineer, so my signal processing theory may be off. I'd be glad to hear from any signal processing wizards if I've made faulty assumptions regarding signal power, perceived volume, or any of that fun signal theory stuff. --8-- This is probably the reason why some audio terms, as used by the author, isn't used the way we're used to. It is also a good hint that the reader of those docs should not take the docs as a source for knowledge about terms used for audio/signal processing. Regards /Jonas |
#36
![]() |
|||
|
|||
![]() "Lord Hasenpfeffer" wrote in message ... P.S. And does anyone here object to my use of the non-word "limitize" when describing the standard behaviour of Normalize in terms of both its default -12dBFS and my preferred -10dBFS RMS-normalization operation? Let's don't pollute the waters any more than we have to. g I think "RMS normalization" is the most standard. DM |
#37
![]() |
|||
|
|||
![]() "Lord Hasenpfeffer" wrote in message ... Jonas Eckerman wrote: I think calling the process "RMS normalizing" is fine. I think this is a good term for it as well but I think a few days ago the term "RMS normalizing" caused someone to believe that I was attempting to set the RMS level to -0dBFS. I don't really recall that. You would most certainly have had a mountain of angry people knocking on *that* post. If I missed it... ah well, this is getting long. (What a noise *that* would make!) And as I'm trying to say, even though not so destructive, limiting does make a sort of 'noise', albeit low in level and not always readily audible it still effects the perception, alters the sound and fatigues the ear. -- David Morgan (MAMS) http://www.m-a-m-s.com http://www.artisan-recordingstudio.com |
#38
![]() |
|||
|
|||
![]() "Jonas Eckerman" wrote in message ... Replying to myself again: I think calling the process "RMS normalizing" is fine. After reading the docs, I've changed my mind. "RMS normalizing" or "RMS normalizing with limiting" is not enough to convey what the app does. Quoting the documentation or providing a link to it is nessecary. The authors explanation or what the app does: http://www1.cs.columbia.edu/~cvaill/...DME.html#AEN88 Regards /Jonas I won't be specific, but I have a few quibbles with the 'presentation' of this FAQ, mostly in use of terminology and vagueness of applying calculations. |
#39
![]() |
|||
|
|||
![]() "Lord Hasenpfeffer" wrote in message ... Interesting to see how Audacity's concept of a -5dB is so much more severe than Normalize's. I guarantee you I was getting virtually identical results everytime when I was attenuating with Normalize and reamplifying with Audacity. But with Audacity alone, things were noticeably different at each step along the way. This is why my initial thoughts were to experiment more and with more software... certainly more with your ears. I sure am wishing there was another Normalize user in here with whom I could compare results because I'm *really* at a loss now to explain the differences I have now witnessed. There are all sorts of 'normalize' users in here who understand corruption, but perhaps not so many "Normalize" users. I, for one, am simply glad that you are experimenting and listening. DM |
#40
![]() |
|||
|
|||
![]() "Jonas Eckerman" wrote in message . 1... Another important quote from the docs: --8-- Please note that I'm not a recording engineer or an electrical engineer, so my signal processing theory may be off. I'd be glad to hear from any signal processing wizards if I've made faulty assumptions regarding signal power, perceived volume, or any of that fun signal theory stuff. --8-- This is probably the reason why some audio terms, as used by the author, isn't used the way we're used to. It is also a good hint that the reader of those docs should not take the docs as a source for knowledge about terms used for audio/signal processing. A-hah! I see that I'm not the only one who appears to believe that there's a little 'voodoo' going on here. ;-) It's kinda funny, the first paragraph that you qouted (I didn't repeat it here) from the document, is exactly where I stopped reading it, came back and stated that I didn't quite buy the terminology. DM |
Reply |
Thread Tools | |
Display Modes | |
|
|
![]() |
||||
Thread | Forum | |||
Humming Sounds From Speakers just keeps getting louder? | General | |||
Lossy Compression | General | |||
Lossy Compression | Audio Opinions | |||
Subwoofer direction | Car Audio | |||
Advantage of tape over MD? | General |