Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: R128GAIN: An EBU R128 compliant loudness scanner (Read 389355 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

R128GAIN: An EBU R128 compliant loudness scanner

Reply #525
How can I use this tool to normalize mpeg-2 and h.264 files?

R128GAIN: An EBU R128 compliant loudness scanner

Reply #526
How can I use this tool to normalize mpeg-2 and h.264 files?

You may consider re-wrapping them into a MKV container by choosing the MKV format.

R128GAIN: An EBU R128 compliant loudness scanner

Reply #527
How can I use this tool to normalize mpeg-2 and h.264 files?

You may consider re-wrapping them into a MKV container by choosing the MKV format.


Thanks for your reply. I need the final file in H.264/AVC/MPEG-4 Part 10, since this is for TV broadcasting. I tried separating audio and video, to normalize the audio and then merge audio and video together. But the audio doesn't change. I have downloaded the shared autobuild of ffmpeg and replaced the dll's in the r128gain-tools folder.

The script that I use is one that Charalampos Tsimpouris helped me adapt from his script at http://1024.gr/blog/normalize-audio-movies...and-sox-windows. It looks like this:

Code: [Select]
echo off
cls
echo Script by http://1024.gr

cd /d %~dp0

echo Extracting audio to "%~1_clean.wav"..
r128gain-1.0-beta-2\r128gain-tools\ffmpeg.exe -i "%~1" -ac 2 -y "%~1_clean.wav"

echo Getting max amplitude and normalizing to "%~1_clean.wav"..
r128gain-1.0-beta-2\r128gain.exe --in-place "%~1_clean.wav"

echo Extracting video to "%~1_clean.avi"..
r128gain-1.0-beta-2\r128gain-tools\ffmpeg.exe -i "%~1" -map 0:0 -vcodec copy -y "%~1_clean.avi"

echo Creating new video file into "%~1_new.avi"..
r128gain-1.0-beta-2\r128gain-tools\ffmpeg.exe -i "%~1_clean.avi" -i "%~1_clean.wav" -vcodec copy "%~1_new.avi"

:clear
echo Cleaning..
del "%~1_clean.wav"
del "%~1_clean.avi"
pause


If I remove deleting the temporary files at the end, I compared the cleaned audio with the original audio and there is no change after running it through r128gain. Are we doing anything wrong in the script above?

In the above case we used it on avi files, but same result regardless of video format.

Cheers,
Daniel

R128GAIN: An EBU R128 compliant loudness scanner

Reply #528
I tried separating audio and video, to normalize the audio and then merge audio and video together.

In principle this should work.

But the audio doesn't change.

That's right because "r128gain" doesn't apply the gain. You may use the "--command" option in order to let SoX apply the gain:

Code: [Select]
r128gain "--command=sox %TRACK% %BN%-norm.wav gain %TGDB%" C:\Windows\Media\chord.wav -o .

R128GAIN: An EBU R128 compliant loudness scanner

Reply #529
Crashes on 2 different computers for me after I click OK using default settings, no log files are written.

I'm guessing this needs SSE2... both computers I tried are PIII.

 

R128GAIN: An EBU R128 compliant loudness scanner

Reply #530
Version 1.0 RC1 released:
[blockquote]Download: http://sourceforge.net/projects/r128gain/files/r128gain/1.0/[/blockquote]
What's new?
  • SoX 14.4.1
  • Improved stability
  • Win64 build

  • Crashes on 2 different computers for me after I click OK using default settings, no log files are written.

    I'm guessing this needs SSE2... both computers I tried are PIII.

    Final finish: Removed SSE.


R128GAIN: An EBU R128 compliant loudness scanner

Reply #531
I noticed that the 14.4.1 windows build of SoX doesn't include FLAC or W64 support.  I did some searching and found this posted on their project forum:
Quote
Unfortunately, there was a build problem in the 14.4.1 release leading to libflac and libsndfile being left out of the Windows binary.

I don't know what the fix is, just letting you know of this issue.  In the meantime, I'll continue using SoX 14.4.0 with R128GAIN RC1 due to WAVs above 4GB in size not working properly (hence why I use FLAC).

R128GAIN: An EBU R128 compliant loudness scanner

Reply #532
I noticed that the 14.4.1 windows build of SoX doesn't include FLAC or W64 support.

This may be true for the official distribution, but it doesn't hold for the build coming with R128GAIN (which is crippled in other ways).

I did some searching and found this posted on their project forum:
Quote
Unfortunately, there was a build problem in the 14.4.1 release leading to libflac and libsndfile being left out of the Windows binary.

Meanwhile there are "sox-14.4.1a-win32.*" builds available.

R128GAIN: An EBU R128 compliant loudness scanner

Reply #533
Thank you for adding FLAC support to the RC2 build.  Works great.

R128GAIN: An EBU R128 compliant loudness scanner

Reply #534
I decided to give R128Gain (latest RC2 build) a try last night after reading about it here and hearing good things about it.  At first, I couldn't get it to work on my MP3s, but as directed I updated FFmpeg and then it was able to do so.  However, the R128Gain-modified MP3s seem to be missing all the ID3 and other metatags.  Is there any simple way to tell R128Gain to simply pass through all tags other than the original ReplayGain one?

R128GAIN: An EBU R128 compliant loudness scanner

Reply #535
I decided to give R128Gain (latest RC2 build) a try last night after reading about it here and hearing good things about it.  At first, I couldn't get it to work on my MP3s, but as directed I updated FFmpeg and then it was able to do so.  However, the R128Gain-modified MP3s seem to be missing all the ID3 and other metatags.  Is there any simple way to tell R128Gain to simply pass through all tags other than the original ReplayGain one?

Unfortunately I'm not able to reproduce this. The result should be the same as in

Code: [Select]
ffmpeg -i "in.mp3" -c copy -y "out.mp3"

You may list the meta data seen by FFmpeg by means of

Code: [Select]
ffmpeg -i "in.mp3"

or

Code: [Select]
ffmpeg -i "out.mp3"


R128GAIN: An EBU R128 compliant loudness scanner

Reply #537
Just to be sure before I trash my whole library - I'm intending to run r128gain on all my mp3s, then write the results to the replaygain tag and convert those to Soundcheck values for use in iTunes. Will my mp3s stay as they are (apart from the tags) or will they be re-encoded during the process?

R128GAIN: An EBU R128 compliant loudness scanner

Reply #538
They will not be re-encoded. RG data are stored in dedicated fields in the tags.

Even if you were using the method of MP3gain and similar tools, the adjustments would be written to gain fields in the MP3 (quantised to 1.5 dB), but the audio data itself would remain untouched.

R128GAIN: An EBU R128 compliant loudness scanner

Reply #539
They will not be re-encoded.


Thanks for the info. I was just wondering how it works with the parallel level and peak adjustments that are required to achieve r128 compliance.

R128GAIN: An EBU R128 compliant loudness scanner

Reply #540
Sorry, but what do you mean? These algorithms just analyse the entire stream, determine the peak and average perceptual loudness, and write corresponding data to tag fields, thus enabling levelling of the volume during subsequent playback. None of this requires rewriting of the stream in even a temporary form, nor any sort of parallelism.

R128GAIN: An EBU R128 compliant loudness scanner

Reply #541
Sorry, but what do you mean? These algorithms just analyse the entire stream, determine the peak and average perceptual loudness


On the production side, you have to work on both aspects to not end up with a file that either has correct peaks but incorrect average loudness, or vice versa. I'm just wondering how a single tag value can result in r128 compliant playback when you, for example, have a track with correct occasional peaks but way too low average loudness.

R128GAIN: An EBU R128 compliant loudness scanner

Reply #542
The two data are stored in separate fields. The player should provide options to (A) normalise average perceptual loudness and also (B) override the adjustment invoked by step A if it would result in clipping according to the specified peak, thus preventing clipping. The user then chooses the combination of options that suit them. Here, straight from the original author, why the user should use clipping prevention but might choose not to: http://hydrogenaudio.org/forums/?showtopic=62625#entry559266

R128GAIN: An EBU R128 compliant loudness scanner

Reply #543
The two data are stored in separate fields. The player should provide options to (A) normalise average perceptual loudness and also (B) override the adjustment invoked by step A if it would result in clipping according to the specified peak, thus preventing clipping.


Thanks for claryfing. I suppose r128gain then is not for me, as I'm using iTunes and it will rely on a single value. I justed wanted to make sure beforehand, because in another discussion I stumbled over statements saying r128gain would sum up its result in a single value (which I couldn't believe).

R128GAIN: An EBU R128 compliant loudness scanner

Reply #544
as I'm using iTunes and it will rely on a single value.

Could you please let us know what kind of value this is?

What "r128gain" does is (as already mentioned) to calculate a set of values and store them as tags in the audio or video file. The most important of theses values (at least to me) is the gain which has to be applied to the audio in order to achieve the loudness required by some standards (e.g. EBU R128 or ATCS A/85). Other values stored are the maximum (inter-sample) peak and the loudness range.

Regarding the maximum (inter-sample) peak: Having applied the gain in order to achieve the loudness as defined by the mentioned standards (-23 dBFS or -24 dBFS, respectively) the maximum (inter-sample) peak typically is between -10 dBFS and -15 dBFS, in seldom cases -6 dBFS at a maximum (for a typical mixture of rock and pop music), i.e. in practice there's no need for limiting.

EDIT: In order to get an idea of what we are talking about you may consider using Winamp in conjunction with the FFSoX Player plugin (http://sourceforge.net/projects/in-ffsox/f...in_ffsox-2/0.0/). The pugin's file information dialog gives some information about a track's maximum peak and whether it's clipping:


In this particular case the maximum inter-sample peak without a gain applied would clip with +0.41 dBFS. On the other hand the EBU R128 gain is between -9.9 dB (track) and -10.9 (album) resulting in an effective maximum peak of about -10.0 dBFS during playback with the gain applied.

R128GAIN: An EBU R128 compliant loudness scanner

Reply #545
Just wondering if this is worth using over foobars RG implementation?

R128GAIN: An EBU R128 compliant loudness scanner

Reply #546
@kareha: Current foobar2000 versions use the R128 algorithm to calculate replaygain values, so it is not needed to use the application, because it already uses the algorithm.

R128GAIN: An EBU R128 compliant loudness scanner

Reply #547

The two data are stored in separate fields. The player should provide
Regarding the maximum (inter-sample) peak: Having applied the gain in order to achieve the loudness as defined by the mentioned standards (-23 dBFS or -24 dBFS, respectively)


Hi,
I've given R128GAIN V1.0 a try. Nice work.
I like the idea of additional meta-data tags besides the standard 4 replaygain tags. Especially tags for REPLAYGAIN_ALGORITHM and REPLAYGAIN_REFERENCE_LOUDNESS (and of course the 2 loudness ranges as specified by EBU-R128).

Question
On the user interface it is possible to specify an offset value ('ReplayGain Calibration') defaulting to -18. However, after running the loudness scanner it does seem hold on the Reference Loudness (default -23 LUFS), regardless of the calibration value (default -18 LUFS). If I compare a loudness scan on the same file with Foobar2000 (v1.2.9), which uses -18 by default I get a different value.

(1) I'm confused because I can modify both Reference Level AND Calibration value for both options "EBU R128" and "Replaygain"
I would have assumed that the replaygain value is calculated as RG =  (Reference Value) - (Loudness), with Loudness measured according ITU-1770-2. For EBU-R128 compliance, the reference value is -23 LUFS to offset content for normalized loudness. For use with music files on portable devices, the recommended reference value is -18 dB for normalized loudness (Wolters et al. (2010), page 11). Can you help me out?


(2) How could I afterward inspect the meta-date of a file to see which calibration value was used?


Thanks

----------------
Wolters, Mundt, Reidmiller (2010). Loudness normalization in the age of portable media players, Audio Engineering Society,
[Note1] http://www.dolby.com/uploadedFiles/Assets/...dia-Players.pdf


R128GAIN: An EBU R128 compliant loudness scanner

Reply #548
On the user interface it is possible to specify an offset value ('ReplayGain Calibration') defaulting to -18. However, after running the loudness scanner it does seem hold on the Reference Loudness (default -23 LUFS), regardless of the calibration value (default -18 LUFS). If I compare a loudness scan on the same file with Foobar2000 (v1.2.9), which uses -18 by default I get a different value.

RG and EBU R128/ITU BS.1770 use completely unrelated metrics and postulate some default or reference loudness w.r.t. there their algorithms, i.e. 89 dB and -23 LUFS, respectively. To my understanding these absolute values don't have any meaning on their own and there is no means to relate them to each other from a theoretical point of view.

However, you may apply the algorithms to some audio and may compare the resulting absolute loudness with the respective reference loudness and those getting the gain you have to apply in order to attenuate the audio's loudness to the reference level. And, of course, you can compare the gain calculated from RG with it's counterpart calculated by EBU R128/ITU BS.1770.

If you do this kind of comparison with a larger set of audio files you'll soon discover that the difference between the two gains is not a constant, i.e. it is varying. That's no surprise because the two gains are based on completely different algorithms. However, you can do some statistics in order to figure out the mean difference between the two gains for a given set of audio files (regression).

Those kinds of statistics came to the impression that 89 dB in RG world is (in mean) equivalent to -18 LUFS in EBU R128/ITU BS.1770 world (for details cf. the respective discussion up this thread).

As far as I can see, you're looking for ITU BS1770 algorithm with metrics taken from RG world. That's what is called RG2 in "r128gain".

(1) I'm confused because I can modify both Reference Level AND Calibration value for both options "EBU R128" and "Replaygain"
I would have assumed that the replaygain value is calculated as RG =  (Reference Value) - (Loudness), with Loudness measured according ITU-1770-2. For EBU-R128 compliance, the reference value is -23 LUFS to offset content for normalized loudness. For use with music files on portable devices, the recommended reference value is -18 dB for normalized loudness (Wolters et al. (2010), page 11). Can you help me out?

Assuming you're looking for RG2 the command would be (if you are using the GUI just choose the respective radio button from the "Compliant" group):

Code: [Select]
$ r128gain --rg2 --overwrite input/Track01.flac -o output
SoX sucessfully loaded.
FFmpeg sucessfully loaded.
analyzing ...
  [1/1] "Track01.flac": 96.2 dBFS (-7.2 dB)
      peak: 0.2 dBFS, range: 3.9 dB
  [ALBUM]: 96.2 dBFS (-7.2 dB)
      peak: 0.2 dBFS, range: 3.9 dB
writing ...
  [1/1] "Track01.flac" ... done.
done.

Please note that the result is slightly different to the one from classical RG:

Code: [Select]
$ r128gain --rg --overwrite input/Track01.flac -o output
SoX sucessfully loaded.
FFmpeg sucessfully loaded.
ReplayGain sucessfully loaded.
analyzing ...
  [1/1] "Track01.flac": 96.9 dBFS (-7.9 dB)
  [ALBUM]: 96.9 dBFS (-7.9 dB)
writing ...
  [1/1] "Track01.flac" ... done.
done.

(2) How could I afterward inspect the meta-date of a file to see which calibration value was used?

Code: [Select]
$ r128gain-tools/ffmpeg -i output/Track01.flac
ffmpeg version 2.0 Copyright (c) 2000-2013 the FFmpeg developers
  built on Jul 14 2013 13:18:11 with gcc 4.7.3 (rubenvb-4.7.4-release)
  libavutil      52. 39.100 / 52. 39.100
  libavcodec     55. 18.102 / 55. 18.102
  libavformat    55. 12.102 / 55. 12.102
  libavdevice    55.  3.100 / 55.  3.100
  libavfilter     3. 80.101 /  3. 80.101
  libswscale      2.  3.100 /  2.  3.100
  libswresample   0. 17.102 /  0. 17.102
  libpostproc    52.  3.100 / 52.  3.100
Input #0, flac, from 'Track01.flac':
  Metadata:
    REPLAYGAIN_ALGORITHM: EBU R128
    REPLAYGAIN_REFERENCE_LOUDNESS: 89.00 dBFS
    REPLAYGAIN_TRACK_GAIN: -7.25 dB
    REPLAYGAIN_TRACK_PEAK: 1.023053
    REPLAYGAIN_TRACK_RANGE: 3.94 dB
    REPLAYGAIN_ALBUM_GAIN: -7.25 dB
    REPLAYGAIN_ALBUM_PEAK: 1.023053
    REPLAYGAIN_ALBUM_RANGE: 3.94 dB
    ENCODER         : Lavf55.12.102
  Duration: 00:05:44.49, bitrate: 838 kb/s
    Stream #0:0: Audio: flac, 44100 Hz, stereo, s16
At least one output file must be specified


R128GAIN: An EBU R128 compliant loudness scanner

Reply #549
As far as I can see, you're looking for ITU BS1770 algorithm with metrics taken from RG world. That's what is called RG2 in "r128gain".


Thanks, this clarifies.

So basically, Gain Adjustment at album or track level can be chosen to be calculated as:

EBU-128 compliant      : GainAdjust (LUFS)= -23 LUFS - (Integrated Programme Loudness calculated with R128 algorithm) LUFS
Replaygain v1.0 (RG)  : GainAdjust (dB)    = -89 dBFS - (Loudness calculated with replaygain 1.0 algorithm) dBFS
Replaygain v2.0 (RG2) : GainAdjust (dB)    = -18 dBFS - (Integrated Programme Loudness calculated with R128 algorithm) dBFS

For ReplayGain v2.0 (RG2), it is assumed that the integrated proramme loudness expressed in LUFS can be interpreted as dBFS because the relationship with the offset of -18 dBFS was empirically determined by correlation analysis (linear regression) between values of classical RG and R128 determined loudness.

The GainAdjust values calcuated are stored in the original meta-data tags of ReplayGain 1.0 for compatibility reasons. I guess this was part of my confusion. The meta-data name is called REPLAYGAIN_xxxx, but the VALUE should be interpreted either as R128 compliant, ReplayGain v1.0 adjustment or ReplayGain v2.0 adjustment.

Would it not be a good idea to note this difference in the tag "REPLAYGAIN_ALGORITHM"? To distinguish the "METHOD" of calculating the values stored in the REPLAYGAIN at album and track level.

REPLAYGAIN_ALGORITHM = "EBU-128"
REPLAYGAIN_ALGORITHM = "ReplayGain 1.0"
REPLAYGAIN_ALGORITHM = "ReplayGain 2.0"

Technically, the algorithm for determining loudness is either R128 or RG 1.0
The METHOD of adjusting the playback gain (replaygain_xxxx tags) is EBU-128 compliant, RG 1.0 compliant or RG 2.0 compliant.