R128GAIN: An EBU R128 compliant loudness scanner Options

[Zao]

You cannot always dynamically link to a library, and in any way the LGPL is extremely vague when it comes to class templates, function templates and data in import libraries.

[cpchan]

You cannot always dynamically link to a library,

Please give me an example where you really have to link statically.

and in any way the LGPL is extremely vague when it comes to class templates, function templates and data in import libraries.

Don't know, I don't do C++. However, if is easy enough to ask at gnu.org, if you are interested. However, the program we are discussing is pure C

[C.R.Helmrich]

It is not obvious for me how to quantize the given coefficients with respect to other sample frequencies, hence I decided to re-sample to 48 kHz

For 44.1 kHz, I resampled the 48-kHz filter impulse responses and tried to find new coefficients which match the given transfer function. Here is what I got:

RLB: numerator = [1 -2 1], denominator = [1 -1.9891 0.98913], accurate to ~0.02 dB above 50 Hz
Pre: numerator = [1.535 -2.633 1.151], denominator = [1 -1.647 0.701], accurate to ~0.05 dB, will tune it a bit more soon

R128GAIN interprets this as follows:

• the -70 LUFS is absolute, hence no second path is needed.
• the 8 LU is relative to the 400ms gating block. R128GAIN uses a running 400ms gating block, hence 50% overlap is guarantied and no second pass is needed.

Sorry, but I don't think that's correct. Look at Tech doc 3341, Annex 1. I think the 8 LU is relative to the entire file/album (summation in equation 7, the Jg are the set of 400-ms gating blocks).

Chris

This post has been edited by C.R.Helmrich: Jan 6 2011, 15:35

[pbelkner]

It's GPLv3 (http://www.gnu.org/licenses/gpl.html)

Any reason why? To suit "Free" software uses only?

R128GAIN is heavily based on SoX (uses SoX IO, re-sampler, filters, chain architecture etc.)

IO will probably be re-implemented in order to support most of the existing codecs using FFmpeg.

Both, SoX and FFmpeg, are GPLed, hence R128GAIN is "GPL infected".

Doing so restricts other players like FB2K from using that code, even if a different implementation is made....>_>

Yep.

[Soap]

Both, SoX and FFmpeg, are GPLed, hence R128GAIN is "GPL infected".

ffmepg is v2.1 or later. Is there a reason you went to v3?

[pbelkner]

R128GAIN interprets this as follows:

• the -70 LUFS is absolute, hence no second path is needed.
• the 8 LU is relative to the 400ms gating block. R128GAIN uses a running 400ms gating block, hence 50% overlap is guarantied and no second pass is needed.

Sorry, but I don't think that's correct. Look at Tech doc 3341, Annex 1. I think the 8 LU is relative to the entire file/album (summation in equation 7).

What R128GAIN does is the following (in principle):

• Create an empty gating block capable of holding samples up to 400ms using a ring buffer.
• For each input sample:
  
  • If the gating block is full remove the first sample from it.
  • Add the current sample to the end of the gating block.
  • If the gating block is full:
    
    • Pick the sample cached in the middle of the gating block.
    • Depending on the (un-gated) loudness measure of the gating block decide, whether to add the picked sample to the overall statistics.

That's my understanding of Tech doc 3341, Annex 1, at least in principle.

Hopefully

EBU Tech Doc 3343 ‘Practical Guidelines for Production and Implementation in accordance with EBU R 128’

will clarify this, if published some day.

[cpchan]

ffmepg is v2.1 or later. Is there a reason you went to v3?

Not totally true, there are some code that is under GPL v3 (or later). However, I believe, they will only be enabled if you run configure with " --enable-version3".

[pbelkner]

Both, SoX and FFmpeg, are GPLed, hence R128GAIN is "GPL infected".

ffmepg is v2.1 or later. Is there a reason you went to v3?

Not really.

[Soap]

ffmepg is v2.1 or later. Is there a reason you went to v3?

Not really.

Your call, not mine, but unless you're worried about Tivoation (however you spell it) or one of the other corner cases covered in new by v3, removing v2 becomes a (significant?) restriction on uptake.

[pbelkner]

ffmepg is v2.1 or later. Is there a reason you went to v3?

Not really.

Your call, not mine, but unless you're worried about Tivoation (however you spell it) or one of the other corner cases covered in new by v3, removing v2 becomes a (significant?) restriction on uptake.

I've heard about some discussions regarding v3 but I'm not aware of the details. Maybe it's a good idea to relax to v2 later on.

[saratoga]

ffmepg is v2.1 or later. Is there a reason you went to v3?

Not really.

Your call, not mine, but unless you're worried about Tivoation (however you spell it) or one of the other corner cases covered in new by v3, removing v2 becomes a (significant?) restriction on uptake.

I've heard about some discussions regarding v3 but I'm not aware of the details. Maybe it's a good idea to relax to v2 later on.

I strongly recommend using a "v2 or later" type GPL license, rather then explicitly going v3. It makes it MUCH easier for other people to use your code, and the added protections in the v3 aren't particularly relevant here anyway.

That said, for this kind of code using a GPL front end and an LGPL backend for the actual DSP library makes a lot of sense since it keeps your tool GPL but still allows a wider range of people to use your code without having to re-implement it.

[cpchan]

That said, for this kind of code using a GPL front end and an LGPL backend for the actual DSP library makes a lot of sense since it keeps your tool GPL but still allows a wider range of people to use your code without having to re-implement it.

I totally agree with this.

[GHammer]

Seven of 38 posts on software licensing.
Geesh!

Could we move the non-pertinent holy-war debate to a different thread?

[mudlord]

Seven of 38 posts on software licensing.
Geesh!

Could we move the non-pertinent holy-war debate to a different thread?

Why, its relevant to the software release, so no >_>.

[mudlord]

You cannot always dynamically link to a library,

Please give me an example where you really have to link statically.

To avoid dependancy hell. I am sure FB2K users would appreciate one singular DLL to install rather then the library, SoX, etc, just to tag some files. >_> Sure, with "GNU/Linux" thats not a problem, but with Windows, it sorta is. >_>

Funny how people EXPECT Linux development philosphies to carry over to the Windows world. Well, sorry, we don't have package managers to install all dependancies. Sorry to jerk you around so much.

This post has been edited by mudlord: Jan 7 2011, 07:20

[googlebot]

To avoid dependancy hell. I am sure FB2K users would appreciate one singular DLL to install rather then the library, SoX, etc, just to tag some files. >_> Sure, with "GNU/Linux" thats not a problem, but with Windows, it sorta is. >_>

Funny how people EXPECT Linux development philosphies to carry over to the Windows world. Well, sorry, we don't have package managers to install all dependancies. Sorry to jerk you around so much.

Not even funny but rather irritating how people feel entitled to a demanding tone about something they have neither contributed to nor paid for. No one on this forum has any intention or purpose to fulfill your christmas wish list.

I think you have made your position clear several times. How about you program your own lib or shut up about this now?

This post has been edited by googlebot: Jan 7 2011, 11:28

[romor]

Bad talk. You are free to see his posts if you want to see his contribution to "community"

[Soap]

forget it.


This post has been edited by Soap: Jan 7 2011, 16:54

[googlebot]

Forget this, too. Else the joke doesn't work out.

This post has been edited by googlebot: Jan 7 2011, 17:05

[staale]

Hi,

Just wanted to add that we've released our first try at an open-source implementation EBU R.128 library. It's GPL, does filter coefficients calculation for samplerates other than 48kHz and can measure EBU m, s and i mode. There's also some example programs (including one using ffmpeg/avcodec for decoding).

There's probably lot of bugs and errors, but it seem to function quite well.

Feel free to download and have fun with it.

Regards

Staale @ Radio Nova

[jangk]

Hello,

back to audio issues again.
Thank you pbelkner for working on this EBU R128 subject.
I am convinced that this will bring RG a big step forward.

I tried r128gain and compared it's results with NUGEN Audio VisLM-H (EBU compliant Loudness Meter) using a test track (dynamic music)
Unfortunately the results were not the same.

Further on, the results emanating from the EBU R128 Test Signals (see post#3) do not correspond to the "Expected response and accepted tolerances" as one can see in EBU-TECH 3341.

Am I missing something???

Thank you for your information

Jean

[2Bdecided]

No one on this forum has any intention or purpose to fulfill your christmas wish list.

At a time when I had no idea about any of this, I said that ReplayGain implementations should be GPL. People wanting to use it suggested that LGPL would be better, so I said that instead. Though having published the algorithm without IP protection, I had no legal right to demand either.

There's always...
http://sam.zoy.org/wtfpl/
http://en.wikipedia.org/wiki/WTFPL
The lawyer's fees for making people comply with that one are far less than for the other options

Cheers,
David.

[pbelkner]

Am I missing something???

Of course not:

• I'm aware of EBU R128 only for a few days (cf. discussion with C.R.Helmrich).
• Hacked this in much fewer days (two or three).
• Immediately published v01.
• Consider the tolerance acceptable for practical purposes (cf. test cases 7 and 8).
• Hopefully future releases based on more inside into the standard will further improve the tool.

[mudlord]

How about you program your own lib or shut up about this now?

Since staale posted crystal clear docs, that is a possibility. >_>

I'll STFU and let you GNU/Linux zealots get on with work.

.....this is the last time I will discuss ANYTHING dealing with GPL here. Obviously people's feelings get hurt if Richard Stallman's poster boy is criticised!

[jangk]

Am I missing something???

Of course not:

• I'm aware of EBU R128 only for a few days (cf. discussion with C.R.Helmrich).
• Hacked this in much fewer days (two or three).
• Immediately published v01.
• Consider the tolerance acceptable for practical purposes (cf. test cases 7 and 8).
• Hopefully future releases based on more inside into the standard will further improve the tool.

Ok, thank you, now I understand.

Anyhow, great work in progress
I am excited to see further developement and how it coud work with RG.

Best regards

Jean