Hydrogenaudio Forums > WaveGain 1.2.7beta available for testing

john33

Jun 1 2006, 05:11

As per the title, I would appreciate some testing on this. It is available at the 'Others' page at Rarewares.

This includes the fix to the bug reported by jaybeee in the 1.2.6 thread, but more importantly, contains three new options:

CODE

  -w, --write      Writes a 'gain' chunk into the Wave Header.
                   Stores the scalefactor applied to the wave data as a
                   double floating point number. Only written when gain
                   is applied. Presence will result in file being skipped
                   if reprocessed.
                   (Unless '--force' or '--undo-gain' are specified.)
      --force      Forces the reprocessing of a file that contains a 'gain'
                   chunk and will result in the new scalefactor overwriting
                   the existing value.
      --undo-gain  Reads the scalefactor in the 'gain' chunk and uses the
                   value to reverse the previously applied gain. This will NOT
                   recreate a bit identical version of the original file, but
                   it will be rescaled to the original level.

It is important to note that when 'undoing' the gain, you should NOT expect the resulting file to be bit identical to the original, it will simply exhibit the same level of loudness.

Possibly the major benefit of writing the 'gain' chunk is that it will not be reprocessed without the use of the '--force' option, it will simply be skipped with an appropriate message to the screen.

Just for the record, any correctly written application encountering the 'gain' chunk will ignore it if it doesn't recognise it, it will not result in any error. This is certainly true of foobar and Adobe Audition to name but two of the applications I have tested this against.

Please report any bugs here.

TIA.

spoon

Jun 1 2006, 05:25

> 'gain' chunk will ignore it if it doesn't

If you write it after the data chunk then even badly written programs shouldnt choke on it (I have seen programs written which expect fmt and data chunks in the start two positions)...

jaybeee

Jun 1 2006, 06:01

Nice work John

I'll test on the 1.2.6 problem file tonight.

Nice extra switches too

john33

Jun 1 2006, 06:34

QUOTE(spoon @ Jun 1 2006, 12:25)

> 'gain' chunk will ignore it if it doesn't

If you write it after the data chunk then even badly written programs shouldnt choke on it (I have seen programs written which expect fmt and data chunks in the start two positions)...

Good point, I'll take that under advisement.

Jebus

Jun 1 2006, 13:15

How about an option to simply "read" the gain chunk... like --readgain, which will simply print out the adjustment value?

jaybeee

Jun 1 2006, 14:47

John, it's done the same thing with the same file

CODE

john33

Jun 2 2006, 10:35

OK, beta2 is uploaded to Rarewares. jaybeee, I believe this should now truly be fixed!!

The problem, I think, centres on the fact that I'm using the functions 'fseek' and 'ftell' when closing the file to ensure that any chunks that appear after the 'data' chunk are copied over, and both of these functions use signed ints!! Hence, the often seen 2GB limit!! I've circumvented this issue by using '_fseeki64' and '_ftelli64' which, as the names suggest, are similar functions, but use signed 64 bit ints. Oddly, these 64 bit functions are completely undocumented regarding their existence.

jaybeee

Jun 2 2006, 11:16

Tried beta2, and this time the file remains the same physical size. So the weirdness with it increasing to 4gb is gone. However, wavegain still reported the "Invalid argument (22)" error. And the file is shorter in duration: 3hrs 22mins 53secs instead of 4hrs 5secs.

Soz mate, seems like there's still some issue

john33

Jun 2 2006, 11:24

QUOTE(jaybeee @ Jun 2 2006, 18:16)

Tried beta2, and this time the file remains the same physical size. So the weirdness with it increasing to 4gb is gone. However, wavegain still reported the "Invalid argument (22)" error. And the file is shorter in duration: 3hrs 22mins 53secs instead of 4hrs 5secs.

Soz mate, seems like there's still some issue

Thanks!!

Back to the drawing board.

john33

Jun 2 2006, 11:46

beta 3 uploaded!!

Of course, making the above changes, it always helps if you permit a file size value of greater than 2GB to be written!!

jaybeee

Jun 4 2006, 11:35

QUOTE(john33 @ Jun 2 2006, 18:46)

beta 3 uploaded!!

Of course, making the above changes, it always helps if you permit a file size value of greater than 2GB to be written!!

Yep, that worked John IPB Image

However, I do still get the "error is: Invalid argument (22)" line printed in the log file. I'm not sure if there is an error this time.
And also the error isn't reported via the cmd prompt, but only in the log file: not sure if that's correct or intentional (it never actually reported it via the cmd prompt though).

john33

Jun 4 2006, 12:49

QUOTE(jaybeee @ Jun 4 2006, 18:35)

QUOTE(john33 @ Jun 2 2006, 18:46)

beta 3 uploaded!!

Of course, making the above changes, it always helps if you permit a file size value of greater than 2GB to be written!!

Yep, that worked John IPB Image

However, I do still get the "error is: Invalid argument (22)" line printed in the log file. I'm not sure if there is an error this time.
And also the error isn't reported via the cmd prompt, but only in the log file: not sure if that's correct or intentional (it never actually reported it via the cmd prompt though).

Great, thanks.

I'll check out the log message.

jaybeee

Jun 5 2006, 03:56

John, this isn't really anything to do with wavegain (other than I've found a bug and that you've fixed it in your particular app), but when I try to encode this 4hr (2.4gb) file to LAME mp3 or Ogg Vorbis or FLAC via foobar, it always errors. Seems to get close to finishing and then falls over. Now I used OggDrop & LameDrop & FLACDrop which all work. So I can only assume this is something to do with foobar.

Again, I know foobar is nothing to do with yourself, but as I've found this bug that affects wavegain, and that in the wavegain 1.2.6 thread you suggested the problem with foobar displaying the filesize correctly could be caused by the same issue you had with wavegain, I wonder if this bug is indeed in foobar. Any thoughts? Or should I just create a new thread about this bug and let the foobar chaps have a look?

john33

Jun 5 2006, 04:18

QUOTE(jaybeee @ Jun 5 2006, 10:56)

John, this isn't really anything to do with wavegain (other than I've found a bug and that you've fixed it in your particular app), but when I try to encode this 4hr (2.4gb) file to LAME mp3 or Ogg Vorbis or FLAC via foobar, it always errors. Seems to get close to finishing and then falls over. Now I used OggDrop & LameDrop & FLACDrop which all work. So I can only assume this is something to do with foobar.

Again, I know foobar is nothing to do with yourself, but as I've found this bug that affects wavegain, and that in the wavegain 1.2.6 thread you suggested the problem with foobar displaying the filesize correctly could be caused by the same issue you had with wavegain, I wonder if this bug is indeed in foobar. Any thoughts? Or should I just create a new thread about this bug and let the foobar chaps have a look?

I'd suggest trying to encode from the command line with one of the encoders and, if that works, then it is probably safe to say that it is a foobar issue, and a new thread would probably be appropriate.

BTW, the error message in the WaveGain log is just a log writing bug that I have now fixed, but I'll not bother with a new beta unless any other problems arise. Thanks for your help with this, it's much appreciated.

jaybeee

Jun 5 2006, 04:26

^^ no probs mate. I've used wavegain for over a year now as I've been converting all my cassette tapes, and I find the program great.

Thought the log thing might just be a wee log writing bug.

I'll do some more testing with commanline encoding and if there's still a problem create a new thread.

Cheers

Martin H

Sep 11 2007, 08:59

@john33

I would be very happy if you would please be so kind as to make WaveGain store it's %ALBUM_PEAK% and other *_PEAK variables in a 0.000000 - 1.000000 range i.e. divide the obtained result by 32767 and only storing the 0.000000 - 1.000000 normalised values in the *_PEAK variables ? Tycho has previously done that with v1.2.6 i.e. v1.2.6.1 for use with his REACT EAC plugin.

REACT uses the %ALBUM_PEAK% variable to set the following line in the cuesheet : "REM REPLAYGAIN_ALBUM_PEAK 1.00000", and so if i use the latest WaveGain beta, instead of Tycho's modified v1.2.6(i.e. v1.2.6.1), then it would become : "REM REPLAYGAIN_ALBUM_PEAK 32767".

So because of this, then i'm using v1.2.6.1 myself at the momment, and i would like to ask you if you could please tell me if the "signed long ints that should have been unsigned" issue of v1.2.6(.1) has any bad effect if i'm not applying any gain values, but only analyzing(-a) wav images and storing the obtained album gain/peak values in the embedded cuesheet of the encoded WavPack images(as 'rem' statements, which fb2k can parse) ?

Also, could you please tell me if you would personally recommend using v1.2.7b or v1.2.6(.1), if i'm only using WaveGain for analyzing wav images and not for modifying them ?

Thank's in advance.

Martin.

john33

Sep 18 2007, 06:24

@Martin H: Sorry for not having replied to this but I have been away, out of internet access(!!) and only just returned. I'll get back to you as soon as I've had time to consider your questions properly.

Martin H

Sep 18 2007, 06:27

Thank's mate

Take all the time you need...

GeSomeone

Sep 18 2007, 09:01

QUOTE(Martin H @ Sep 11 2007, 15:59)

...PEAK 1.00 dB

REACT is wrong in adding dB, it is a factor.

BTW. by what value should 24bit files be devided?

Martin H

Sep 18 2007, 09:26

@GeSomeone

Doh! Sorry, it was me which made that idiotic mistake and not REACT

Thank's for the correction, mate

About 24 bit files... Good point - I haden't thought off that at all, i must admit...

@John33

Sorry for wasting your time then, but i would still really appreciate if you could please tell me if the "signed long ints that should have been unsigned" issue of v1.2.6 has any bad effect if i'm not applying any gain values, but only analyzing. I mean if the calculated gain values will be a little less accurate or something ?

Thank's in advance.

CU, Martin.

john33

Sep 18 2007, 09:40

QUOTE(GeSomeone @ Sep 18 2007, 16:01)

BTW. by what value should 24bit files be devided?

If you mean to convert to float values, it's 8388608.

john33

Sep 18 2007, 09:50

QUOTE(Martin H @ Sep 18 2007, 16:26)

....... but i would still really appreciate if you could please tell me if the "signed long ints that should have been unsigned" issue of v1.2.6 has any bad effect if i'm not applying any gain values, but only analyzing. I mean if the calculated gain values will be a little less accurate or something ?

Thank's in advance.

CU, Martin.

Unless you were processing files over 2GB, then there will be no error at all. For long files, it may be slightly less accurate than it should have been.

Martin H

Sep 18 2007, 09:59

Hi John33

Just wanted to say many thanks for answering my question, mate

Atleast i don't have to worry about that issue anymore, then

Again, many thanks for your help and for all your excellent work on WaveGain too

CU, Martin.