I have auto gain on and i play a new song like black eyed peas "hey mama" and it is very loud.

i play an older song like michael jackson "lady in my life" and it is very low.

i know that the science of auto gain is not simple, but it does not work very well.

what is auto gain doing sonically ?

Current auto-gain routines are It's very "rustic", I confess.

It does nothing sonically. It just checks the vu-meter bars: if the volume is being clipped, it lowers the gain. It also checks for the maximum vu-meter value of the whole song. If it is too low, then increases the gain.

I plan to improve the auto-gain routines by implementing the "Replay Gain" standard. It is very accurate but consumes *A LOT* of CPU. It will be optional, of course.

Regards,

Use MP3gain to have the same volume for all your MP3, it works really good without giving damage to your MP3 files.

High CPU usage = no good

I guess you can look at the meters while cueing the song and adjust your gain on the mixer before mixing in.

MP3Gain is the ultimate lifesaver!!  We've been using it since the first version and could not live without it.  Our current library of over 12,000 "canciones" (songs) is widely varied as far as "playback" volume is concerned and this program will allow a "volume balanced" playback of any combination with no loss..  This is NOT standard "normalization".

If you haven't tried it... you should.

Edy... if you actually do implement replay gain (to heck with how much power it needs)... how much "look ahead" will it have?

Note that mp3Gain is actually an implementation of the Replay Gain standard.

The "look-ahead" would be the same as the buffer size (normally around 80ms), as the Replay Gain would be implemented inside the main audio chain. Actually, the auto-gain feature in Deejaysystem works this way (this is regardless of the specification used):

1. The first time a song is played Deejaysystem starts collecting volume data, and it adjusts the volume according to the available data.
2. The next time the song is loaded Deejaysystem 'remembers' the last volume data and sets the initial adjustments according to them. More data is collected, so the adjustments are 'refined' continuously according the available data, and the new information is saved for the next time.

In summary, when Deejaysystem implements Replay Gain it will be like a mp3gain in real-time.

Yes, I understand what the MP3Gain program is based on.  And, while I realize nothing will ever really replace a very expensive "external" limiter/compressor (which few of us can afford) anything that will help maintain a "constant volume level" helps.  To bad most "software" based limiter/compressors cause discenable "pumping" (soft knee or not).

So... what you are saying is that when the new system is included and implemented sometime in a future version that in order for it to work "well" the entire library would need to be played completely through in order to pre-establish values???

Well, I don't think it to be so "dramatic".

With the scheme I'm designing Deejaysystem could handle the right volume for a brand-new song within the first minute of playback. It won't be a typical software limter/compressor, but a kind of 'smart' volume estimator. As more of the track is read, there is more info on it, and thus the volume can be modified with more accuracy.

This design has two main goals:

• The software must be able to play a completely new song in auto-gain mode without previous analysis.
• The user must be able to use the player with auto-gain without any action other than enabling the "auto-play" button.

Some softwares (like Traktor) performs a full analysis of each new song at the time it's loaded, with takes a considerable time to open the track. I don't like this policy, as it may be quite annoying when one has to quickly listen to lots of new songs (i.e. when choosing the songs for our session from a never-played-before library).

I may consideer in the future to add a option for manually analyze songs. When invoked, this option would perform a complete analysis of a group of songs (database, folder...) so the process would gather as much info as if the songs had been fully played. Of course, this process may take a lot of time.

Greetings,

>I may consideer in the future to add a option for manually analyze >songs. When invoked, this option would perform a complete analysis >of a group of songs (database, folder...) so the process would >gather as much info as if the songs had been fully played. Of >course, this process may take a lot of time.

Without a doubt... probably exactly the same amount of time it would take to run the same batch through MP3Gain... since it would be primarily that same algorithm.  However, if your routine simply puts the "markers" from the analysis into the DB and controlled the out gain based upon that... it would run in half the time (of MP3Gain) since the mods would not have to be written out to the audio file itself.  vewy intewesting <grin>

BTW and for anyone who wants to know... using MP3Gain on a flatout  3.2 gigahertz machine... it takes about 3.5 hours to analyse and process about 4,000 tracks  (half of that time is analysis)

Exactly. The mp3 file is not modified. The gain data is stored at the database, which is applied on each track.

Hey, could you please perform a small test for me? I'm curious about the performance of the ReplayGain algorythm and its real-time capability. The testing I'd need is: take a typical long song (around 10 minutes) and use mp3gain on it. I want to know the time taken by the analysis phase only.

This way we would know an estimation of how much CPU the algorythm could take in real time. For instance, if the analysis time is 1 minute for a 10 minutes song, then the algorythm would take a 10% CPU when used in realtime playback.

Your current results (1.75 hours analysis time for 4000 tracks) means around 38 tracks per minute, so we can expect than the CPU time will be more than affordable when using Replay Gain.

Greetings,

Actually I ran a couple of tests, but on a slightly slower and more "normal" machine (2.2gigahertz) since the first tests [run on a highly tweaked 3.2 machine] were not realistic.  These tests should be more indicative.

First I chose a single 19:29 minute MP3.  With stopwatch in hand, analysis took 15:02 seconds and writing the tag took an additional 3:58 seconds.

Then I took a complete Alejandro Fernandez CD containing 13 tracks (see track list below) with a total run time of 55:22 and the results were:  Analysis of all tracks 46:10 seconds, writing all tags 14:31 seconds.

Keep in mind that if you write the tags like Glen Sawyer does (which I assume you would have to) when new tracks are added to a master list, if your code detects the replay gain tag you can have it skip those tracks that have already been modified.  True, the first time through might take a while but after that it should fly.

Yes, I understand that writing the "tags" to the DB should be faster than actually updating the MP3 tags.

Then again... trying to do this, in real time, might put one heck of a load on slower CPUs

-jack-

Wow, that means that performing the analysis realtime in one track would consume around the 80% of a 2,2Ghz CPU.

The replay-gain specification applies a 10-order infinite response filter (IIR) to the waveform. A 10-order IIR filter means 20 float-point multiplications per sample and per channel. An stereo waveform would receive 40 multiplications per sample. A sample rate of 44100Hz means 44100*40 = 1,76 millions of floating-pint multiplications per second.

It seems it's currently too much to real-time processing. A 2,2Ghz CPU wouldn't be able to process two tracks with replay-gain at the same time.

Althought I'll probably implement replay-gain anyway (I think mp3gain performance could be greatly optimized) I'm also exploring other possibilities of real-time normalization. I've found another approach based on RMS power that could perform a nice normalization (not as much quality as replay-gain) with very little CPU usage.

Greetings,

Like I said.. while realtime "normalization" (we both know that's not quite the correct term) is a wonderful concept.. it is, and would be, processor intensive.  However, the "idea" of pre-analyzing a "master list" and wrtiing the gain info to a data base rather than directly to the MP3s has merits.  Especially if one could pre-analyze CDs.

I know that everyone does things a little differently but I must assume that many build their playlists from MP3's stored on the same computer (or accessed from the same computer) as the playback software resides on and all those tracks could easily be pre-analyzed at a convenient time just as one would with MP3gain.  However, the possiblity that a situation might arise where a track (or tracks) from a CD might need to be injected into the playlist opens up the need for those tracks to be pre-analyzed (as a background operation) before they are queued (either in sequentail or random modes).  At least by using a DB to store the info this might be possible (even if the data for the "immediate" CD was only stored temporarily).

The major benefit of using the DB (as far as I can see) is that it could be applied to more "sources" than simply MP3s.

The person who can come up with a "real time" gain normalizer that is more than just a brickwall "limiter/compressor" will be cheered by many <grin>

Well, I don't like the "background analyzing" concept. I think it it's very important the player not to do anything that it's not expected to. If new tracks of a CD are injected in the playlist, it doesn't mean that they all will be played inmediately. What if the medium is slow and the performance of the entire computer drops while all songs are being pre-analyzed?

I think it's better to perform the analysis real-time, even if the quality is not as good as mp3gain. Current method is very basic, and high-quality methods are quite CPU intensive. So the solution may be to implement two or three methods with different qualities/cpu requirements so the user could choose which one he wants.

Greetings,