In response to a particular user request, I created a special version of WaveGain that performed the analysis phase extremely fast.

There is no magic at work here, the deal was this: instead of analysing the whole file, which can be time consuming, the analysis is performed on 200 reads of 16k samples/sample pairs read at even intervals through the middle 80% of the file. The 10% at the front and end of the files are ignored. Clearly, in the purest sense, this breaks the Replaygain principles; however, on the testing that I've performed, the vast majority of files processed showed an analysis result that was within 0.5dB of the result of the full analysis. Therefore, if analysis speed is of the essence, the cost in terms of accuracy is minimal.

If anyone sees a widespread use for this facility, I'll add it as a 'Fast' option to the standard WaveGain. I may add it anyway, I guess I'm really just asking whether anyone other than the original requestor is interested in this.

I'd be interested in a fast wavegain like this Sometimes the problems I have with Replaygain principles is that often the 'loud' part of a song is in the middle, and the quiet parts at the beginning and ends throws it off, IMHO.

foo_rgscan uses an ASM optimized version of the replaygain routines, maybe you could use those for another (insignificant - according to DEATH) speed up:
http://foobar2000.org/SDK.zip

If 1.5dB is good enough for MP3gain's resolution, 0.5dB is good enough for WaveGain, IMO. I'd use this instead of the whole-file analyzer just to speed things up, just for the hell of it. Cool idea.

Do you have more statistical analysis? Maximum difference, mean difference, std. dev, etc.?

So there is some interest.

Here is a link to the version I supplied to the requestor: http://homepage.ntlworld.com/jfe1205/wglite.zip. This version only performs the high speed analysis. If you guys would care to give it a test, and you think it's OK, I'll merge it in as an option. Obviously, if you choose to apply the gain, then that part of the program runs as before in respect of performance.

I like the every other group of samples thing, but I don't know about the middle 80% thing. If you're a MP3 + CUE person, this can get a little innaccurate.

I take your point and maybe it is not appropriate in that situation. However, the idea behind this was that in the situation where only a limited number of samples are to be used for analysis then those samples should come from the main body of the file/title and not from the start and end where there may be fade-in/fade-out that would be unrepresentative of the overall volume levels.

My suggestion is to also scan the file for the highest sample to guarantee that clipping will not occur if positive gain was needed to achieve the wanted average level.

Within the part of the code concerned with applying the gain, + or -, there is active clipping prevention. However, the analysis phase within the high speed version only looks at peaks occuring within the chosen sample chunks. I understand your concern, but to scan the entire file looking at peaks is part of the analysis phase within the standard WaveGain application. If you use the high speed version for the analysis and then use a different application to apply the gain there is indeed a risk that this other application may allow clipping.

If this is a major concern, then use the standard application. In England, there is a saying - "You pays your money and takes your choice".

Great idea john!

I used something similar when first developing ReplayGain, because my code was just too slow to keep re-processing whole tracks and albums! It worked very well most of the time.

There were predictable failures - on some of the tracks on the EBU SQAM CD, ReplayGain only happened to see the silence between extracts, which didn't quite give the desired ReplayGain value!

However, most of the time it works very well. As for clipping prevention, if you're going for maxnoclipgain it'll be right a lot of the time, and wrong some of the time - but if you're using a conservative target volume (remember I started with 83dB, which is very safe), you're unlikely to clip even without clipping prevention, so this fast method does no harm.

Cheers,
David.

Thanks for that, David.

I think in the circumstances I'll merge this up and present it as a 'Fast' option. I'll add a comment in the 'Help' that says that this mode may not produce the desired level of accuracy with some material.

I have now posted WaveGain v1.1.0 at Rarewares. This fast mode is included as an option activated by adding '-s', or '--fast' switches, but see the Help info.

Edit: BTW, because of the reading strategy used for the fast mode, files of 8mb, or less, are processed in the normal way.

There's a shareware mp3 normalizer program that has this feature. I just learned of it recently. It's obviously based on MP3Gain, but it has several extra features. Most notable of those extra features is a variable speed adjustment, "up to 10 times faster than conventional products" (presumably by examining 1/10 of the data).

Sorry I didn't bring it up 'round these parts when I first found it. I'm not planning on adding such a feature to MP3Gain, but I should have thought that the other ReplayGain implementations might be interested in the idea.

http://mp3br.com if anyone's interested.

-Glen

Hi All,

As the requestor at the start of this thread, I felt that as nearly 3 months of continual use has gone by in a broadcast environment, I would add my comments to all of the above.

WGLite has worked out remarkable well! Level balance is in fact much tighter than the quoted 0.5dB error (measured using BBC Peak Programme Meters). It is extremely fast and we are indebted to John33 for his work.

The only thing we don't do, is to actually modify the file itself. The level is read during the track loading/CD rip and the players replay volume is automatically set according to the returned value from WGlite.

Many thanks John,

Steve

Thanks for the feedback, Steve. Always nice to know when something works out well, rather than the other way round!!

Does that mean that ReplayGain is now being used within the BBC?

Or within a radio station that uses the BBC PPM standard?

Any chance of letting us know which one?

(john33 - do you know - since Steve Grant might not check back).

Cheers,
David.

He did tell me in the original mail he sent which, unfortunately, I no longer have. IIRC, it wasn't as grand as the Beeb itself, I think it was a hospital radio service, but I'm happy to be corrected on this. If Steve doesn't check back here I'll mail him and ask the question.

David, we are a Hospital Radio service. However all the technical functions of the station are to the highest broadcast standard. All output is monitored with PPM's, at the risk of starting a level reading debate, VU's tell you something is happening, PPM's tell you what.

Wglite is used primarily on the second (non-Presenter) channel and we needed a way to control levels, but didn't want to feed everything through compressors.
We achieve a well balanced signal, that still possesses all the qualities of the original recording. Mainly MOR/Instrumental on this channel, so the sources are not too compressed already.

Thanks for the interest,

Steve.

Thanks for getting back, Steve. I'm happy to know that my memory hasn't completely failed me, yet!!

Actually, why not compute replaygain values in lazy background mode, always when playing the track, keep gathering the RG data, then if user wants, show it right away, or if configured, update the track data - after the track ends. Sooner or later, all tracks will be RG'ed without any special waiting, and next time around, its RG values can be used.
Not suitable for broadcasters, but for normal users, would work nice I guess.

mind you, we're talking about WaveGain here. do you store your music in wav foramt?
so you have to use WaveGain most probably prior to encoding.