With v1.2.4, all header data was copied through to the processed file including ‘bext’ and ‘cart’ chunks. As of this version, all trailers are now also copied through regardless of content. This ensures that any chunks appearing after the ‘data’ chunk are not lost as a result of ‘wavegaining’ the file. These changes have been implemented primarily to meet the needs of the broadcasting industry but will have no impact when processing regular wave files that contain the minimum chunk requirements.

Source and executable are at Rarewares now.

Is it possible to make correction of DC Offsets independent from gain processing in 1.2.6? This would be useful for me in this special case:

I have two (or more) files with different Gain and DC Offset but perfect silence at their start and end (zero-lines there). If I want to change Gain for every track, DC Offsets are also processed. Silence at track borders is now at different (DC-) level. Now I'm merging the two files with CueMake and burn them gapless with CUEsheet. Because of the changing DC-level at track border there is a "click" between them.
To avoid this, I have to change DC Offset for the whole album but gain for every track.

Thanks in advance ...

... and sorry for bad English.

John, thanks a lot!
Seems to work great on Mac OS 10.4...

@Surfi: I'll look at providing the option to switch DC correction off.

@krmathis:

I've been playing with the WaveGain code a little, and made a very useful addition (I think). It adds user command execution after wavegaining. It adds the following option (which must be placed last on the command line):

-e, --exec Cmd - Execute a command after WaveGain

The following environment variables are available:
INPUT_FILE, INPUT_FDIR, INPUT_RDIR, INPUT_NAME,
TRACK_GAIN, TRACK_PEAK, TRACK_SCALE, TRACK_NEW_PEAK,
ALBUM_GAIN, ALBUM_PEAK, ALBUM_SCALE, ALBUM_NEW_PEAK,
DC_OFFSET_L, DC_OFFSET_R.

Note that when using recursive file seach (-z),WaveGain processes files from the directory where the file is located, and therefore the INPUT_FILE and INPUT_FDIR variable reflects this. However, INPUT_RDIR will always contain the path from the working directory to the file (useful for building an output path). INPUT_NAME is the file name without directory and extension. Example to write log of output:
However, it is most useful for launching an encoder, and e.g. using --scale option, or setting RG tags, using the environment variables shown above.

@john33, if you like it, please use this for your next version. BTW: I did remove the setting of codepage inside the program. I don't like that my code page is changed by running a tool. You can always set it with the chcp console command if you need it.

Get wavegain-1.2.5.E3.zip and the wavegain-1.2.5.E3src.zip here.

History:
- 1.2.5.E3: %TRACK_PEAK% %ALBUM_PEAK% is normalized to 1.0
- 1.2.5.E2: You may specify a relative path to an executable given by -e.

Here's a more useful example:

You can also set up various batch files to launch from the -e option. For example if you want to store your mp3's in a different root folder (edit: now tested. Make sure to specify an absolute path to encode.bat):

Looks very interesting, thanks. I'll take a closer look, but I'll almost certainly take up your offer, thank you.

A small update in 1.2.5.E2, so that you can specify a relative path to a executable (or bat file). I.e. if you have encode.bat in your current console directory, you may write:
WaveGain -a -z *.wav -e encode.bat

Thanks John. This would be a a first step but maybe you can implement this in a different way.

We have three variables DC-Offset, Gain and Mode (Album or Track).

For every Mode there's 4 possible combinations of Gain and DC-Offset, 3 to make program execution necessary:

Gain c. | DC-O c.
-----------------
0 | 0 (makes no sense, no need to run program)
0 | 1
1 | 0
1 | 1


Due to the "clicks" I reported in my earlier post, there should be an option to run DC-Offset correction in Album[a]- or Track[t]-Mode too. This will lead to 8 possible combinations:

Gain c. | DC-O c.
-----------------
0 | 1[a]
0 | 1[t]
1[a] | 0
1[t] | 0
1[a] | 1[a]
1[t] | 1[t]

1[a] | 1[t] (preserves relative volume with the risk of "clicks")
1[t] | 1[a] (preserves relative DC-Offset)

To avoid these "clicks" you only need to select a combination with DC-Offset correction in Album-Mode. Of course, this only makes sense if you have perfect digital silence at the track borders and want to burn gapless with cuesheet.

I'm not a programmer but finding the correct values for the last two combinations seems not that easy.


Let's have a look at the last one first:

Gain c. | DC-O c.
-----------------
1[t] | 1[a] (preserves relative DC-Offset)

To avoid "clicks", Gain for a track must be applied first but with DC-Offset for the album in mind.
1. calculate DC-O for the whole album
2. calculate Gain for every track
and add half(or full?) DC-O[a]
3. apply gain
4. apply DC-Offset


The other one:

Gain c. | DC-O c.
-----------------
1[a] | 1[t] (preserves relative volume with the risk of "clicks")

This mode is already implemented, isn't it?


Last thing in my mind is an option for an additional manual DC-Offset (like -g for Gain).

These changes would make WaveGain my universal correction util ...
... but it's up to you ...

Thanks for reading.

john33, in 1.2.5.E3 I normalize ALBUM_PEAK and TRACK_PEAK env. vars. relative to 1.0, instead of max sample (32767). Reason is that when tagging REPLAYGAIN_TRACK/ALBUM_PEAK, the values should be like that.

John - thanks for this.

Been playing around with your tool for the first time on some audio ripped from an analogue source (cassette tape).
Can you, or anyone else, provide any links to suggested reading about dithering & noise shaping please? (I found this doc which was quite helpful).

Also, given the audio source, in that there's minimal sound above 15khz, and apart from the amendment to the db level, would applying dither, without or with noise shaping, be of benefit? or is that something I would just need to play around with and listen to the outcome?

Many thanks

Analysis of the file:


EDIT: ok found these papers by Nika Aldrich that I'll take a look at.

I have an issue using WaveGain v1.2.5 with Frontend 1.2 and Multi Frontend (I was previously using WaveGain v1.0.4). If it matters, I'm running Win98se. When I do a radio/album gain calculation, it does the calculation, but immediately afterwards I get the dreaded 'This program has performed an illegal operation and will be shut down' message box with the following info:

WAVEGAIN caused an invalid page fault in module WAVEGAIN.EXE at 01a7:0040863b.
Registers:
EAX=00680078 CS=01a7 EIP=0040863b EFLGS=00010246
EBX=00000001 SS=01af ESP=0066fc3c EBP=0066fc58
ECX=3f22e6ae DS=01af ESI=00790e0c FS=2f97
EDX=00000e10 ES=01af EDI=00000000 GS=0000
Bytes at CS:EIP:
8b 14 31 8d 1c 31 89 55 f4 8b 56 fc 89 55 f8 8b
Stack dump:
00000000 00790e10 00000001 006801bc 00000005 bfd47ad7 3f22e6ae 0066fc70 00406948 0078000c 00790e10 00790e70 00417130 00000000 00404bc5 00790e10

If I do the calculations with the new 'fast' switch there's no problem. Odd?

+++++++++++++++++++++++++++++++

Another situation: I took a newly ripped wav and made 2 copies of it. I did a radio gain calculation of each copy - one with v1.0.4 and the other with v1.2.5 and got the same result. I then applied radio gain to each copy and did a 'Compare WAVs' process with EAC. From start to finish, it said there were different samples in each file. Why would that be? Is it because the newer version of WaveGain uses a different algorithm?

+++++++++++++++++++++++++++++++

Speaking of algorithms, I happened to come across this page today where WaveGain's algorithm was described as being 'brutal.' I don't know what version of WaveGain they were evaluating, but I'd be interested to hear any comments about why the authors might feel that way.

http://www.itconversations.com/wikis/itc/p...?n=Dev.WaveGain

Regarding the error, I'll look into it, but I am looking to release a minor upgrade within the next few days. I should mention that this is the first report I have received indicating a problem of this nature.

The underlying algorithm is basically unchanged, although one fundamental difference between the two versions is that 1.0.4 used libsndfile for i/o whereas the current version uses its own i/o routines. No doubt this accounts for the differences.

Since WaveGain uses the same basic replaygain algorithm as vorbisgain and mp3gain, I have no idea what is meant by the description 'brutal'. It could be that this relates to the fact that the samples are directly changed rather than by adding a tag to the file, or by changing the gain value, as per mp3gain, but I'm only guessing.

tnx, ill look into this soon.

Another question: When calculating gain for a directory of files numerically named (01. song title, 02. song title, etc.), why is it that the resulting log file has the files in a completely random order? Sometimes they'll be in the correct order, but the majority of the time they're not.

Any insight yet regarding that error I receive?

Not directly, however, you may like to try this: http://homepage.ntlworld.com/jfe1205/wavegain-1.2.6a.zip . This does not yet contain any other enhancements.

I am perplexed by the supposed random printing order in the logfile, basically because I cannot see how this can occur!! The logfile entry is written immediately following the console display. The logfile is opened, the entry is appended, and then the file is closed. Oh, and the buffer is flushed for good measure.

I'll give the new version a try and see how I fare. What 'enhancements' do you have planned for the next version?

Regarding the log file, I should have mentioned that the random track order is shown in the console display as well.

Followup Good: I repeated the analysis for several albums, with WaveGain versions from old .96 thru the new 1.2.6a, and in all cases the console display and log file showed the tracks in their correct order.

Followup Bad: Still get the error message at the end of analysis. Let me know anything I can do to help as far as info you might need.

There's another thread running regarding a linux version issue which I think will also address this problem. I'm looking at another couple of things before another release, but it shouldn't be more than a few days. Thanks for your patience!!

Please see here: http://www.hydrogenaudio.org/forums/index....ic=38290&hl=#25 for 1.2.6beta. Testing would be appreciated, thanks.

Attempting to use the command-line version of WaveGain 1.2.5 in Win98SE gives me the same problem. It calculates, displays, and processes all the gain/DC offset changes, but then gives that Windows "illegal operation" error. It does write the gain-changed files correctly; it seems the error comes at the very end, right as WaveGain attempts to finish its work and return to the DOS prompt. Meanwhile, WaveGain 1.0.5 works correctly in Win98SE with no errors.

Kevtronics - no such errors with v1.2.6 beta 4

Good, I'll give it a try.

p.s. How about a Windows 3.1 version?

Could someone please upload tycho's wavegain-1.2.5.E3.zip somewhere again? I'm unable to get it from this location(dawn 404 Not Found )

I can make it available if you really want it, but 1.2.6 includes tycho's additions.

Okay, sorry I didn't know that
Thanks, I'm going to download it from rarewares.org

And the other way round? I want to correct the dc offset of the waves and perhaps apply any (wave)gain for my flac's or mp3's later.
I have tried several options but did not succeed yet.
A gain of 0 didn't work either.

You can do that with EAC - Process Waves. It will give pretty much the same result.

Yeah, I know, but I would like to do the dc correction with your program by using parameters on the commandline. For a whole bunch *.waves, recursively
Because in wavegain the options -g and --adc exist I thought I could combine them.
Gain 0 and dc offset corrected. Job done. My mistake.

Problem solved. I now do just the opposite in two steps. First analyze the wav's.
Then take note of the recommended gain and scale value, and process the waves using the opposite gainvalue. Works like a charm. Pity your program has no option for it.
But this works too. Thanx