Hello everyone, Let me first introduce myself, I am Vittorio Colao and I am developing ReplayGain support for Mixxx in features_replaygain branch. What I do in my life is writing theorems when I'm lucky. Teaching math at an italian university otherwise. So, expect my code to be not so precise as it is for hobby. The same can be said about my skill in english. I rarely write something which does not begin with "Let E be a Banach space…" ;) To be more precise, I do my work in that branch of Nonlinear Analysis called Fixed Point Theory. That is, do not ask me to solve some math problem if you are not ready to receive "Can you translate it into a fixed point problem?" as an answer ;)
I'd like to say *Thank You* to both RJ Ryan and Sean M. Pappalardo. The first one because of the impressive amount of things I could learn from him in a less-than-15-minute IRC chat and Sean for his always polite and constructive critics and suggestions. That really helps. Thanks again! I currently use mixxx in a very basic way. That is, I use it to play music at metal/hard rock parties or after shows. This usually involves just mix properly the end of a track with the beginning of the next one ( I could be killed by other headbangers if I just try to introduce something new in a track or if I stop it before that "epic solo") or looping in some part to allow people screaming more and more that part. When I use mixxx, one of the tasks which takes me a bit of time is that of leveling sound because of different registration volume levels ( look here http://en.wikipedia.org/wiki/Loudness_war for the problem ). If you try to compare volume levels of a track from early '90s and an actual one, you may understand on what problem I am writing of. That is why I thought in implementing ReplayGain in Mixxx. When I wrote it, main idea has been that of "reset loudness level" and use a newer one which allows every track to sound at the same volume level. One can argue on using a dynamic compressor between Mixxx and PA. But in my opinion, compression "flatten" the sound, while (pre)normalization do not alter the track at all. On the other hand, ReplayGain is more than "normalizing" a track. I mean, one may normalize a track in different ways. The very basic one is "Peak-to-Peak", that is what Sean implicitly use. It consists on leveling maximum peaks of tracks so that all tracks have the same maximum peak (or if you prefer, they are all just before clipping). By using this method, one faces a big implementation-by-nature in human perception (that is why one has to act on volume faders to level sound). Nature developed us to be more sensitive on high frequencies, that is we perceive as louder a signal at say 1kHz than one at say 500Hz (you may test such feature here: http://www.phys.unsw.edu.au/jw/hearing.html ) despite dB. That's where ReplayGain comes into play: by filtering signals by mean of an equal-loudness filter, it gives the right weight to frequencies and let human ears perceive two tracks as at the same level. This may not work if you are not human. For this last, one may think to develop a say Klingon-equal-loudness. But this is future work, if I can only find a Klingon :D Well, that is because I thought that it was better for ReplayGain thing to act transparently on pregain: it is "substituting registration volume level with a default one which takes in consideration human perception and let all tracks loud the same". On the other hand, "Peak-to-Peak" can be easily implemented: a lot of soundfiles coming with a ReplayGain tag, have a "replaygain peak" tag which is nothing than its maximum relative peak. The same can be easily calculated by the analyser. I thought a bit if I could implement this kind of normalization too before 1.9 release. Unfortunately I cannot. There is no exotic reason. The only one is that on October 25 I start teaching in 4 classes, so that I'd like to use my spare time on bugfixing my branch and for it to stay up-to-date. Anyway, even this feature is an easy-weekend one. So maybe I can find that weekend and implement it too. Last words are for skin/controllers mapping developer. As for now, ReplayGain implementation is due for 1.9 release (planned for December). I added some new COs and I think it would be awesome if they could be mapped to some led/output. This is related to ConfigKey(group, "replaygain") which defaults to 0 when there is no replaygain value associated with a track or outputs a nonzero value(i.e. the replaygain adjustment) when found/calculated. It is ok for me to be contacted by mail, PM on forum, IRC chat or telepathy if you are an alien ( in this last case, please send me an equal-loudness filter proper for your people :D ) I am confident on my branch to be usable. That is I am going to perform live using it. I will really appreciate any test/comment/critic/bugfixing/encouragement. Thanks for reading, Vittorio > > I would prefer ReplayGain to be an effects send. If you want it, turn > it up. If not, turn it off. > > This business with adjusting volume faders seems counter to what you > would want on stage. > > On Thu, Oct 21, 2010 at 2:48 PM, Albert Santoni <[email protected]> wrote: >> Hey Sean, >> >> Thanks for pointing this out. >> >> When I mix, I use the gain knob to "normalize" the volume of the track >> so that when the volume sliders are maxed out, both songs have roughly >> the same volume. This makes mixing with the upfaders easier, but maybe >> I've been doing it all wrong. The method you described sounds like >> what you'd use for audio production mixing, which I had never thought >> about before. >> >> I believe the two DJ mixers I've used both have max volume slider as >> unity though. ie. The volume sliders don't boost. I think this makes >> it easier if you don't know what you're doing but maybe there's >> another reason for it. >> >> Albert >> >> On Thu, Oct 21, 2010 at 6:03 AM, Sean M. Pappalardo - D.J. Pegasus >> <[email protected]> wrote: >>> Hello everyone. >>> >>> Vittorio and I have been discussing his ReplayGain branch. Its purpose >>> is to prevent differences in track loudness by normalizing the levels of >>> all tracks. (This is what ReplayGain is all about.) >>> >>> Currently the ReplayGain value is read from tags (or calculated if not >>> present) and applied transparently, before the Gain and Volume >>> sliders/knobs on the skin. This results in the average volume of the >>> tracks being around the center of the (pre-fader) channel VU meters (if >>> no initial boost is applied.) >>> >>> This bothers me because, in the analog world at least, you want to >>> maximize the dynamic range of the input stage by adjusting the pre-fader >>> gain so that the signal is as high as possible but not clipping. (You do >>> this by increasing the gain until you see clipping then backing it off >>> slowly until the clip light no longer illuminates.) Then you use the >>> volume/level fader to adjust the channel's relative volume in the >>> overall mix. (So if a channel is quieter than another, its volume slider >>> gets raised above that of the louder one.) I do this in sound >>> reinforcement scenarios, when I DJ with my analog mixer, and when DJing >>> with Mixxx (all have pre-fader channel VU meters.) >>> >>> Given all that, it makes the most sense to me for the following to occur: >>> 1) Peak-detection finds the loudest transient in the track and >>> automatically adjusts the (pre-fader) Gain knob so that that loudest >>> transient is just below clipping. >>> 2) ReplayGain value is read/calculated and automatically adjusts the >>> deck _volume_ slider to compensate for the volume difference. In order >>> for this to work well, the volume sliders would need to default to >>> something other than 100% so there is somewhere to go in either >>> direction. (Maybe 75%?) >>> >>> (Note that this has nothing to do with the master output level, which >>> should only be controlled by the DJ to adjust the main overall floor >>> volume as needed.) >>> >>> Also, I plan on implementing soft-takeover for MIDI controllers that >>> have physical knobs & sliders so the auto-adjusting won't be a problem. >>> >>> Let me know what you all think. Thanks for your attention. >>> >>> Sincerely, >>> Sean M. Pappalardo >>> "D.J. Pegasus" >>> Mixxx Developer - Controller Specialist >>> >>> ------------------------------------------------------------------------------ >>> Nokia and AT&T present the 2010 Calling All Innovators-North America contest >>> Create new apps & games for the Nokia N8 for consumers in ?U.S. and Canada >>> $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing >>> Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store >>> http://p.sf.net/sfu/nokia-dev2dev >>> _______________________________________________ >>> Mixxx-devel mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/mixxx-devel >>> >> >> ------------------------------------------------------------------------------ >> Nokia and AT&T present the 2010 Calling All Innovators-North America contest >> Create new apps & games for the Nokia N8 for consumers in ?U.S. and Canada >> $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing >> Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store >> http://p.sf.net/sfu/nokia-dev2dev >> _______________________________________________ >> Mixxx-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/mixxx-devel >> > ------------------------------------------------------------------------------ Nokia and AT&T present the 2010 Calling All Innovators-North America contest Create new apps & games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev _______________________________________________ Mixxx-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mixxx-devel
