R128GAIN: An EBU R128 compliant loudness scanner Options

[jangk]

@ pbelkner:

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

[pbelkner]

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:

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).

[Canar]

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...

[M]

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.

[Canar]

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.

This post has been edited by Canar: Feb 1 2011, 17:03

Reason for edit: Not splitting.

[jangk]

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

[eevan]

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(V²/V²ref)=20*log(V/Vref).

Cheers

[pbelkner]

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(V²/V²ref)=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.

[jangk]

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

Great

This underlines what an important tool true peak measurement is.

Quite true, don't underestimate intersample peaks!

Best regards
Jean

[pbelkner]

R128GAIN v0.8 released

http://sourceforge.net/projects/r128gain/files/

What's new?

• Streamcopy for (hopefully) allmost all formats and codecs supported by FFmpeg. E.g. for tagging Youtube videos try the following:
  
  
  CODE
  r128gain *.flv -o out_dir
  
  
• You may also wrap them into a MKV container:
  
  
  CODE
  r128gain *.flv -o out_dir mkv
  
  
• Mono is treated as stereo by default (requested by gjgriffith). You may force mono treatment:
  
  
  CODE
  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

$ r128gain.exe --help
An 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.

[gjgriffith]

R128GAIN v0.8 released

http://sourceforge.net/projects/r128gain/files/

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.

[pbelkner]

R128GAIN v0.8.1

http://sourceforge.net/projects/r128gain/files/

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:

[bbrabant]

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

[pbelkner]

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
  $ lame -V2 ref_pink.wav ref_pink.mp3
  
  
  CODE
  $ 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
  $ r128gain ref_pink.mp3 -o OUT
  
  
  CODE
  $ ffmpeg -i OUT/ref_pink.mp3
  ...
  [mp3 @ 0048d530] Estimating duration from bitrate, this may be inaccurate
  Input #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
  ffmpeg -i ref_pink.mp3 -acodec copy -y OUT/ref_pink_ffmpeg.mp3
  
  
  CODE
  $ ffmpeg -i OUT/ref_pink_ffmpeg.mp3
  ...
  [mp3 @ 0048d530] Estimating duration from bitrate, this may be inaccurate
  Input #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.

[pbelkner]

R128GAIN v0.8.3 released

http://sourceforge.net/projects/r128gain/files/

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
    #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
    $ 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
  $ 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.

This post has been edited by pbelkner: Feb 13 2011, 17:28

[bbrabant]

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

[pbelkner]

Compiling FFmpeg myself is a bit to technical for me.

Please check your private mail.

BTW: Does somebody know about the patent/license issues with respect to MPEG audio frame headers (maybe starting a respective thread)?

[bbrabant]

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

[jangk]

Hi,

today EBU Tech 3343 was finally published:

EBU Tech 3343

Best regards

Jean

[C.R.Helmrich]

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:

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:

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:

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:

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

[Raiden]

Also interesting:

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.

[jangk]

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

[pbelkner]

R128GAIN v0.8.4 released:

http://sourceforge.net/projects/r128gain/files/

What's new?

Page 12:

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

$ r128gain --help
An 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:

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

$ r128gain --gate=-10.0 ../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.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.

This post has been edited by pbelkner: Feb 27 2011, 11:53

[C.R.Helmrich]

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

[pbelkner]

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.

As already stated:

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.

Provided I've made no mistake ...

Maybe Raiden can incorporate this feature in his tool as well? This would enable us to have a second independent test.