Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > General > Audio encoding

Reply
 
Thread Tools Search this Thread Display Modes
Old 4th August 2014, 13:56   #1  |  Link
hydra3333
Registered User
 
Join Date: Oct 2009
Location: crow-land
Posts: 532
DynamicAudioNormalizer

Saw this and liked the look of it.
http://www.videohelp.com/tools/Dynamic-Audio-Normalizer
https://github.com/lordmulder/Dynami...lizer#chap_cfg
Did a quick search and it doesn't seem to be mentioned here ?
(The author has an interesting id)
Any reviews or info ?
Is it safe to run ?
Thanks.
hydra3333 is offline   Reply With Quote
Old 4th August 2014, 19:49   #2  |  Link
hello_hello
Registered User
 
Join Date: Mar 2011
Posts: 4,029
It seems to work very much like the WinAmp "compressor" plugin I've been using with ffdshow for years. I'm not a fan of altering/compressing the audio before encoding it (at least not for general soundtrack audio), so I do it on playback instead, but not everyone uses a PC as a media player. If the DynamicAudioNormalizer works as well as the WinAmp RockSteady plugin, and they seem to work in a similar fashion, it should be a good thing.

If you're interested, I posted about the way I compress audio on playback in this thread. I also included a few samples. I was comparing the RockSteady plugin to Levelator. I wasn't overly excited about Levelator but it's not designed for soundtrack audio.

Compressing the audio the traditional way and "compressing it" by increasing the volume of the quiet parts are both susceptible to the same "pumping" problem, where you can hear the volume of background sounds going up and down. The more you compress, the more it's likely to happen. Normalising the way the DynamicAudioNormalizer does it tends to be easier to configure than standard compression though..... well my setup is pretty much set and forget.... I'm not needing to constantly adjust it as you probably would using standard compression.

Anyway..... I wouldn't normally compress while encoding, but I will give the DynamicAudioNormalizer a spin at some stage.
There's another free WinAmp "compressor" DSP here. Once again you can use it with ffdshow. Same principle, easier to configure.
hello_hello is offline   Reply With Quote
Old 4th August 2014, 20:34   #3  |  Link
tebasuna51
Moderator
 
tebasuna51's Avatar
 
Join Date: Feb 2005
Location: Spain
Posts: 5,694
The author, LoRd_MuldeR, is a moderator in this forum then, maybe, can help you about this.

I think can be applied to some audios bad recorded, but I don't think is for use always.
Good audio tracks have the Dynamic Range than the author want, and compress it is not recommended at all.
But, of course, is your choice.

I recommend read Loudness war
__________________
BeHappy, AviSynth audio transcoder, in Doom9 forums. NicAudio, BassAudio, audio decoders.
tebasuna51 is offline   Reply With Quote
Old 4th August 2014, 23:51   #4  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,070
Quote:
Originally Posted by tebasuna51 View Post
The author, LoRd_MuldeR, is a moderator in this forum then, maybe, can help you about this.

I think can be applied to some audios bad recorded, but I don't think is for use always.
Good audio tracks have the Dynamic Range than the author want, and compress it is not recommended at all.
But, of course, is your choice.

I recommend read Loudness war
Since you mention "compression" and "loudness war" I just want to clarify that the Dynamic Audio Normalizer doesn't quite work like a compressor. The compressor first "flattens" the signal peaks (by reducing all samples above a predefined threshold), which results in a certain headroom, and then applies a fixed gain in order to bring the signal to the maximum level again. The results in a much "louder" signal, but the peaks are gone for good. The dynamic range has been reduced significantly.

At the same time, the Dynamic Audio Normalizer works more like a "standard" normalizer. It simply applies a certain gain factor to the samples, but doesn't prune any samples before that. This means that the maximum gain factor is restricted by the highest magnitude sample. The difference between a "standard" normalizer and the Dynamic Audio Normalizer is that the latter readjusts the gain factor over time, so "quiet" sections of the track can get a stronger amplification than "loud" sections. In a certain way, this also is a dynamic range compression, yes. But within each section the full dynamic range is retained. And if your input file already contains peaks of maximum signal level in regular intervals, it will be passed trough unmodified.

It's probably better to think of this as harmonizing the volume of the "quiet" and "loud" sections of the file. And if that isn't desired, then the Dynamic Audio Normalizer is not the proper tool for whatever you are trying to achieve

Quote:
Originally Posted by hello_hello View Post
Compressing the audio the traditional way and "compressing it" by increasing the volume of the quiet parts are both susceptible to the same "pumping" problem, where you can hear the volume of background sounds going up and down.
This would be the case, if we simply calculated the maximum possible gain factor for each frame and then applied that gain factor to the frame - which would result in strong and unsteady gain fluctuations. The Dynamic Audio Normalizer mostly avoids the "pumping" problem by looking at a certain neighborhood around each frame rather than individual frames. Think of it like a sliding window approach. First, a minimum filter is applied, which is pretty effective in filtering out short-term gain variations. Secondly, a Gaussian smoothing kernel is applied, which ensures the remaining gain changes are smooth and steady. If you still get noticeable "pumping" after all, you should probably try a larger window size...

Quote:
Originally Posted by hydra3333 View Post
Is it safe to run ?
Safe? In regard to what?
__________________
There was of course no way of knowing whether you were being watched at any given moment.
How often, or on what system, the Thought Police plugged in on any individual wire was guesswork.



Last edited by LoRd_MuldeR; 5th August 2014 at 00:35.
LoRd_MuldeR is offline   Reply With Quote
Old 5th August 2014, 08:48   #5  |  Link
tebasuna51
Moderator
 
tebasuna51's Avatar
 
Join Date: Feb 2005
Location: Spain
Posts: 5,694
Quote:
Originally Posted by LoRd_MuldeR View Post
...
It's probably better to think of this as harmonizing the volume of the "quiet" and "loud" sections of the file. And if that isn't desired, then the Dynamic Audio Normalizer is not the proper tool for whatever you are trying to achieve
...
I read your full explanation in https://github.com/lordmulder/Dynami...lizer#chap_cfg and I really apreciate your method to harmonize the loudness.

I don't want to be critic, but if the user question "Is it safe to run?" want say "Is it safe to run always?", I think than is recommended when the track is bad recording or the user want this effect, but many artists (Alan Parsons, Bob Dylan, ...) want your songs with quiet and loud parts like was recorded.

But maybe is better than the user answer your question:

Safe? In regard to what?
__________________
BeHappy, AviSynth audio transcoder, in Doom9 forums. NicAudio, BassAudio, audio decoders.
tebasuna51 is offline   Reply With Quote
Old 5th August 2014, 13:02   #6  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,070
Quote:
Originally Posted by tebasuna51 View Post
I don't want to be critic, but if the user question "Is it safe to run?" want say "Is it safe to run always?"
Well, I am confident it is "safe" to always use it, in the sense that it won't screw up your audio.

But is the effect always desired/advisable? Probably not
__________________
There was of course no way of knowing whether you were being watched at any given moment.
How often, or on what system, the Thought Police plugged in on any individual wire was guesswork.


LoRd_MuldeR is offline   Reply With Quote
Old 5th August 2014, 13:39   #7  |  Link
hello_hello
Registered User
 
Join Date: Mar 2011
Posts: 4,029
Quote:
Originally Posted by LoRd_MuldeR View Post
This would be the case, if we simply calculated the maximum possible gain factor for each frame and then applied that gain factor to the frame - which would result in strong and unsteady gain fluctuations. The Dynamic Audio Normalizer mostly avoids the "pumping" problem by looking at a certain neighborhood around each frame rather than individual frames. Think of it like a sliding window approach. First, a minimum filter is applied, which is pretty effective in filtering out short-term gain variations. Secondly, a Gaussian smoothing kernel is applied, which ensures the remaining gain changes are smooth and steady. If you still get noticeable "pumping" after all, you should probably try a larger window size...
I'm no expert on this, but isn't there always some sort of compromise between reducing the "pumping" effect, and the amount of time over which the volume is adjusted, in respect to how much you can "compress"?

I've had a brief play with the DynamicAudioNormalizer (this isn't a criticism as it seems to work well) but the default frame length of 500ms seems too large to me. At least for "soundtrack" audio.

So I had a look at my RockSteady settings and it's RSM window (which I guess is it's name for "frame length") defaults to 75ms, so I added --frame-len 75 to the commandline along with --gauss-size 11 and so far I much prefer the result, at least for stereo "soundtrack" audio. For example, when going from a loud peak to relative silence with dialogue, the default settings take too long to increase the level of the dialogue for me, whereas with the smaller frame length the dialogue seemed to commence with full amplification. Admittedly if you listen closely the really quiet background stuff behind dialogue is on the verge of "pumping" at times, but it still sounds good to me. And it's definitely better than my TV's "night mode" which does cause audible "pumping".

Anyway, each to their own.... thanks for quite a nice audio utility.

Last edited by hello_hello; 5th August 2014 at 13:41.
hello_hello is offline   Reply With Quote
Old 5th August 2014, 13:51   #8  |  Link
hydra3333
Registered User
 
Join Date: Oct 2009
Location: crow-land
Posts: 532
Yes, thanks for the program.
Quote:
Originally Posted by LoRd_MuldeR View Post
Safe? In regard to what?
Well, it didn't seem to have a mention here, so it seemed possible someone could have been trading on your name and passing off ad-ridden (or worse) software ...
hydra3333 is offline   Reply With Quote
Old 5th August 2014, 22:41   #9  |  Link
manolito
Registered User
 
manolito's Avatar
 
Join Date: Sep 2003
Location: Berlin, Germany
Posts: 2,671
Sorry, but could not test the software... The Guru strikes again.


Quote:
F:\Download\DynAudNorm.2014-08-03.Windows-DLL>DynamicAudioNormalizerCLI.exe -i "
i:\test.wav" -o "i:\norm.wav"
---------------------------------------------------------------------------
Dynamic Audio Normalizer, Version 2.02-0, Shared
Copyright (c) 2014 LoRd_MuldeR <mulder2@gmx.de>. Some rights reserved.
Built on Aug 3 2014 at 19:15:00 with MSVC 2013.2 for Win-x86.

This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License <http://www.gnu.org/>.
Note that this program is distributed with ABSOLUTELY NO WARRANTY.
---------------------------------------------------------------------------

Using libsndfile-1.0.25, by Erik de Castro Lopo <erikd@mega-nerd.com>.



GURU MEDITATION: Unhandeled structured exception error!
Looks like SSE2 is required. The static version has the same behavior.


Cheers
manolito
manolito is offline   Reply With Quote
Old 6th August 2014, 01:38   #10  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,070
Quote:
Originally Posted by hello_hello View Post
I'm no expert on this, but isn't there always some sort of compromise between reducing the "pumping" effect, and the amount of time over which the volume is adjusted?
That's pretty much the trade-off that is controlled by the filter length parameter. And since the filter length is expressed in frames, changing the frame size has a similar effect.

I've had a brief play with the DynamicAudioNormalizer (this isn't a criticism as it seems to work well) but the default frame length of 500ms seems too large to me. At least for "soundtrack" audio.

Quote:
Originally Posted by hello_hello View Post
So I had a look at my RockSteady settings and it's RSM window (which I guess is it's name for "frame length") defaults to 75ms, so I added --frame-len 75 to the commandline along with --gauss-size 11 and so far I much prefer the result, at least for stereo "soundtrack" audio. For example, when going from a loud peak to relative silence with dialogue, the default settings take too long to increase the level of the dialogue for me, whereas with the smaller frame length the dialogue seemed to commence with full amplification. Admittedly if you listen closely the really quiet background stuff behind dialogue is on the verge of "pumping" at times, but it still sounds good to me. And it's definitely better than my TV's "night mode" which does cause audible "pumping".
There is no sophisticated justification for the default filter length of 31 and the default frame length of 500 ms. It's just what seemed to work reasonably well in my tests

Depending on what kind of input you are dealing with and on what you are trying to achieve, you may need to adjust the defaults.

You may also want to check out the "maximum gain" setting. With the proper limit, you can allow just enough gain to get sufficient volume in "dialogue" sections, but avoid a further volume in crease in really "quite" sections.

Quote:
Originally Posted by manolito View Post
Looks like SSE2 is required. The static version has the same behavior.
Yes, the pre-compiled binaries were made with SSE2 enabled.

This is 2014. SSE2 has been supported by mainstream processors since ~2000. Also SSE and SSE2 have been adopted as "core" instructions in all x64 processors.

Last but not least, current compilers have moved on to always enable SSE/SSE2 instructions, even for 32-Bit, unless those are explicitly disabled...

So I hope you understand that it's about time to have SSE2 enabled in the "standard" builds. If you need to run this on legacy hardware, you'll need to make your own build.

(But be aware that all the "external" libraries, such as libsndfile, libvorbis and libFLAC would have to be recompiled as well)
__________________
There was of course no way of knowing whether you were being watched at any given moment.
How often, or on what system, the Thought Police plugged in on any individual wire was guesswork.



Last edited by LoRd_MuldeR; 6th August 2014 at 03:14.
LoRd_MuldeR is offline   Reply With Quote
Old 6th August 2014, 20:11   #11  |  Link
manolito
Registered User
 
manolito's Avatar
 
Join Date: Sep 2003
Location: Berlin, Germany
Posts: 2,671
Today I had some time to test the software with a variety of CD tracks with different characteristics. I only used the defaults, and I must say that I am very impresssed how musical and artifact-free the results were. Even with critical sources I was unable to detect any pumping. And the dynamic characteristics were preserved nicely, while the quieter parts became much more present than in the original.

The effect might not be strong enough when listening to movie soundtracks at a very low listening volume like hello_hello already pointed out, but IMO the defaults are perfect for "real" music. I was particularly impressed how a rather quiet Jazz track with a very high dynamic range came out (I cover the waterfront by Joy Denalane). I consider this software a winner.

Maybe future versions could come with a couple of presets to cover different needs...

Any plans to integrate it into LameXP?
Does the software support STDIN and STDOUT so it can be used with pipes?


Cheers
manolito

Last edited by manolito; 6th August 2014 at 21:30.
manolito is offline   Reply With Quote
Old 7th August 2014, 01:07   #12  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,070
Quote:
Originally Posted by manolito View Post
Any plans to integrate it into LameXP?
Probably yes.

Quote:
Originally Posted by manolito View Post
Does the software support STDIN and STDOUT so it can be used with pipes?
Not yet. Currently all I/O is handled by libsndfile internally.

This would not only require to by-pass libsndfile, but also additional options to specify the sample format and the number of channels would have to be added.

Maybe in some future version
__________________
There was of course no way of knowing whether you were being watched at any given moment.
How often, or on what system, the Thought Police plugged in on any individual wire was guesswork.


LoRd_MuldeR is offline   Reply With Quote
Old 8th August 2014, 23:48   #13  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,070
Here is a new Test version that features support for "raw" audio data, including reading from the STDIN and writing to the STDOUT. See included manual for details!
http://sourceforge.net/projects/muld...lizer/Testing/

I have also implemented a new optional RMS-based normalization mode for volume adjustment. It can be enabled with the "--target-rms" switch.
__________________
There was of course no way of knowing whether you were being watched at any given moment.
How often, or on what system, the Thought Police plugged in on any individual wire was guesswork.



Last edited by LoRd_MuldeR; 8th August 2014 at 23:52.
LoRd_MuldeR is offline   Reply With Quote
Old 9th August 2014, 17:38   #14  |  Link
manolito
Registered User
 
manolito's Avatar
 
Join Date: Sep 2003
Location: Berlin, Germany
Posts: 2,671
Sorry, the NON-SSE test version is not working here. It does work when calling it without any parameters or with the -h parameter. But as soon as I want to convert a file, the GURU starts meditating again...


Cheers
manolito
manolito is offline   Reply With Quote
Old 10th August 2014, 02:09   #15  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,070
Quote:
Originally Posted by manolito View Post
Sorry, the NON-SSE test version is not working here. It does work when calling it without any parameters or with the -h parameter. But as soon as I want to convert a file, the GURU starts meditating again...
Note quite sure. I think I did the same thing as for the previous "No SSE" build, i.e. I recompiled libsndfile and the program itself with SEE/SSE2 explicitly disabled

Did you happen to use FLAC or Vorbis as input or output? This could be a problem, since I was too lazy to recompile those libs as well

Anyway, since I already reverted the changes that I did for the last "No SSE" build and also cleaned-up the intermediate files, we will never know. So here is a new attempt:

http://sourceforge.net/projects/muld...E.zip/download
__________________
There was of course no way of knowing whether you were being watched at any given moment.
How often, or on what system, the Thought Police plugged in on any individual wire was guesswork.


LoRd_MuldeR is offline   Reply With Quote
Old 10th August 2014, 17:41   #16  |  Link
manolito
Registered User
 
manolito's Avatar
 
Join Date: Sep 2003
Location: Berlin, Germany
Posts: 2,671
My input file was a regular PCM Wave file ripped from an Audio CD. Looks like libsndfile still needed SSE2.

Whatever, the latest version works nicely...

Still I am a little confused about the new RMS parameter. I converted several files of the more quiet kind, using the default parameters first, then adding -r 1, and at last using -r 0. Every time the three resulting files were bit identical. Did I do something wrong?

Another question:
When I process a file which starts rather quiet and stays quiet for about a minute, then gets louder, the processed file (default parameters) will also start quiet, but after about 8 seconds the gain increases. Is there a way to make the processed file start with the increased gain without destroying the dynamics? Reducing the gauss window size does not help. I guess that only a 2-pass approach could solve this.


Cheers
manolito
manolito is offline   Reply With Quote
Old 10th August 2014, 19:20   #17  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,070
Quote:
Originally Posted by manolito View Post
Whatever, the latest version works nicely...
Good to know.

Quote:
Originally Posted by manolito View Post
Still I am a little confused about the new RMS parameter. I converted several files of the more quiet kind, using the default parameters first, then adding -r 1, and at last using -r 0. Every time the three resulting files were bit identical. Did I do something wrong?
A value of zero is the default (if you don't use "--target-rms") and it has a special meaning: It simply disables the RMS processing.

What would a target RMS of zero mean anyway? Only 100% silent audio could have such RMS.

Furthermore, a target RMS value of 1.0 is too high. All samples would have to be at 0 dBFS (maximum possible sample value) to reach such RMS value, i.e. you'd need a 100% constant signal level.

For a "real" audio signal, with varying signal levels, try something like "--target-rms 0.2". And keep in mind "--target-rms" can only result in lower gain values, compared to not using "--target-rms".


Quote:
Originally Posted by manolito View Post
When I process a file which starts rather quiet and stays quiet for about a minute, then gets louder, the processed file (default parameters) will also start quiet, but after about 8 seconds the gain increases. Is there a way to make the processed file start with the increased gain without destroying the dynamics? Reducing the gauss window size does not help. I guess that only a 2-pass approach could solve this.
The "gauss window" takes into account a certain number of frames before and after the current frame.

Naturally, at the very beginning of the file we have no preceding frames. And at the very end of the file we have no subsequent frames. So what gain factors should we assume for those "missing" frames outside the file?

Currently, by default, a gain factor of 1.0 is assumed. This results in a smooth "fade in" and "fade out". It also avoids that we start/end with very strong amplification, if the the file starts/ends with silence - as is the case with many files.

However, you can use "--alt-boundary" to enable the alternative boundary mode. This will assume the "missing" frames at the beginning/end have the same gain as the very first/last frame in the file...
__________________
There was of course no way of knowing whether you were being watched at any given moment.
How often, or on what system, the Thought Police plugged in on any individual wire was guesswork.



Last edited by LoRd_MuldeR; 10th August 2014 at 19:23.
LoRd_MuldeR is offline   Reply With Quote
Old 10th August 2014, 21:29   #18  |  Link
manolito
Registered User
 
manolito's Avatar
 
Join Date: Sep 2003
Location: Berlin, Germany
Posts: 2,671
Alright, thanks for the explanation how --target-rms works. I made some more tests, but or the specific source file I used the parameter range is too coarse.

For a value of 0.2 the output is almost identical to the source file, and for a value of 0.3 the output is very similar to the default peak mode. A value of 0.5 makes for a result which is almost identical to peak mode.

For the other problem the --alt-boundary mode does not help at all. Maybe files with such properties (starting quiet and staying quiet for some time) require a special treatment. Like determining the peaks for the first few seconds first and applying the required gain factor right from the start of the file.

I uploaded my test source and a couple of conversions in case you want to have a look...
http://www32.zippyshare.com/v/10807498/file.html


Cheers
manolito
manolito is offline   Reply With Quote
Old 10th August 2014, 23:48   #19  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,070
Quote:
Originally Posted by manolito View Post
Alright, thanks for the explanation how --target-rms works. I made some more tests, but or the specific source file I used the parameter range is too coarse.

For a value of 0.2 the output is almost identical to the source file, and for a value of 0.3 the output is very similar to the default peak mode. A value of 0.5 makes for a result which is almost identical to peak mode.
Keep in mind that without "--target-rms", the gain factor for each frame is already is the maximum possible gain factor (without clipping).

Consequently, by adding the "--target-rms" switch, the gain factors cannot become even higher. They can only become smaller.

This means that you will need to specify a target RMS value that leaves enough room for the normalizer to work.

With a target value of 0.5, most frames probably have a much smaller RMS than the target RMS, but it's simply not possible to amplify these frames enough to reach that target RMS.

As a result, you will be running into the maximum peak limit all the time. And then, of course, the output is the same that you would have gotten without "--target-rms"


Quote:
Originally Posted by manolito View Post
For the other problem the --alt-boundary mode does not help at all. Maybe files with such properties (starting quiet and staying quiet for some time) require a special treatment. Like determining the peaks for the first few seconds first and applying the required gain factor right from the start of the file.
Your "Original.wav" file doesn't contain much volume variation to begin with:
http://i.imgur.com/NefTxvQ.png

The only thing noteworthy is that very short but huge peak (much higher than all the rest of the file!) in the left channel at the very beginning of the file:
http://i.imgur.com/cFEu9Dh.png

As expected with such input that has almost no volume variation, the resulting gain factors are constant as well – more or less:
http://i.imgur.com/ib7gI2K.png

Note that the "fade in" and "fade out" effect that we see towards the beginning and the end of the file are expected with the standard boundary mode. That's because we start off (and also end up) with a gain factor of exactly 1.0.

The alternative boundary mode changes the behavior at the beginning and at the end of the file. But with your specific file, the huge peak at the beginning prevents even higher gain factors there!

As a result, the beginning of the file looks pretty much the same with alternative boundary mode, but towards the end of the file the gain factors are now going up, because the original audio is fading out:
http://i.imgur.com/KuGmkJs.png

I'm not quite sure what else you have expected. But if we disable the channel coupling and only look at the right channel, which does not have such huge peak at the beginning, we get this:
http://i.imgur.com/Hx6YUXB.png
__________________
There was of course no way of knowing whether you were being watched at any given moment.
How often, or on what system, the Thought Police plugged in on any individual wire was guesswork.



Last edited by LoRd_MuldeR; 11th August 2014 at 00:10.
LoRd_MuldeR is offline   Reply With Quote
Old 11th August 2014, 02:12   #20  |  Link
manolito
Registered User
 
manolito's Avatar
 
Join Date: Sep 2003
Location: Berlin, Germany
Posts: 2,671
OK, so the --target-rms option is not for me. If I decide to use Dynamic Range Compression at all, then I want the resulting file to be LOUDER, not quieter than the source.

For the other issue you are absolutely right, the peak in the left channel at the beginning prevents the --alt-boundary mode to work. After I edited the original file removing this peak I did get a perfect result with the --alt-boundary option.

But I think that files like this are not too rare. Could the --alt-boundary mode be modified to ignore single peaks like the one in my original source file?


Cheers
manolito
manolito is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 05:38.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, vBulletin Solutions Inc.