New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

changes for osx #1

Merged
merged 2 commits into from Nov 21, 2012

Conversation

Projects
None yet
2 participants
@bwagner
Contributor

bwagner commented Nov 18, 2012

These changes mostly consist of replacing the preprocessor symbol MACOSX by the more generic APPLE. (MACOSX is not even defined for my os x version 10.7.5, i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1)
(see also http://stackoverflow.com/questions/2166483/which-macro-to-wrap-mac-os-x-specific-code-in-c-c)

One more important change is renaming the Windows-specific directory from "WaveGain" to "mswindows". I'm confident that the windows version still works with these changes.
I had to rename the directory because the usual osx file system does not differentiate between "wavegain" and "WaveGain". So when gcc tries to write the executable "wavegain", it barfs, because it can't replace the directory "WaveGain" with the executable "wavegain".

Thank you
Bernhard

MestreLion added a commit that referenced this pull request Nov 21, 2012

Merge pull request #1 from bwagner/master
fix compatibility issues on Mac OS X

@MestreLion MestreLion merged commit c928eaf into MestreLion:master Nov 21, 2012

@MestreLion

This comment has been minimized.

Show comment
Hide comment
@MestreLion

MestreLion Nov 21, 2012

Owner

Thanks! :)

Owner

MestreLion commented Nov 21, 2012

Thanks! :)

@bwagner

This comment has been minimized.

Show comment
Hide comment
@bwagner

bwagner Nov 21, 2012

Contributor

Thank you!
BTW: check http://normalize.nongnu.org/

Contributor

bwagner commented Nov 21, 2012

Thank you!
BTW: check http://normalize.nongnu.org/

@MestreLion

This comment has been minimized.

Show comment
Hide comment
@MestreLion

MestreLion Nov 22, 2012

Owner

I'm aware of normalize and its debian package normalize-audio, but it only performs peak normalization, while wavegain does replaygain, which is a more advanced normalization, based on power instead of peak, that relies on psychoacustics for perceived loudness (while still preventing peak clipping like normalize does)

Owner

MestreLion commented Nov 22, 2012

I'm aware of normalize and its debian package normalize-audio, but it only performs peak normalization, while wavegain does replaygain, which is a more advanced normalization, based on power instead of peak, that relies on psychoacustics for perceived loudness (while still preventing peak clipping like normalize does)

@bwagner

This comment has been minimized.

Show comment
Hide comment
@bwagner

bwagner Nov 22, 2012

Contributor

There's a section in the help of normalize that seems to suggest that "normalize" does more than simple peak analysis:
normalize --help
...
--peak adjust by peak level instead of using loudness analysis
...

I've run an analysis only on the same audio file with both tools:

WaveGain:

    Gain   |  Peak  | Scale | New Peak |Left DC|Right DC| Track
           |        |       |          |Offset | Offset |
 --------------------------------------------------------------
  +8.31 dB |  12267 |  2.60 |    31933 |    1  |     1  | /Volumes/LaCie2T/audio/exil/201211212315/exil1211212315_02.wav

normalize:

  level        peak         gain
-22.6144dBFS -8.5341dBFS  10.6144dB  /Volumes/LaCie2T/audio/exil/201211212315/exil1211212315_02.wav

So normalize seems to come up with a gain of 10.6144 dB, where WaveGain only gains 8.31 dB...

I'm not sure which to use.

Contributor

bwagner commented Nov 22, 2012

There's a section in the help of normalize that seems to suggest that "normalize" does more than simple peak analysis:
normalize --help
...
--peak adjust by peak level instead of using loudness analysis
...

I've run an analysis only on the same audio file with both tools:

WaveGain:

    Gain   |  Peak  | Scale | New Peak |Left DC|Right DC| Track
           |        |       |          |Offset | Offset |
 --------------------------------------------------------------
  +8.31 dB |  12267 |  2.60 |    31933 |    1  |     1  | /Volumes/LaCie2T/audio/exil/201211212315/exil1211212315_02.wav

normalize:

  level        peak         gain
-22.6144dBFS -8.5341dBFS  10.6144dB  /Volumes/LaCie2T/audio/exil/201211212315/exil1211212315_02.wav

So normalize seems to come up with a gain of 10.6144 dB, where WaveGain only gains 8.31 dB...

I'm not sure which to use.

@MestreLion

This comment has been minimized.

Show comment
Hide comment
@MestreLion

MestreLion Nov 22, 2012

Owner

Looks like you're correct: http://normalize.nongnu.org/README.html makes clear that normalize also uses RMS amplitudes for calculating the gain, so it is better than simple peak normalization. But their algorithms used to calculate the gain are different: WaveGain uses the replaygain standard, while normalize uses its own made up algo, which is similar in concept.

Since replaygain was proposed by the hydrogenaudio community, and implemented in several players and encoders, I'd stick with it rather than using the one created by normalize. At least you would get consistent results with mp3gain, vorbisgain, metaflac, etc..

Owner

MestreLion commented Nov 22, 2012

Looks like you're correct: http://normalize.nongnu.org/README.html makes clear that normalize also uses RMS amplitudes for calculating the gain, so it is better than simple peak normalization. But their algorithms used to calculate the gain are different: WaveGain uses the replaygain standard, while normalize uses its own made up algo, which is similar in concept.

Since replaygain was proposed by the hydrogenaudio community, and implemented in several players and encoders, I'd stick with it rather than using the one created by normalize. At least you would get consistent results with mp3gain, vorbisgain, metaflac, etc..

@bwagner

This comment has been minimized.

Show comment
Hide comment
@bwagner

bwagner Nov 23, 2012

Contributor

Thanks for your advice!

Contributor

bwagner commented Nov 23, 2012

Thanks for your advice!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment