Topic: R128GAIN: An EBU R128 compliant loudness scanner (Read 277558 times)
0 Members and 1 Guest are viewing this topic.

## R128GAIN: An EBU R128 compliant loudness scanner

##### Reply #225 – 2011-02-01 14:08:35
@ pbelkner:

Quote
seq-3341-1-16bit.wav (1/1): -23.0 LUFS, -0.0 LU (peak: 0.071316: -11.5 dBFS)

Peak: 0.071316 is -22.9363 dBFS, not -11.5 dBFS.

Jean

## R128GAIN: An EBU R128 compliant loudness scanner

##### Reply #226 – 2011-02-01 14:39:53
Quote
seq-3341-1-16bit.wav (1/1): -23.0 LUFS, -0.0 LU (peak: 0.071316: -11.5 dBFS)

Peak: 0.071316 is -22.9363 dBFS, not -11.5 dBFS.

Please correct me where I'm wrong:
• We are talking about a voltage/power.
• According to Wikipedia we calculate as follows: 10.0*log10(P1/P0).
• In our case P1/P0 is 0.071316.
• Using http://www.calcoolate.com/ and typing 10.0*log10(0.071316) we get -11.468130236941654.
I suspect you are talking about 10.0*log(A1^2/A0^2).

## R128GAIN: An EBU R128 compliant loudness scanner

##### Reply #227 – 2011-02-01 14:52:31
You guys are overcomplicating it.

There we go. That correlation is good enough for anyone. Would there be any complaint when using that correlation as the provisional mapping for now? I know that the semantic meaning may not be identical, but when the correlation is that strong...

## R128GAIN: An EBU R128 compliant loudness scanner

##### Reply #228 – 2011-02-01 15:10:31
You guys are overcomplicating it.

There we go. That correlation is good enough for anyone. Would there be any complaint when using that correlation as the provisional mapping for now? I know that the semantic meaning may not be identical, but when the correlation is that strong...

Canar, do you have an example of that graph with the reference values used? If it compares ReplayGain @ 89dB to R128 @ -18.0 LUFS, that is different from comparing it to R128 @ -23.0 LUFS, isn't it?

My understanding of the argument (as much as I've followed of it, at least!) is that folks object to "ReplayGain" tags being used to store values calculated for R128 @ -23.0 LUFS, since they are inherently ~5dB lower than the majority of ReplayGain values. I didn't pick up on much objection to using them for this purpose if the calculation is based on R128 @ -18.0 LUFS, and there certainly hasn't been any such objection in the foo_r128scan thread, despite the fact that ReplayGain tags are similarly used by that component.

- M.

## R128GAIN: An EBU R128 compliant loudness scanner

##### Reply #229 – 2011-02-01 15:27:26
That graph, if I recall correctly, comes from lvgcl and is from foo_r128scan's -18 reference level, you are correct. The point that I'm making is that using that mapping to calculate values stored in ReplayGain tags is quite valid. At this point, any further comment on my part would be simply recapitulating Case and/or Notat.

We are dealing with software that is in early development and we will see where things go from here. I don't think there's uncovered ground left in the discussion about the various tagging formats.

## R128GAIN: An EBU R128 compliant loudness scanner

##### Reply #230 – 2011-02-01 18:38:36
Quote
Please correct me where I'm wrong:

1. We are talking about a voltage/power.
2. According to Wikipedia we calculate as follows: 10.0*log10(P1/P0).
3. In our case P1/P0 is 0.071316.
4. Using http://www.calcoolate.com/ and typing 10.0*log10(0.071316) we get -11.468130236941654.

I suspect you are talking about 10.0*log(A1^2/A0^2).

We are talking about peak voltage, in that case level calculation applies 20*log ...

Here are measured values of seq-3341-1-16bit.wav, see True Peak at aprox. -23 dBFS

As a reminder, the text from EBU Tech 3341:
Stereo sine wave, 1000 Hz, -23.0 dBFS (per-channel peak level); signal applied in phase to both channels simultaneous; 20 s duration
M, S, I = -23.0 ±0.1 LUFS M, S, I = 0.0 ±0.1 LU

Jean

## R128GAIN: An EBU R128 compliant loudness scanner

##### Reply #231 – 2011-02-01 21:04:31
Jean is correct, the proper formula for voltages is 20*log(V/Vref). That's because power is proportional to the square of the amplitude (voltage), so one gets 10*log(V2/V2ref)=20*log(V/Vref).

Cheers
If age or weaknes doe prohibyte bloudletting you must use boxing

## R128GAIN: An EBU R128 compliant loudness scanner

##### Reply #232 – 2011-02-02 07:18:34
We are talking about peak voltage, in that case level calculation applies 20*log ...

Jean is correct, the proper formula for voltages is 20*log(V/Vref). That's because power is proportional to the square of the amplitude (voltage), so one gets 10*log(V2/V2ref)=20*log(V/Vref).

Thank's a lot for clarifying. The next version will, of course, correct this.

If I thought to measure up to 1 dBFS clipping for hard (brickwall) limited audio this means that it is about 2 dBFS instead. This underlines what an important tool true peak measurement is.

## R128GAIN: An EBU R128 compliant loudness scanner

##### Reply #233 – 2011-02-02 07:26:35
Quote
Thank's a lot for clarifying. The next version will, of course, correct this.

Great

Quote
This underlines what an important tool true peak measurement is.

Quite true, don't underestimate intersample peaks!

Best regards
Jean

## R128GAIN: An EBU R128 compliant loudness scanner

##### Reply #234 – 2011-02-05 15:26:58
R128GAIN v0.8 released
[blockquote]http://sourceforge.net/projects/r128gain/files/[/blockquote]What's new?
• Streamcopy for (hopefully) allmost all formats and codecs supported by FFmpeg. E.g. for tagging Youtube videos try the following:

Code: [Select]
`r128gain *.flv -o out_dir`

• You may also wrap them into a MKV container:

Code: [Select]
`r128gain *.flv -o out_dir mkv`

• Mono is treated as stereo by default (requested by gjgriffith). You may force mono treatment:

Code: [Select]
`r128gain --mono *.wav`

NOTE: The "--mono" option affects mono only, not stereo nor any other channel configuration.
• Progress display during analysis.
• Fixed peak calculation in dBFS (reported by jangk).
• Fixed calculation of absolute loudness in RG compatible mode.
• Partially fixed open file dialog (reported by M). It should work now with Windows XP and earlier. Unfortunately this holds not for Windows Vista and later, c.f. http://www.midiox.com/html/dtcoding.htm).
GUI:

Command line options:

Code: [Select]
`\$ r128gain.exe --helpAn EBU R128 (http://tech.ebu.ch/loudness) compliant loudness scanner.For details refer to "http://r128gain.sourceforge.net/".Usage: r128gain [options] (file|directory)+ [-o <directory> [flac|mkv]]Options:  --r128             Run in EBU R128 compliant mode (default).  --rg               Run in ReplayGain compliant mode.  --r128-compatible  Calibrate output according to EBU R128.  --rg-compatible    Calibrate output according to ReplayGain.  --rg-calibration=<float>  Aequivalent to use for ReplayGain                     loudness (default: -18.0).  --true-peak=on,--true-peak  Up-sample for peak determination (default).  --true-peak=off,--fast  Switch off up-sampling.  --mono=off         Treat mono as stereo (default).  --mono=on,--mono   Don't treat mono as stereo.  --in-place         Allow overwriting of files in place.  --loglevel=<integer>  Set FFmpeg loglevel.  --regression       Calculate linear regression between EBU R128                     and ReplayGain.  --duration         Print out duration.  --version          Display version information.  --help             Display this information.`

## R128GAIN: An EBU R128 compliant loudness scanner

##### Reply #235 – 2011-02-05 17:53:35
R128GAIN v0.8 released
[blockquote]http://sourceforge.net/projects/r128gain/files/[/blockquote]

The new mono mode works just as I had hoped - thank you. Unfortunately, the new version appears to null out the values of all of my standard flac tags (ARTIST, ALBUM, etc.). In other words, the tags are present but have blank values.

## R128GAIN: An EBU R128 compliant loudness scanner

##### Reply #236 – 2011-02-05 19:18:22
R128GAIN v0.8.1
[blockquote]http://sourceforge.net/projects/r128gain/files/[/blockquote]
Unfortunately, the new version appears to null out the values of all of my standard flac tags (ARTIST, ALBUM, etc.). In other words, the tags are present but have blank values.

Many thanks for the report. Fortunately it was not that hard to fix. Sorry for any inconvenience.

Version 0.8.1 adds the option to increase the FFmpeg loglevel to the GUI:

## R128GAIN: An EBU R128 compliant loudness scanner

##### Reply #237 – 2011-02-10 13:03:17
I have been testing the latest version (0.8.1). After scanning a number of mp3 files I noticed the track duration of the generated files were wrong.
When the r128 scanner writes the mp3 files, vbr mp3 get written as cbr mp3.  They play alright but the track duration is totally messed up.
Mp3 were encode with lame 3.98.4 (-v2).
Used ffmpeg-r26397-swscale-r32676-mingw32-shared.
R128Gain 0.8.1 setting algorithm to BS 1770 and compatible Replaygain.

Could this time issue be fixed?

Greetings,

Ben

## R128GAIN: An EBU R128 compliant loudness scanner

##### Reply #238 – 2011-02-10 15:04:59
Thanks for the report. In order to reproduce it I did the following (using v0.8.2, should make no difference):
• Created a MP3:
Code: [Select]
`\$ lame -V2 ref_pink.wav ref_pink.mp3`

Code: [Select]
`\$ ffmpeg -i ref_pink.mp3...Input #0, mp3, from 'ref_pink.mp3':  Duration: 00:00:05.04, start: 0.000000, bitrate: 92 kb/s    Stream #0.0: Audio: mp3, 44100 Hz, 1 channels, s16, 92 kb/s`
• Tagged it using R128GAIN:
Code: [Select]
`\$ r128gain ref_pink.mp3 -o OUT`

Code: [Select]
`\$ ffmpeg -i OUT/ref_pink.mp3...[mp3 @ 0048d530] Estimating duration from bitrate, this may be inaccurateInput #0, mp3, from 'OUT/ref_pink.mp3':  Metadata:    REPLAYGAIN_ALGORITHM: EBU R128    REPLAYGAIN_REFERENCE_LOUDNESS: -23 LUFS    REPLAYGAIN_TRACK_GAIN: -2.6 LU    REPLAYGAIN_TRACK_PEAK: 0.294253    REPLAYGAIN_ALBUM_GAIN: -2.6 LU    REPLAYGAIN_ALBUM_PEAK: 0.294253    encoder         : Lavf52.92.0  Duration: 00:00:05.83, start: 0.000000, bitrate: 80 kb/s    Stream #0.0: Audio: mp3, 44100 Hz, 1 channels, s16, 80 kb/s`
• Created a reference using FFmpeg:
Code: [Select]
`ffmpeg -i ref_pink.mp3 -acodec copy -y OUT/ref_pink_ffmpeg.mp3`

Code: [Select]
`\$ ffmpeg -i OUT/ref_pink_ffmpeg.mp3...[mp3 @ 0048d530] Estimating duration from bitrate, this may be inaccurateInput #0, mp3, from 'OUT/ref_pink_ffmpeg.mp3':  Metadata:    encoder         : Lavf52.92.0  Duration: 00:00:05.80, start: 0.000000, bitrate: 80 kb/s    Stream #0.0: Audio: mp3, 44100 Hz, 1 channels, s16, 80 kb/s`

As it is obvious both, FFmpeg and R128GAIN, seem to loose header information present in the original MP3 (e.g. duration).

By loading the three MP3s into Winamp it can be seen that the VBR information is also lost during FFmpeg and R128GAIN processing. On the other hand WA is able to recover the duration (propably similar to FFmpeg's "Estimating duration from bitrate ...").

As far as I can see, R128GAIN reproduces FFmpeg. That's the expected behaviour.

Please note that (at least currently) FFmpeg's capabilities are a constraint to R128GAIN's capabilities.

## R128GAIN: An EBU R128 compliant loudness scanner

##### Reply #239 – 2011-02-13 16:24:41
R128GAIN v0.8.3 released
[blockquote]http://sourceforge.net/projects/r128gain/files/[/blockquote]What's new?
• Supplied a workaround for the VBR issue reported by bbrabant:

When the r128 scanner writes the mp3 files, vbr mp3 get written as cbr mp3.  They play alright but the track duration is totally messed up.

It seems to be caused by the FFmpeg MP3 de-muxer eating the VBR header.

Because it is an FFmpeg issue and I'm avoiding to re-distribute MPEG related software in binary form you have to compile and install it yourself:

• If not already done install Msys/MinGW (http://sourceforge.net/projects/mingw/files/ or http://tdm-gcc.tdragon.net/).
• If not already done install FFmpeg source and shared development packages (http://ffmpeg.arrozcru.org/autobuilds/).
• Save the following as "mp3_demuxer_alternate.c":

Code: [Select]
`#include <libavformat/avformat.h>#include <libavformat/id3v1.h>int mp3_read_header_alternate(AVFormatContext *s, AVFormatParameters *ap){    AVStream *st;    int64_t off;    st = av_new_stream(s, 0);    if (!st)        return AVERROR(ENOMEM);    st->codec->codec_type = AVMEDIA_TYPE_AUDIO;    st->codec->codec_id = CODEC_ID_MP3;    st->need_parsing = AVSTREAM_PARSE_FULL;    st->start_time = 0;    // lcm of all mp3 sample rates    av_set_pts_info(st, 64, 1, 14112000);    off = url_ftell(s->pb);    if (!av_metadata_get(s->metadata, "", NULL, AV_METADATA_IGNORE_SUFFIX))        ff_id3v1_read(s);#ifdef __ORIGINAL__    if (mp3_parse_vbr_tags(s, st, off) < 0)        url_fseek(s->pb, off, SEEK_SET);#else // __ORIGINAL__    url_fseek(s->pb, off, SEEK_SET);#endif // __ORIGINAL__    /* the parameters will be extracted from the compressed bitstream */    return 0;}`
• In an Msys shell issue the command (possibly with adapted include and link paths)

Code: [Select]
`\$ gcc -shared -mwindows mp3_demuxer_alternate.c -o mp3_demuxer_alternate.dll -lavformat`
• Copy the resulting "mp3_demuxer_alternate.dll" to R128GAIN's sub-directory "r128gain".

• The six channel test sample is finally processed as expected:

Code: [Select]
`\$ r128gain ../sounds/ebu-loudness-test-setv01/SoX successfully loaded.FFmpeg successfully loaded.../sounds/ebu-loudness-test-setv01  analyzing ...    1kHz Sine -20 LUFS-16bit.wav (1/16): -20.0 LUFS, -3.0 LU (peak: 0.100733: -19.9 dBFS)    1kHz Sine -26 LUFS-16bit.wav (2/16): -26.0 LUFS, 3.0 LU (peak: 0.050508: -25.9 dBFS)    1kHz Sine -40 LUFS-16bit.wav (3/16): -40.0 LUFS, 17.0 LU (peak: 0.010260: -39.8 dBFS)    seq-3341-1-16bit.wav (4/16): -23.0 LUFS, -0.0 LU (peak: 0.071316: -22.9 dBFS)    seq-3341-2-16bit.wav (5/16): -33.0 LUFS, 10.0 LU (peak: 0.023049: -32.7 dBFS)    seq-3341-3-16bit.wav (6/16): -23.0 LUFS, -0.0 LU (peak: 0.071468: -22.9 dBFS)    seq-3341-4-16bit.wav (7/16): -23.0 LUFS, 0.0 LU (peak: 0.070849: -23.0 dBFS)    seq-3341-5-16bit.wav (8/16): -22.9 LUFS, -0.1 LU (peak: 0.100845: -19.9 dBFS)    seq-3341-6-5channels-16bit.wav (9/16): -23.0 LUFS, 0.0 LU (peak: 0.063132: -24.0 dBFS)    seq-3341-6-6channels-WAVEEX-16bit.wav (10/16): -23.0 LUFS, 0.0 LU (peak: 0.063132: -24.0 dBFS)    seq-3341-7_seq-3342-5-24bit.wav (11/16): -23.0 LUFS, -0.0 LU (peak: 0.358340: -8.9 dBFS)    seq-3341-8_seq-3342-6-24bit.wav (12/16): -23.0 LUFS, 0.0 LU (peak: 0.718297: -2.9 dBFS)    seq-3342-1-16bit.wav (13/16): -22.6 LUFS, -0.4 LU (peak: 0.100088: -20.0 dBFS)    seq-3342-2-16bit.wav (14/16): -16.8 LUFS, -6.2 LU (peak: 0.177971: -15.0 dBFS)    seq-3342-3-16bit.wav (15/16): -20.0 LUFS, -3.0 LU (peak: 0.100088: -20.0 dBFS)    seq-3342-4-16bit.wav (16/16): -20.0 LUFS, -3.0 LU (peak: 0.100073: -20.0 dBFS)    ALBUM: -21.7 LUFS, -1.3 LU (peak: 0.718297: -2.9 dBFS)`

• Further improved stream copy.

## R128GAIN: An EBU R128 compliant loudness scanner

##### Reply #240 – 2011-02-13 18:09:15
Quote
It seems to be caused by the FFmpeg MP3 de-muxer eating the VBR header.
Because it is an FFmpeg issue and I'm avoiding to re-distribute MPEG related software in binary form you have to compile and install it yourself:

Thank you for your effort to fix the vbr header issue. Compiling FFmpeg myself is a bit to technical for me.
I have a different solution. I use foobar with the 128gainscan plugin. This way only the gain tags are written without messing with the vbr header.

Thanks again,

Ben

## R128GAIN: An EBU R128 compliant loudness scanner

##### Reply #241 – 2011-02-13 18:46:09
Compiling FFmpeg myself is a bit to technical for me.

## R128GAIN: An EBU R128 compliant loudness scanner

##### Reply #242 – 2011-02-13 23:26:27
After a quick test with R128GAIN v0.8.3 and the new mp3_demuxer_alternate.dll (thanks peter) the mp3 vbr header is written correctly.
The track duration is now the same as the source mp3.

I also noticed that some id3 tags are not the same as the source mp3.

The "Year" tag is changed to "RELEASETIME" tag.
The "comment" tag is removed
The album art (cover.jpg) stored in the mp3 is also removed.

Thank you for the r128gain scanning, almost time to replace replaygain scanning.

greetings,

ben

## R128GAIN: An EBU R128 compliant loudness scanner

##### Reply #243 – 2011-02-25 19:54:30
Hi,

today EBU Tech 3343 was finally published:

EBU Tech 3343

Best regards

Jean

## R128GAIN: An EBU R128 compliant loudness scanner

##### Reply #244 – 2011-02-26 12:05:09
Thanks for the link, Jean! I skimmed through the 43 pages. Quotes of the most important passages with regard to file metadata such as ReplayGain:

page 10:
Quote
The Low Frequency Effects channel (the “.1”-channel in “5.1”) of a multichannel audio signal is currently not taken into account for the loudness measurement according to ITU-R BS.1770. [...] Ongoing investigations try  to evaluate the subjective effect the LFE has on the perception of loudness as well as the appropriate way to include it in the objective loudness measurement.

Page 12:
Quote
Recently (September 2010), the EBU has submitted the suggestion to the ITU to include the relative gating method into BS.1770. At the subsequent ITU meeting this suggestion was accepted, albeit with a slightly lower threshold level of -10 LU below the ungated loudness level. According to the tests of PLOUD, the results with a relative gate of -10 LU are only marginally different from -8 LU. Therefore, once the -10 LU gate is published in the next revision of ITU-R BS.1770, it will also be incorporated into EBU R 128 and the accompanying documents, particularly EBU Tech Doc 3341.

Page 34:
Quote
Metadata generally can be active (potentially changing the audio signal) or descriptive (providing information about the signal, such as format, copyright etc.). As a natural consequence of the work within PLOUD and the publication of EBU R 128 and its supporting documents, the three main parameters Programme Loudness, Loudness Range and Maximum True Peak Level shall form the core of loudness Metadata in audio files. Work is underway to include those parameters in the header (Broadcast Extension (BEXT) chunk) of the Broadcast Wave File (BWF) format (for a detailed description of BWF, see [10], [11] and [12]).

Page 35:
Quote
Exceptions where a different value than -23 [LUFS] may be used are: [...] A fully functional system of providing and using Metadata over the whole signal chain is already in place. This implies faithful transportation of loudness Metadata to the consumer’s home equipment.

Since ReplayGain can be considered a "fully functional system", I think we're on the right track with the R128 gain taggers here on HA, especially for stereo (only the change from -8 to -10 LU will be needed one day). Regarding a Programme Loudness tag, I have no opinion on whether/how we should transmit that.

Chris

## R128GAIN: An EBU R128 compliant loudness scanner

##### Reply #245 – 2011-02-26 18:46:07
Also interesting:
Quote
Informal tests conducted by
members of the EBU PLOUD group have shown that the difference in the loudness measurement
with and without the -8 LU relative gate of programmes with a small to medium loudness range are
around 0 – 1 LU.

## R128GAIN: An EBU R128 compliant loudness scanner

##### Reply #246 – 2011-02-26 20:38:54
Since ReplayGain can be considered a "fully functional system", I think we're on the right track with the R128 gain taggers here on HA, especially for stereo (only the change from -8 to -10 LU will be needed one day).

Yes, I fully agree!

Jean

## R128GAIN: An EBU R128 compliant loudness scanner

##### Reply #247 – 2011-02-27 10:52:13
R128GAIN v0.8.4 released:
[blockquote]http://sourceforge.net/projects/r128gain/files/[/blockquote]What's new?

Page 12:
Quote
Recently (September 2010), the EBU has submitted the suggestion to the ITU to include the relative gating method into BS.1770. At the subsequent ITU meeting this suggestion was accepted, albeit with a slightly lower threshold level of -10 LU below the ungated loudness level. According to the tests of PLOUD, the results with a relative gate of -10 LU are only marginally different from -8 LU. Therefore, once the -10 LU gate is published in the next revision of ITU-R BS.1770, it will also be incorporated into EBU R 128 and the accompanying documents, particularly EBU Tech Doc 3341.

With R128GAIN v0.8.4 it's possible to parametrize the BS.1770 gate:

The range from -10.0 LU to -8.0 LU is considered EBU R128 compliant.

The command line version offers an respective "--gate" option:

Code: [Select]
`\$ r128gain --helpAn EBU R128 (http://tech.ebu.ch/loudness) compliant loudness scanner.For details refer to "http://r128gain.sourceforge.net/".Usage: r128gain [options] (file|directory)+ [-o <directory> [flac|mkv]]Options:  --r128             Run in EBU R128 compliant mode (default).  --rg               Run in ReplayGain compliant mode.  --r128-compatible  Calibrate output according to EBU R128.  --rg-compatible    Calibrate output according to ReplayGain.  --gate=<float>     R128 gate (-10.0 .. -8.0, default: -8.0).  --rg-calibration=<float>  Aequivalent to use for ReplayGain                     loudness (default: -18.0).  --true-peak=on,--true-peak  Up-sample for peak determination (default).  --true-peak=off,--fast  Switch off up-sampling.  --mono=off         Treat mono as stereo (default).  --mono=on,--mono   Don't treat mono as stereo.  --in-place         Allow overwriting of files in place.  --loglevel=<integer>  Set FFmpeg loglevel.  --regression       Calculate linear regression between EBU R128                     and ReplayGain.  --duration         Print out duration.  --version          Display version information.  --help             Display this information.`

Also interesting:
Quote
Informal tests conducted by
members of the EBU PLOUD group have shown that the difference in the loudness measurement
with and without the -8 LU relative gate of programmes with a small to medium loudness range are
around 0 – 1 LU.

It appears that this is true for almost all test cases except the "Authentic programme 2, stereo, wide Loudness Range (WLR) programme segment; similar in genre to a movie/drama" (the last one):

Code: [Select]
`\$ r128gain --gate=-10.0 ../sounds/ebu-loudness-test-setv01SoX successfully loaded.FFmpeg successfully loaded.../sounds/ebu-loudness-test-setv01  analyzing ...    1kHz Sine -20 LUFS-16bit.wav (1/16): -20.0 LUFS, -3.0 LU (peak: 0.100733: -19.9 dBFS)    1kHz Sine -26 LUFS-16bit.wav (2/16): -26.0 LUFS, 3.0 LU (peak: 0.050508: -25.9 dBFS)    1kHz Sine -40 LUFS-16bit.wav (3/16): -40.0 LUFS, 17.0 LU (peak: 0.010260: -39.8 dBFS)    seq-3341-1-16bit.wav (4/16): -23.0 LUFS, -0.0 LU (peak: 0.071316: -22.9 dBFS)    seq-3341-2-16bit.wav (5/16): -33.0 LUFS, 10.0 LU (peak: 0.023049: -32.7 dBFS)    seq-3341-3-16bit.wav (6/16): -23.0 LUFS, -0.0 LU (peak: 0.071468: -22.9 dBFS)    seq-3341-4-16bit.wav (7/16): -23.0 LUFS, 0.0 LU (peak: 0.070849: -23.0 dBFS)    seq-3341-5-16bit.wav (8/16): -22.9 LUFS, -0.1 LU (peak: 0.100845: -19.9 dBFS)    seq-3341-6-5channels-16bit.wav (9/16): -23.0 LUFS, 0.0 LU (peak: 0.063132: -24.0 dBFS)    seq-3341-6-6channels-WAVEEX-16bit.wav (10/16): -23.0 LUFS, 0.0 LU (peak: 0.063132: -24.0 dBFS)    seq-3341-7_seq-3342-5-24bit.wav (11/16): -23.0 LUFS, -0.0 LU (peak: 0.358340: -8.9 dBFS)    seq-3341-8_seq-3342-6-24bit.wav (12/16): -23.2 LUFS, 0.2 LU (peak: 0.718297: -2.9 dBFS)    seq-3342-1-16bit.wav (13/16): -22.6 LUFS, -0.4 LU (peak: 0.100088: -20.0 dBFS)    seq-3342-2-16bit.wav (14/16): -16.8 LUFS, -6.2 LU (peak: 0.177971: -15.0 dBFS)    seq-3342-3-16bit.wav (15/16): -20.0 LUFS, -3.0 LU (peak: 0.100088: -20.0 dBFS)    seq-3342-4-16bit.wav (16/16): -24.5 LUFS, 1.5 LU (peak: 0.100073: -20.0 dBFS)    ALBUM: -21.9 LUFS, -1.1 LU (peak: 0.718297: -2.9 dBFS)`

For the "Authentic programme 2, stereo, wide Loudness Range (WLR) programme segment; similar in genre to a movie/drama" there is a huge difference of about 4.5 LU.

This mirrors exactly what I've expected: The compromise towards the original un-gated BS.1770 becomes noticeable in case of high dynamics where the gate is thought for.

## R128GAIN: An EBU R128 compliant loudness scanner

##### Reply #248 – 2011-02-27 11:00:36
With R128GAIN v0.8.4 it's possible to parametrize the BS.1770 gate:

The range from -10.0 LU to -8.0 LU is considered EBU R128 compliant.

The command line version offers an respective "--gate" option:

That's nice. We could use that functionality to check the validity of the statement "the results with a relative gate of -10 LU are only marginally different from -8 LU" and could actually report to the P/LOUD group songs where it makes a difference of e.g. more than 1 LU.

Chris

## R128GAIN: An EBU R128 compliant loudness scanner

##### Reply #249 – 2011-02-27 11:20:09
That's nice. We could use that functionality to check the validity of the statement "the results with a relative gate of -10 LU are only marginally different from -8 LU" and could actually report to the P/LOUD group songs where it makes a difference of e.g. more than 1 LU.