ReplayGain

[simoncn]

A large positive value for replayGain should produce the loudest possible sound volume. However, an extremely large value could cause binary arithmetic overflow which might produce a very quiet sound. I suggest you turn your amplifier volume very low before trying this experiment.

[golke53]

(07-02-2021 16:51)simoncn Wrote:  A large positive value for replayGain should produce the loudest possible sound volume. However, an extremely large value could cause binary arithmetic overflow which might produce a very quiet sound. I suggest you turn your amplifier volume very low before trying this experiment.

I think I'd rather go with the recommendation to remove the tags. I had only discovered these values by accident when I recently experimented with the profiles and got these values displayed in my control point (Kinsky). They had been created in a long lasting batch conversion which got applied to my entire music library quite a while ago (when you had published the replaygain solution above in this thread). Since then they had been sleeping in my lib.
What I take from here: don't activate replaygain_track unless you have checked the gain values. I am glad I had included the displayFormat string to display the values in my properties otherwise I would have never found them.

I may try mp3tag to help me finding other gain values of the exotic kind.

[simbun]

(07-02-2021 14:49)golke53 Wrote:  I have few audio test files with samples like "silence" or "pink noise". These samples happen to bear a trackgain value of let's say 922... billion dB (seriously, an endless string, very large positive number). What would happen (to my system) if I ever played one of those files with trackgain enabled?

I use trackgain when I'm shuffling so this got me curious.
I don't know too much about this so happy to be corrected, but when applying track/album replaygain ffmpeg also uses the peak values to prevent clipping, so this shouldn't be a problem (assuming it's been calculated correctly). I manually changed a tracks gain from -10.55 to 1000 and while the resulting output did show clipping in a number of areas, it was barely any different; changing the peak however I was able to clip the whole thing.

When I calculated track gain on some test files that included white noise my track gains were in the order of -3, with a peak of 0.99...., so not sure how yours are so extreme; I use foobar which I believe uses EBU R128.

It would be interesting to see what ffmpeg produced from your files with trackgain applied (assuming you have a track peak value):

Code:

ffmpeg.exe -i [infile].flac -af "volume=replaygain=track" [outfile].flac

You could then open it up in Audacity and click on View > Show Clipping, to get an idea.

There is the ffmpeg option replaygain_noclip but it didn't seem to make any difference.

[golke53]

(11-02-2021 12:39)simbun Wrote:  

(07-02-2021 14:49)golke53 Wrote:  I have few audio test files with samples like "silence" or "pink noise". These samples happen to bear a trackgain value of let's say 922... billion dB (seriously, an endless string, very large positive number). What would happen (to my system) if I ever played one of those files with trackgain enabled?

I use trackgain when I'm shuffling so this got me curious.
I don't know too much about this so happy to be corrected, but when applying track/album replaygain ffmpeg also uses the peak values to prevent clipping, so this shouldn't be a problem (assuming it's been calculated correctly). I manually changed a tracks gain from -10.55 to 1000 and while the resulting output did show clipping in a number of areas, it was barely any different; changing the peak however I was able to clip the whole thing.

When I calculated track gain on some test files that included white noise my track gains were in the order of -3, with a peak of 0.99...., so not sure how yours are so extreme; I use foobar which I believe uses EBU R128.

It would be interesting to see what ffmpeg produced from your files with trackgain applied (assuming you have a track peak value):

Code:

ffmpeg.exe -i [infile].flac -af "volume=replaygain=track" [outfile].flac

You could then open it up in Audacity and click on View > Show Clipping, to get an idea.

There is the ffmpeg option replaygain_noclip but it didn't seem to make any difference.

Hi there,
I am using dbpoweramp to rip my CD's and the DSP setting shows that I am using EBU R128 as well. It also shows a maximum gain level at 28 dB but that appears rather new to me. I haven't seen such a possibility to limit the gain in older versions of dbpoweramp (just recently upgraded to rel. 17, the latest). So I wonder how that billion db number ever made its way into my files. Probably when I had recoded (3 years ago, maybe) my entire collection flac -> flac to generate the replaygain tags the software did not yet provide such a "max gain" possibility. I remember well that there was a tickbox to enable/disable "prevent clipping" which caused me a lot of trouble. It had happened several times to me that a batch of lets say 1000 tracks ran into some error during the recoding (which takes quite a while) and at the very end it took another "quite a while" to perform the backout of the changes. Talking about 5 hours and more, depending how large the chunk of tracks was. Trial and error I disabled "prevent clipping" and then the batches ran through. SO that's probably how it happened.

Nevertheless I searched through my collection in the the meantime and have found just a handfull of such exotic values. Nullified them with mp3tag and game over.

Thank you for taking the time to answer.

[simbun]

Are you sure you didn't apply the Gain to the actual music itself?

The only reason I ask is that you said "recoded (3 years ago, maybe) my entire collection flac -> flac" and then you said it took 5 hours for batches (and gave 1000 tracks as an example). I've also heard that the language around ReplayGain used in DBPowerAmp isn't very clear.

Analysing the music just to add the tags REPLAYGAIN_TRACK_GAIN and REPLAYGAIN_TRACK_PEAK (and album if required) should not be taking more than 10 seconds or so per album, unless of course you're running on a very slow CPU and running it over a very slow network.
Using foobar I scanned 200 tracks and it had finished the operation in 50 seconds. I know you can use different algorithms to calculate the track peak which can massively affect the speed of operation, but I can't install DBPowerAmp to test as Replaygain is behind a pay wall (and I used a trial license a few months ago to try and rip a copy controlled CD).

One way to check would be to use CUETools to verify one of your previous rips.

Apologies if I'm barking up the wrong tree.

EDIT:
I performed the ReplayGain operation over the network on 477 files and it took 5m 20s. If you chose to write the file out to another location, or if the source had to be rewritten because of insufficient padding, this would have also increased the duration.

[golke53]

In dbpoweramp there are 2 options for replaygain: 1. "replaygain apply" and 2. just replaygain. I have always been double cautious not to do the apply thing because this would have changed the files instead of just adding tags.
I did create always both, Album and Track in the same conversion.
After the recoding I have always checked the replaygain tags with mp3tag and could conclude that if the tags were written the run was mutually exclusive to the apply function (unless dbpoweramp has a major bug, I don't believe). A way to check is to just do a recode with the same settings twice and then the tags in the 2nd run would be big time different from the first. This has not been the case so far.

Your example of just above 5 minutes for 500+ files I cannot match but my PC is not the fastest. I always do rewrite to the same location instead of creating a copy on a new folder. In theory it should be faster since it uses my 4 CPU cores simultaneously but while the conversion runs I can observe that most of the time 2 of the 4 processes are in a wait state, probably waiting for the tag write to disk which requires an exclusive lock on the disk track(s) in question.

The 10 seconds per song appears a bit too much. For 500 this implies 5000 seconds devided by ,, hmm 4 cores means 1250 seconds or a bit more than 20 minutes. I just tested a batch with 400 of alreaded recoded records and it took 10 minutes. Sure the software does recalculate the gains but the tag values in both were the same. All that looks fine.

I am now on dbpoweramp rel. 17 and 3 years ago it may have been rel. 14 or 15 and therefore I have no way to prove anything unless I downgrade the software. But that is not worth the effort for the handful of exotic tag values that were easy to correct and not difficult to find.

The new options in dbpoweramp regarding DSP setting make a lot of sense to me and even in the batch processing I found a new option that would allow to skip the "finish" message which has not been the case before. It happened often in the past that the process did not come to conclusion even after all files were done but the process was stuck in a state named "finalizing DSP effects". In that situation all I could do was to cancel and then the backout of all previous changes took place and lasted, and lasted.
I assume the problem was not only my single user problem and so the Illustrate guys invented this new option.

Good talk mate. Thanks for engaging.

[ilia.smirnov]

Hi!

Is it possible to use convolution and replaygain simutaneously?

Ay this time I use the room correction wav-convolution with convOut=-i /volume1/MinimServer/conv/al20210224-*.wav -lavfi afir=gtype=gn. When I try to add the -af volume=replaygain=track switches Minimwatch says "option incorrect for converter".

[simoncn]

You need to specify the combination like this:

convOut=-i /volume1/MinimServer/conv/al20210224-*.wav -lavfi "afir=gtype=gn,volume=replaygain=track"

[ilia.smirnov]

(28-02-2021 17:53)simoncn Wrote:  You need to specify the combination like this:

convOut=-i /volume1/MinimServer/conv/al20210224-*.wav -lavfi "afir=gtype=gn,volume=replaygain=track"

Thank you very much!

[Jim_Pap]

(22-01-2018 21:39)simoncn Wrote:  3) In the stream.transcode property, add:

flac:wav;

exactly as shown, including the semicolon

Hi all. I am transcoding to L16, not to wav, because my renderer (Yamaha WXAD10) does not support seeking into flac or wav audio (and I hate not being able to seek). I use BubbleUpnp as my control point which does support ReplayGain. However, to my (poor) understanding, transconding removes the ReplayGain information so BubbleUPNP support of it becomes useless. If this is true, the only option I have is to use ReplayGain and convOut on MinimStreamer. So if I use

flac:L16;

will ReplayGain normalization during transcoding work as intended? Btw, I am running Minim on Synology DSM 7 and I am not sure if its ffmpeg is ok for trancoding my flacs.

Thank you