IPB

Welcome Guest ( Log In | Register )

23 Pages V  « < 8 9 10 11 12 > »   
Closed TopicStart new topic
R128GAIN: An EBU R128 compliant loudness scanner
jangk
post Feb 1 2011, 15:08
Post #226





Group: Members
Posts: 36
Joined: 31-December 10
Member No.: 86953



@ 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
Go to the top of the page
+Quote Post
pbelkner
post Feb 1 2011, 15:39
Post #227





Group: Members
Posts: 412
Joined: 13-June 10
Member No.: 81467



QUOTE (jangk @ Feb 1 2011, 15:08) *
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:
  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).
Go to the top of the page
+Quote Post
Canar
post Feb 1 2011, 15:52
Post #228





Group: Super Moderator
Posts: 3373
Joined: 26-July 02
From: To:
Member No.: 2796



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


--------------------
You cannot ABX the rustling of jimmies.
No mouse? No problem.
Go to the top of the page
+Quote Post
M
post Feb 1 2011, 16:10
Post #229





Group: Members
Posts: 964
Joined: 29-December 01
Member No.: 830



QUOTE (Canar @ Feb 1 2011, 09:52) *
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.
Go to the top of the page
+Quote Post
Canar
post Feb 1 2011, 16:27
Post #230





Group: Super Moderator
Posts: 3373
Joined: 26-July 02
From: To:
Member No.: 2796



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.


--------------------
You cannot ABX the rustling of jimmies.
No mouse? No problem.
Go to the top of the page
+Quote Post
jangk
post Feb 1 2011, 19:38
Post #231





Group: Members
Posts: 36
Joined: 31-December 10
Member No.: 86953



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
Go to the top of the page
+Quote Post
eevan
post Feb 1 2011, 22:04
Post #232





Group: Members
Posts: 541
Joined: 9-April 07
From: Belgrade, Serbia
Member No.: 42357



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
Go to the top of the page
+Quote Post
pbelkner
post Feb 2 2011, 08:18
Post #233





Group: Members
Posts: 412
Joined: 13-June 10
Member No.: 81467



QUOTE (jangk @ Feb 1 2011, 19:38) *
We are talking about peak voltage, in that case level calculation applies 20*log ...

QUOTE (eevan @ Feb 1 2011, 22:04) *
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.
Go to the top of the page
+Quote Post
jangk
post Feb 2 2011, 08:26
Post #234





Group: Members
Posts: 36
Joined: 31-December 10
Member No.: 86953



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

Great smile.gif

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

Quite true, don't underestimate intersample peaks!

Best regards
Jean
Go to the top of the page
+Quote Post
pbelkner
post Feb 5 2011, 16:26
Post #235





Group: Members
Posts: 412
Joined: 13-June 10
Member No.: 81467



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.
Go to the top of the page
+Quote Post
gjgriffith
post Feb 5 2011, 18:53
Post #236





Group: Members
Posts: 7
Joined: 31-January 11
Member No.: 87795



QUOTE (pbelkner @ Feb 5 2011, 16:26) *


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.
Go to the top of the page
+Quote Post
pbelkner
post Feb 5 2011, 20:18
Post #237





Group: Members
Posts: 412
Joined: 13-June 10
Member No.: 81467



R128GAIN v0.8.1
http://sourceforge.net/projects/r128gain/files/
QUOTE (gjgriffith @ Feb 5 2011, 18:53) *
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:

Go to the top of the page
+Quote Post
bbrabant
post Feb 10 2011, 14:03
Post #238





Group: Members
Posts: 44
Joined: 4-April 07
Member No.: 42201



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
Go to the top of the page
+Quote Post
pbelkner
post Feb 10 2011, 16:04
Post #239





Group: Members
Posts: 412
Joined: 13-June 10
Member No.: 81467



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.
Go to the top of the page
+Quote Post
pbelkner
post Feb 13 2011, 17:24
Post #240





Group: Members
Posts: 412
Joined: 13-June 10
Member No.: 81467



R128GAIN v0.8.3 released
http://sourceforge.net/projects/r128gain/files/
What's new?
  • Supplied a workaround for the VBR issue reported by bbrabant:

    QUOTE (bbrabant @ Feb 10 2011, 14:03) *
    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
Go to the top of the page
+Quote Post
bbrabant
post Feb 13 2011, 19:09
Post #241





Group: Members
Posts: 44
Joined: 4-April 07
Member No.: 42201



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

Go to the top of the page
+Quote Post
pbelkner
post Feb 13 2011, 19:46
Post #242





Group: Members
Posts: 412
Joined: 13-June 10
Member No.: 81467



QUOTE (bbrabant @ Feb 13 2011, 19:09) *
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)?
Go to the top of the page
+Quote Post
bbrabant
post Feb 14 2011, 00:26
Post #243





Group: Members
Posts: 44
Joined: 4-April 07
Member No.: 42201



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
Go to the top of the page
+Quote Post
jangk
post Feb 25 2011, 20:54
Post #244





Group: Members
Posts: 36
Joined: 31-December 10
Member No.: 86953



Hi,

today EBU Tech 3343 was finally published:

EBU Tech 3343

Best regards

Jean
Go to the top of the page
+Quote Post
C.R.Helmrich
post Feb 26 2011, 13:05
Post #245





Group: Developer
Posts: 693
Joined: 6-December 08
From: Erlangen Germany
Member No.: 64012



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


--------------------
If I don't reply to your reply, it means I agree with you.
Go to the top of the page
+Quote Post
Raiden
post Feb 26 2011, 19:46
Post #246





Group: Developer
Posts: 224
Joined: 14-September 04
Member No.: 17002



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.
Go to the top of the page
+Quote Post
jangk
post Feb 26 2011, 21:38
Post #247





Group: Members
Posts: 36
Joined: 31-December 10
Member No.: 86953



QUOTE (C.R.Helmrich @ Feb 26 2011, 13:05) *
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

Go to the top of the page
+Quote Post
pbelkner
post Feb 27 2011, 11:52
Post #248





Group: Members
Posts: 412
Joined: 13-June 10
Member No.: 81467



R128GAIN v0.8.4 released:
http://sourceforge.net/projects/r128gain/files/
What's new?

QUOTE (C.R.Helmrich @ Feb 26 2011, 13:05) *
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
$ 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.

QUOTE (Raiden @ Feb 26 2011, 19:46) *
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
$ 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
Go to the top of the page
+Quote Post
C.R.Helmrich
post Feb 27 2011, 12:00
Post #249





Group: Developer
Posts: 693
Joined: 6-December 08
From: Erlangen Germany
Member No.: 64012



QUOTE (pbelkner @ Feb 27 2011, 12:52) *
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


--------------------
If I don't reply to your reply, it means I agree with you.
Go to the top of the page
+Quote Post
pbelkner
post Feb 27 2011, 12:20
Post #250





Group: Members
Posts: 412
Joined: 13-June 10
Member No.: 81467



QUOTE (C.R.Helmrich @ Feb 27 2011, 12:00) *
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:

QUOTE (pbelkner @ Feb 27 2011, 11:52) *
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.
Go to the top of the page
+Quote Post

23 Pages V  « < 8 9 10 11 12 > » 
Closed TopicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 19th December 2014 - 12:01