LUFS measurment for short length audio

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

LUFS measurment for short length audio

christian.will
 

Hi list!

 

Can somebody help to measure LUFS for audio files under 0,4 seconds???

 

Yours sincerly

Chris

 

_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: LUFS measurment for short length audio

Bouke-3

> On 09 Sep 2020, at 10:33, [hidden email] wrote:
>
>
>
> Hi list!
>
>
>
> Can somebody help to measure LUFS for audio files under 0,4 seconds???
>

Cat it a couple of times first?

Bouke

>
>
> Yours sincerly
>
> Chris
>
>
>
> _______________________________________________
> ffmpeg-user mailing list
> [hidden email]
> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> [hidden email] with subject "unsubscribe".

_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: LUFS measurment for short length audio

Gyan Doshi-2


On 14-09-2020 01:15 pm, Bouke wrote:

>> On 09 Sep 2020, at 10:33, [hidden email] wrote:
>>
>>
>>
>> Hi list!
>>
>>
>>
>> Can somebody help to measure LUFS for audio files under 0,4 seconds???
>>
> Cat it a couple of times first?

A few more times is required. Total duration should be  >3 seconds.

See https://superuser.com/q/1281327/

Gyan
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: LUFS measurment for short length audio

christian.will

To cat means to loop the file until it is longer then 0,4s?

Yes we tried, there is a variation of 3db or more, so it is kind of suboptimal.
We also know the loudnorm command.

We use this command atm to read out values:

ffmpeg -nostats -i 'filename' -filter_complex ebur128 -f null -

and it is fine with all files >0,4s. As it should be relating to the ebu128 definition.

Anyway, our customer provides us with lufs values for shorter lenghts and he wont tell us how he analyses it.

Now we tried to read out momentary lufs, as it works with 400ms windows, but im not sure if i get correct values here.
As it shows -120db mLUFS for an example and on proTools it says -23--24db (with DPMeterXP2)

Anybody an idea how to read out reliable momentary LUFS values with ffmpeg?





-----Ursprüngliche Nachricht-----
Von: ffmpeg-user <[hidden email]> Im Auftrag von Gyan Doshi
Gesendet: Montag, 14. September 2020 09:50
An: [hidden email]
Betreff: Re: [FFmpeg-user] LUFS measurment for short length audio



On 14-09-2020 01:15 pm, Bouke wrote:

>> On 09 Sep 2020, at 10:33, [hidden email] wrote:
>>
>>
>>
>> Hi list!
>>
>>
>>
>> Can somebody help to measure LUFS for audio files under 0,4 seconds???
>>
> Cat it a couple of times first?

A few more times is required. Total duration should be  >3 seconds.

See https://superuser.com/q/1281327/

Gyan
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email [hidden email] with subject "unsubscribe".

_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: LUFS measurment for short length audio

Bouke-3

> On 14 Sep 2020, at 13:23, [hidden email] wrote:
>
>
> To cat means to loop the file until it is longer then 0,4s?

yes

>
> Yes we tried, there is a variation of 3db or more, so it is kind of suboptimal.

If it’s exact 3db, it smells like you might render the file to mono on catting, are you sure that’s not the case?

> We also know the loudnorm command.

Why, if you want to conform to R128 specs, you analyse, get the I value, and lower / up the volume by the measured Integrated minus target Integrated (in Db, one LU is equal to one dB)
>
> We use this command atm to read out values:
>
> ffmpeg -nostats -i 'filename' -filter_complex ebur128 -f null

This might or might not work, if it’s 5.1, you would need to omit the LFE channel, and if there are multiple tracks you would need to patch the correct ones first.
So, full command line / output missing :-) (I would never think I would write this…)

> and it is fine with all files >0,4s. As it should be relating to the ebu128 definition.
>
> Anyway, our customer provides us with lufs values for shorter lenghts and he wont tell us how he analyses it.

So you have no clue if your client measurements are correct? I would not accept this, you would need to reverse engineer your clients steps...

>
> Now we tried to read out momentary lufs, as it works with 400ms windows, but im not sure if i get correct values here.
> As it shows -120db mLUFS for an example and on proTools it says -23--24db (with DPMeterXP2)

-120 is silence…

>
> Anybody an idea how to read out reliable momentary LUFS values with ffmpeg?

Not sure how reliable it is, but it’s just in the output I would think…

Bouke


>
> -----Ursprüngliche Nachricht-----
> Von: ffmpeg-user <[hidden email]> Im Auftrag von Gyan Doshi
> Gesendet: Montag, 14. September 2020 09:50
> An: [hidden email]
> Betreff: Re: [FFmpeg-user] LUFS measurment for short length audio
>
>
>
> On 14-09-2020 01:15 pm, Bouke wrote:
>>> On 09 Sep 2020, at 10:33, [hidden email] wrote:
>>>
>>>
>>>
>>> Hi list!
>>>
>>>
>>>
>>> Can somebody help to measure LUFS for audio files under 0,4 seconds???
>>>
>> Cat it a couple of times first?
>
> A few more times is required. Total duration should be  >3 seconds.
>
> See https://superuser.com/q/1281327/
>
> Gyan
> _______________________________________________
>

_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: LUFS measurment for short length audio

christian.will
Its all mono we are talking about here

Full command line would be
ffmpeg -nostats -i '#{filename}' -filter_complex ebur128 -f null - 2>&1
(i only forward this from the IT section, but its the standard ffmpeg lufs measurment as far as i know)

yes, we dont know if the customer values are correct. The problem is, there is no correct if you dont use the same method/algo.
There are different meters coming up with different values on LUFSs, specially if you are under 0,4s.
You are right, the best would be to use the same method, but our customer wont share their method and we cant reverse engineer something we dont own.

Yes, there ist the (m) value in the output, but i think its not very reliable ... as the file measured isnt silent 😊



-----Ursprüngliche Nachricht-----
Von: ffmpeg-user <[hidden email]> Im Auftrag von Bouke
Gesendet: Montag, 14. September 2020 13:41
An: FFmpeg user questions <[hidden email]>
Betreff: Re: [FFmpeg-user] LUFS measurment for short length audio


> On 14 Sep 2020, at 13:23, [hidden email] wrote:
>
>
> To cat means to loop the file until it is longer then 0,4s?

yes

>
> Yes we tried, there is a variation of 3db or more, so it is kind of suboptimal.

If it’s exact 3db, it smells like you might render the file to mono on catting, are you sure that’s not the case?

> We also know the loudnorm command.

Why, if you want to conform to R128 specs, you analyse, get the I value, and lower / up the volume by the measured Integrated minus target Integrated (in Db, one LU is equal to one dB)
>
> We use this command atm to read out values:
>
> ffmpeg -nostats -i 'filename' -filter_complex ebur128 -f null

This might or might not work, if it’s 5.1, you would need to omit the LFE channel, and if there are multiple tracks you would need to patch the correct ones first.
So, full command line / output missing :-) (I would never think I would write this…)

> and it is fine with all files >0,4s. As it should be relating to the ebu128 definition.
>
> Anyway, our customer provides us with lufs values for shorter lenghts and he wont tell us how he analyses it.

So you have no clue if your client measurements are correct? I would not accept this, you would need to reverse engineer your clients steps...

>
> Now we tried to read out momentary lufs, as it works with 400ms windows, but im not sure if i get correct values here.
> As it shows -120db mLUFS for an example and on proTools it says
> -23--24db (with DPMeterXP2)

-120 is silence…

>
> Anybody an idea how to read out reliable momentary LUFS values with ffmpeg?

Not sure how reliable it is, but it’s just in the output I would think…

Bouke


>
> -----Ursprüngliche Nachricht-----
> Von: ffmpeg-user <[hidden email]> Im Auftrag von Gyan
> Doshi
> Gesendet: Montag, 14. September 2020 09:50
> An: [hidden email]
> Betreff: Re: [FFmpeg-user] LUFS measurment for short length audio
>
>
>
> On 14-09-2020 01:15 pm, Bouke wrote:
>>> On 09 Sep 2020, at 10:33, [hidden email] wrote:
>>>
>>>
>>>
>>> Hi list!
>>>
>>>
>>>
>>> Can somebody help to measure LUFS for audio files under 0,4 seconds???
>>>
>> Cat it a couple of times first?
>
> A few more times is required. Total duration should be  >3 seconds.
>
> See https://superuser.com/q/1281327/
>
> Gyan
> _______________________________________________
>

_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email [hidden email] with subject "unsubscribe".

_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: LUFS measurment for short length audio

Bouke-3

> On 14 Sep 2020, at 13:54, <[hidden email]> <[hidden email]> wrote:
>
> Its all mono we are talking about here
>
> Full command line would be
> ffmpeg -nostats -i '#{filename}' -filter_complex ebur128 -f null - 2>&1
> (i only forward this from the IT section, but its the standard ffmpeg lufs measurment as far as i know)
>
> yes, we dont know if the customer values are correct. The problem is, there is no correct if you dont use the same method/algo.
> There are different meters coming up with different values on LUFSs, specially if you are under 0,4s.
> You are right, the best would be to use the same method, but our customer wont share their method and we cant reverse engineer something we dont own.
>
> Yes, there ist the (m) value in the output, but i think its not very reliable ... as the file measured isnt silent 😊

I would think M is not relevant, as it should equal I if the file is 400 Msecs…
And I can reproduce the issue on a short file. But, if I cat the file with silence before / after, then measure with adding -ss yadda -t sourcedur it seems to work.
(But a looped input results the same values when scanned fully.)


 
Bouke.


>
>
>
> -----Ursprüngliche Nachricht-----
> Von: ffmpeg-user <[hidden email]> Im Auftrag von Bouke
> Gesendet: Montag, 14. September 2020 13:41
> An: FFmpeg user questions <[hidden email]>
> Betreff: Re: [FFmpeg-user] LUFS measurment for short length audio
>
>
>> On 14 Sep 2020, at 13:23, [hidden email] wrote:
>>
>>
>> To cat means to loop the file until it is longer then 0,4s?
>
> yes
>
>>
>> Yes we tried, there is a variation of 3db or more, so it is kind of suboptimal.
>
> If it’s exact 3db, it smells like you might render the file to mono on catting, are you sure that’s not the case?
>
>> We also know the loudnorm command.
>
> Why, if you want to conform to R128 specs, you analyse, get the I value, and lower / up the volume by the measured Integrated minus target Integrated (in Db, one LU is equal to one dB)
>>
>> We use this command atm to read out values:
>>
>> ffmpeg -nostats -i 'filename' -filter_complex ebur128 -f null
>
> This might or might not work, if it’s 5.1, you would need to omit the LFE channel, and if there are multiple tracks you would need to patch the correct ones first.
> So, full command line / output missing :-) (I would never think I would write this…)
>
>> and it is fine with all files >0,4s. As it should be relating to the ebu128 definition.
>>
>> Anyway, our customer provides us with lufs values for shorter lenghts and he wont tell us how he analyses it.
>
> So you have no clue if your client measurements are correct? I would not accept this, you would need to reverse engineer your clients steps...
>
>>
>> Now we tried to read out momentary lufs, as it works with 400ms windows, but im not sure if i get correct values here.
>> As it shows -120db mLUFS for an example and on proTools it says
>> -23--24db (with DPMeterXP2)
>
> -120 is silence…
>
>>
>> Anybody an idea how to read out reliable momentary LUFS values with ffmpeg?
>
> Not sure how reliable it is, but it’s just in the output I would think…
>
> Bouke
>
>
>>
>> -----Ursprüngliche Nachricht-----
>> Von: ffmpeg-user <[hidden email]> Im Auftrag von Gyan
>> Doshi
>> Gesendet: Montag, 14. September 2020 09:50
>> An: [hidden email]
>> Betreff: Re: [FFmpeg-user] LUFS measurment for short length audio
>>
>>
>>
>> On 14-09-2020 01:15 pm, Bouke wrote:
>>>> On 09 Sep 2020, at 10:33, [hidden email] wrote:
>>>>
>>>>
>>>>
>>>> Hi list!
>>>>
>>>>
>>>>
>>>> Can somebody help to measure LUFS for audio files under 0,4 seconds???
>>>>
>>> Cat it a couple of times first?
>>
>> A few more times is required. Total duration should be  >3 seconds.
>>
>> See https://superuser.com/q/1281327/
>>
>> Gyan
>> _______________________________________________
>>
>
> _______________________________________________
> ffmpeg-user mailing list
> [hidden email]
> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email [hidden email] with subject "unsubscribe".
>
> _______________________________________________
> ffmpeg-user mailing list
> [hidden email]
> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> [hidden email] with subject "unsubscribe".

_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: LUFS measurment for short length audio

christian.will
Thanks for measuring Bouke!
Guess momentary isnt working with <0,4s too.

I tried my example with adding silence before and after and i get both times -23.3db LUFS for i & m.
Which is a 1db variation to the customers value. If all files are coming with a 1db difference, that would be something we could work with.
So we are not precisely here, but its good enough for now.
I wonder how the meters are measuring it. As they dont have problmes with durations.
We will try ...


-----Ursprüngliche Nachricht-----
Von: ffmpeg-user <[hidden email]> Im Auftrag von Bouke
Gesendet: Montag, 14. September 2020 14:08
An: FFmpeg user questions <[hidden email]>
Betreff: Re: [FFmpeg-user] LUFS measurment for short length audio


> On 14 Sep 2020, at 13:54, <[hidden email]> <[hidden email]> wrote:
>
> Its all mono we are talking about here
>
> Full command line would be
> ffmpeg -nostats -i '#{filename}' -filter_complex ebur128 -f null -
> 2>&1 (i only forward this from the IT section, but its the standard
> ffmpeg lufs measurment as far as i know)
>
> yes, we dont know if the customer values are correct. The problem is, there is no correct if you dont use the same method/algo.
> There are different meters coming up with different values on LUFSs, specially if you are under 0,4s.
> You are right, the best would be to use the same method, but our customer wont share their method and we cant reverse engineer something we dont own.
>
> Yes, there ist the (m) value in the output, but i think its not very
> reliable ... as the file measured isnt silent 😊

I would think M is not relevant, as it should equal I if the file is 400 Msecs… And I can reproduce the issue on a short file. But, if I cat the file with silence before / after, then measure with adding -ss yadda -t sourcedur it seems to work.
(But a looped input results the same values when scanned fully.)


 
Bouke.


>
>
>
> -----Ursprüngliche Nachricht-----
> Von: ffmpeg-user <[hidden email]> Im Auftrag von Bouke
> Gesendet: Montag, 14. September 2020 13:41
> An: FFmpeg user questions <[hidden email]>
> Betreff: Re: [FFmpeg-user] LUFS measurment for short length audio
>
>
>> On 14 Sep 2020, at 13:23, [hidden email] wrote:
>>
>>
>> To cat means to loop the file until it is longer then 0,4s?
>
> yes
>
>>
>> Yes we tried, there is a variation of 3db or more, so it is kind of suboptimal.
>
> If it’s exact 3db, it smells like you might render the file to mono on catting, are you sure that’s not the case?
>
>> We also know the loudnorm command.
>
> Why, if you want to conform to R128 specs, you analyse, get the I
> value, and lower / up the volume by the measured Integrated minus
> target Integrated (in Db, one LU is equal to one dB)
>>
>> We use this command atm to read out values:
>>
>> ffmpeg -nostats -i 'filename' -filter_complex ebur128 -f null
>
> This might or might not work, if it’s 5.1, you would need to omit the LFE channel, and if there are multiple tracks you would need to patch the correct ones first.
> So, full command line / output missing :-) (I would never think I
> would write this…)
>
>> and it is fine with all files >0,4s. As it should be relating to the ebu128 definition.
>>
>> Anyway, our customer provides us with lufs values for shorter lenghts and he wont tell us how he analyses it.
>
> So you have no clue if your client measurements are correct? I would not accept this, you would need to reverse engineer your clients steps...
>
>>
>> Now we tried to read out momentary lufs, as it works with 400ms windows, but im not sure if i get correct values here.
>> As it shows -120db mLUFS for an example and on proTools it says
>> -23--24db (with DPMeterXP2)
>
> -120 is silence…
>
>>
>> Anybody an idea how to read out reliable momentary LUFS values with ffmpeg?
>
> Not sure how reliable it is, but it’s just in the output I would
> think…
>
> Bouke
>
>
>>
>> -----Ursprüngliche Nachricht-----
>> Von: ffmpeg-user <[hidden email]> Im Auftrag von Gyan
>> Doshi
>> Gesendet: Montag, 14. September 2020 09:50
>> An: [hidden email]
>> Betreff: Re: [FFmpeg-user] LUFS measurment for short length audio
>>
>>
>>
>> On 14-09-2020 01:15 pm, Bouke wrote:
>>>> On 09 Sep 2020, at 10:33, [hidden email] wrote:
>>>>
>>>>
>>>>
>>>> Hi list!
>>>>
>>>>
>>>>
>>>> Can somebody help to measure LUFS for audio files under 0,4 seconds???
>>>>
>>> Cat it a couple of times first?
>>
>> A few more times is required. Total duration should be  >3 seconds.
>>
>> See https://superuser.com/q/1281327/
>>
>> Gyan
>> _______________________________________________
>>
>
> _______________________________________________
> ffmpeg-user mailing list
> [hidden email]
> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email [hidden email] with subject "unsubscribe".
>
> _______________________________________________
> ffmpeg-user mailing list
> [hidden email]
> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> [hidden email] with subject "unsubscribe".

_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email [hidden email] with subject "unsubscribe".

_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: LUFS measurment for short length audio

Bouke-3


> On 14 Sep 2020, at 14:27, [hidden email] wrote:
>
> Thanks for measuring Bouke!
> Guess momentary isnt working with <0,4s too.

Of course not, for both Momentary and Short, there is not enough media to measure it, take it it will be the same as Integrated. (And meaningless for such short files.)

>
> I tried my example with adding silence before and after and i get both times -23.3db LUFS for i & m.

What happens when you use -ss and -t besides the silence (to crop the silence start / end, work here…)

> Which is a 1db variation to the customers value. If all files are coming with a 1db difference, that would be something we could work with.
> So we are not precisely here, but its good enough for now.
> I wonder how the meters are measuring it. As they dont have problmes with durations.
> We will try ...

1 dB is not really a big difference I would think, and since this is not broadcast I take it, it ‘should’ not matter, as long as all input gets to the same percepted value.

What are you doing, game assets?

Bouke

>
>
> -----Ursprüngliche Nachricht-----
> Von: ffmpeg-user <[hidden email]> Im Auftrag von Bouke
> Gesendet: Montag, 14. September 2020 14:08
> An: FFmpeg user questions <[hidden email]>
> Betreff: Re: [FFmpeg-user] LUFS measurment for short length audio
>
>
>> On 14 Sep 2020, at 13:54, <[hidden email]> <[hidden email]> wrote:
>>
>> Its all mono we are talking about here
>>
>> Full command line would be
>> ffmpeg -nostats -i '#{filename}' -filter_complex ebur128 -f null -
>> 2>&1 (i only forward this from the IT section, but its the standard
>> ffmpeg lufs measurment as far as i know)
>>
>> yes, we dont know if the customer values are correct. The problem is, there is no correct if you dont use the same method/algo.
>> There are different meters coming up with different values on LUFSs, specially if you are under 0,4s.
>> You are right, the best would be to use the same method, but our customer wont share their method and we cant reverse engineer something we dont own.
>>
>> Yes, there ist the (m) value in the output, but i think its not very
>> reliable ... as the file measured isnt silent 😊
>
> I would think M is not relevant, as it should equal I if the file is 400 Msecs… And I can reproduce the issue on a short file. But, if I cat the file with silence before / after, then measure with adding -ss yadda -t sourcedur it seems to work.
> (But a looped input results the same values when scanned fully.)
>
>
>
> Bouke.
>
>
>>
>>
>>
>> -----Ursprüngliche Nachricht-----
>> Von: ffmpeg-user <[hidden email]> Im Auftrag von Bouke
>> Gesendet: Montag, 14. September 2020 13:41
>> An: FFmpeg user questions <[hidden email]>
>> Betreff: Re: [FFmpeg-user] LUFS measurment for short length audio
>>
>>
>>> On 14 Sep 2020, at 13:23, [hidden email] wrote:
>>>
>>>
>>> To cat means to loop the file until it is longer then 0,4s?
>>
>> yes
>>
>>>
>>> Yes we tried, there is a variation of 3db or more, so it is kind of suboptimal.
>>
>> If it’s exact 3db, it smells like you might render the file to mono on catting, are you sure that’s not the case?
>>
>>> We also know the loudnorm command.
>>
>> Why, if you want to conform to R128 specs, you analyse, get the I
>> value, and lower / up the volume by the measured Integrated minus
>> target Integrated (in Db, one LU is equal to one dB)
>>>
>>> We use this command atm to read out values:
>>>
>>> ffmpeg -nostats -i 'filename' -filter_complex ebur128 -f null
>>
>> This might or might not work, if it’s 5.1, you would need to omit the LFE channel, and if there are multiple tracks you would need to patch the correct ones first.
>> So, full command line / output missing :-) (I would never think I
>> would write this…)
>>
>>> and it is fine with all files >0,4s. As it should be relating to the ebu128 definition.
>>>
>>> Anyway, our customer provides us with lufs values for shorter lenghts and he wont tell us how he analyses it.
>>
>> So you have no clue if your client measurements are correct? I would not accept this, you would need to reverse engineer your clients steps...
>>
>>>
>>> Now we tried to read out momentary lufs, as it works with 400ms windows, but im not sure if i get correct values here.
>>> As it shows -120db mLUFS for an example and on proTools it says
>>> -23--24db (with DPMeterXP2)
>>
>> -120 is silence…
>>
>>>
>>> Anybody an idea how to read out reliable momentary LUFS values with ffmpeg?
>>
>> Not sure how reliable it is, but it’s just in the output I would
>> think…
>>
>> Bouke
>>
>>
>>>
>>> -----Ursprüngliche Nachricht-----
>>> Von: ffmpeg-user <[hidden email]> Im Auftrag von Gyan
>>> Doshi
>>> Gesendet: Montag, 14. September 2020 09:50
>>> An: [hidden email]
>>> Betreff: Re: [FFmpeg-user] LUFS measurment for short length audio
>>>
>>>
>>>
>>> On 14-09-2020 01:15 pm, Bouke wrote:
>>>>> On 09 Sep 2020, at 10:33, [hidden email] wrote:
>>>>>
>>>>>
>>>>>
>>>>> Hi list!
>>>>>
>>>>>
>>>>>
>>>>> Can somebody help to measure LUFS for audio files under 0,4 seconds???
>>>>>
>>>> Cat it a couple of times first?
>>>
>>> A few more times is required. Total duration should be  >3 seconds.
>>>
>>> See https://superuser.com/q/1281327/
>>>
>>> Gyan
>>> _______________________________________________
>>>
>>
>> _______________________________________________
>> ffmpeg-user mailing list
>> [hidden email]
>> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>>
>> To unsubscribe, visit link above, or email [hidden email] with subject "unsubscribe".
>>
>> _______________________________________________
>> ffmpeg-user mailing list
>> [hidden email]
>> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>>
>> To unsubscribe, visit link above, or email
>> [hidden email] with subject "unsubscribe".
>
> _______________________________________________
> ffmpeg-user mailing list
> [hidden email]
> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email [hidden email] with subject "unsubscribe".
>
> _______________________________________________
> ffmpeg-user mailing list
> [hidden email]
> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> [hidden email] with subject "unsubscribe".

_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: LUFS measurment for short length audio

christian.will


> On 14 Sep 2020, at 14:27, [hidden email] wrote:

>
> I tried my example with adding silence before and after and i get both times -23.3db LUFS for i & m.

>>What happens when you use -ss and -t besides the silence (to crop the silence start / end, work here…)

How does this work? Does it crop the silence from the file or is it just for not measuring the silence parts at beginning and end??
Do you have a command i can try?


> Which is a 1db variation to the customers value. If all files are coming with a 1db difference, that would be something we could work with.
> So we are not precisely here, but its good enough for now.
> I wonder how the meters are measuring it. As they dont have problmes with durations.
> We will try ...

>>1 dB is not really a big difference I would think, and since this is not broadcast I take it, it ‘should’ not matter, as long as all input gets to the same percepted value.

Yes its not much, but its mostly due to controlling issues, not to hit the same value. So the measurement must be somehow exact, up to +-2db variation to make sure the controlling is useful. When it comes to close-up diaologs and heavy compression, 2 - 4 db can be a lot. But this is the minor case mostly 😊


What are you doing, game assets?
😊 yep


Bouke

>
>
> -----Ursprüngliche Nachricht-----
> Von: ffmpeg-user <[hidden email]> Im Auftrag von Bouke
> Gesendet: Montag, 14. September 2020 14:08
> An: FFmpeg user questions <[hidden email]>
> Betreff: Re: [FFmpeg-user] LUFS measurment for short length audio
>
>
>> On 14 Sep 2020, at 13:54, <[hidden email]> <[hidden email]> wrote:
>>
>> Its all mono we are talking about here
>>
>> Full command line would be
>> ffmpeg -nostats -i '#{filename}' -filter_complex ebur128 -f null -
>> 2>&1 (i only forward this from the IT section, but its the standard
>> ffmpeg lufs measurment as far as i know)
>>
>> yes, we dont know if the customer values are correct. The problem is, there is no correct if you dont use the same method/algo.
>> There are different meters coming up with different values on LUFSs, specially if you are under 0,4s.
>> You are right, the best would be to use the same method, but our customer wont share their method and we cant reverse engineer something we dont own.
>>
>> Yes, there ist the (m) value in the output, but i think its not very
>> reliable ... as the file measured isnt silent 😊
>
> I would think M is not relevant, as it should equal I if the file is 400 Msecs… And I can reproduce the issue on a short file. But, if I cat the file with silence before / after, then measure with adding -ss yadda -t sourcedur it seems to work.
> (But a looped input results the same values when scanned fully.)
>
>
>
> Bouke.
>
>
>>
>>
>>
>> -----Ursprüngliche Nachricht-----
>> Von: ffmpeg-user <[hidden email]> Im Auftrag von
>> Bouke
>> Gesendet: Montag, 14. September 2020 13:41
>> An: FFmpeg user questions <[hidden email]>
>> Betreff: Re: [FFmpeg-user] LUFS measurment for short length audio
>>
>>
>>> On 14 Sep 2020, at 13:23, [hidden email] wrote:
>>>
>>>
>>> To cat means to loop the file until it is longer then 0,4s?
>>
>> yes
>>
>>>
>>> Yes we tried, there is a variation of 3db or more, so it is kind of suboptimal.
>>
>> If it’s exact 3db, it smells like you might render the file to mono on catting, are you sure that’s not the case?
>>
>>> We also know the loudnorm command.
>>
>> Why, if you want to conform to R128 specs, you analyse, get the I
>> value, and lower / up the volume by the measured Integrated minus
>> target Integrated (in Db, one LU is equal to one dB)
>>>
>>> We use this command atm to read out values:
>>>
>>> ffmpeg -nostats -i 'filename' -filter_complex ebur128 -f null
>>
>> This might or might not work, if it’s 5.1, you would need to omit the LFE channel, and if there are multiple tracks you would need to patch the correct ones first.
>> So, full command line / output missing :-) (I would never think I
>> would write this…)
>>
>>> and it is fine with all files >0,4s. As it should be relating to the ebu128 definition.
>>>
>>> Anyway, our customer provides us with lufs values for shorter lenghts and he wont tell us how he analyses it.
>>
>> So you have no clue if your client measurements are correct? I would not accept this, you would need to reverse engineer your clients steps...
>>
>>>
>>> Now we tried to read out momentary lufs, as it works with 400ms windows, but im not sure if i get correct values here.
>>> As it shows -120db mLUFS for an example and on proTools it says
>>> -23--24db (with DPMeterXP2)
>>
>> -120 is silence…
>>
>>>
>>> Anybody an idea how to read out reliable momentary LUFS values with ffmpeg?
>>
>> Not sure how reliable it is, but it’s just in the output I would
>> think…
>>
>> Bouke
>>
>>
>>>
>>> -----Ursprüngliche Nachricht-----
>>> Von: ffmpeg-user <[hidden email]> Im Auftrag von
>>> Gyan Doshi
>>> Gesendet: Montag, 14. September 2020 09:50
>>> An: [hidden email]
>>> Betreff: Re: [FFmpeg-user] LUFS measurment for short length audio
>>>
>>>
>>>
>>> On 14-09-2020 01:15 pm, Bouke wrote:
>>>>> On 09 Sep 2020, at 10:33, [hidden email] wrote:
>>>>>
>>>>>
>>>>>
>>>>> Hi list!
>>>>>
>>>>>
>>>>>
>>>>> Can somebody help to measure LUFS for audio files under 0,4 seconds???
>>>>>
>>>> Cat it a couple of times first?
>>>
>>> A few more times is required. Total duration should be  >3 seconds.
>>>
>>> See https://superuser.com/q/1281327/
>>>
>>> Gyan
>>> _______________________________________________
>>>
>>
>> _______________________________________________
>> ffmpeg-user mailing list
>> [hidden email]
>> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>>
>> To unsubscribe, visit link above, or email [hidden email] with subject "unsubscribe".
>>
>> _______________________________________________
>> ffmpeg-user mailing list
>> [hidden email]
>> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>>
>> To unsubscribe, visit link above, or email
>> [hidden email] with subject "unsubscribe".
>
> _______________________________________________
> ffmpeg-user mailing list
> [hidden email]
> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email [hidden email] with subject "unsubscribe".
>
> _______________________________________________
> ffmpeg-user mailing list
> [hidden email]
> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> [hidden email] with subject "unsubscribe".

_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email [hidden email] with subject "unsubscribe".

_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: LUFS measurment for short length audio

Bouke-3


> On 14 Sep 2020, at 15:56, [hidden email] wrote:
>
>
>
>> On 14 Sep 2020, at 14:27, [hidden email] <mailto:[hidden email]> wrote:
>
>>
>> I tried my example with adding silence before and after and i get both times -23.3db LUFS for i & m.
>
>>> What happens when you use -ss and -t besides the silence (to crop the silence start / end, work here…)
>
> How does this work? Does it crop the silence from the file or is it just for not measuring the silence parts at beginning and end??
> Do you have a command i can try?

Put in -ss <duration added silence start in secs> -t <duration added silence at end in secs> after the -i <input>

Bouke

>
>
>> Which is a 1db variation to the customers value. If all files are coming with a 1db difference, that would be something we could work with.
>> So we are not precisely here, but its good enough for now.
>> I wonder how the meters are measuring it. As they dont have problmes with durations.
>> We will try ...
>
>>> 1 dB is not really a big difference I would think, and since this is not broadcast I take it, it ‘should’ not matter, as long as all input gets to the same percepted value.
>
> Yes its not much, but its mostly due to controlling issues, not to hit the same value. So the measurement must be somehow exact, up to +-2db variation to make sure the controlling is useful. When it comes to close-up diaologs and heavy compression, 2 - 4 db can be a lot. But this is the minor case mostly 😊
>
>
> What are you doing, game assets?
> 😊 yep
>
>
> Bouke
>
>>
>>
>> -----Ursprüngliche Nachricht-----
>> Von: ffmpeg-user <[hidden email]> Im Auftrag von Bouke
>> Gesendet: Montag, 14. September 2020 14:08
>> An: FFmpeg user questions <[hidden email]>
>> Betreff: Re: [FFmpeg-user] LUFS measurment for short length audio
>>
>>
>>> On 14 Sep 2020, at 13:54, <[hidden email]> <[hidden email]> wrote:
>>>
>>> Its all mono we are talking about here
>>>
>>> Full command line would be
>>> ffmpeg -nostats -i '#{filename}' -filter_complex ebur128 -f null -
>>> 2>&1 (i only forward this from the IT section, but its the standard
>>> ffmpeg lufs measurment as far as i know)
>>>
>>> yes, we dont know if the customer values are correct. The problem is, there is no correct if you dont use the same method/algo.
>>> There are different meters coming up with different values on LUFSs, specially if you are under 0,4s.
>>> You are right, the best would be to use the same method, but our customer wont share their method and we cant reverse engineer something we dont own.
>>>
>>> Yes, there ist the (m) value in the output, but i think its not very
>>> reliable ... as the file measured isnt silent 😊
>>
>> I would think M is not relevant, as it should equal I if the file is 400 Msecs… And I can reproduce the issue on a short file. But, if I cat the file with silence before / after, then measure with adding -ss yadda -t sourcedur it seems to work.
>> (But a looped input results the same values when scanned fully.)
>>
>>
>>
>> Bouke.
>>
>>
>>>
>>>
>>>
>>> -----Ursprüngliche Nachricht-----
>>> Von: ffmpeg-user <[hidden email]> Im Auftrag von
>>> Bouke
>>> Gesendet: Montag, 14. September 2020 13:41
>>> An: FFmpeg user questions <[hidden email]>
>>> Betreff: Re: [FFmpeg-user] LUFS measurment for short length audio
>>>
>>>
>>>> On 14 Sep 2020, at 13:23, [hidden email] wrote:
>>>>
>>>>
>>>> To cat means to loop the file until it is longer then 0,4s?
>>>
>>> yes
>>>
>>>>
>>>> Yes we tried, there is a variation of 3db or more, so it is kind of suboptimal.
>>>
>>> If it’s exact 3db, it smells like you might render the file to mono on catting, are you sure that’s not the case?
>>>
>>>> We also know the loudnorm command.
>>>
>>> Why, if you want to conform to R128 specs, you analyse, get the I
>>> value, and lower / up the volume by the measured Integrated minus
>>> target Integrated (in Db, one LU is equal to one dB)
>>>>
>>>> We use this command atm to read out values:
>>>>
>>>> ffmpeg -nostats -i 'filename' -filter_complex ebur128 -f null
>>>
>>> This might or might not work, if it’s 5.1, you would need to omit the LFE channel, and if there are multiple tracks you would need to patch the correct ones first.
>>> So, full command line / output missing :-) (I would never think I
>>> would write this…)
>>>
>>>> and it is fine with all files >0,4s. As it should be relating to the ebu128 definition.
>>>>
>>>> Anyway, our customer provides us with lufs values for shorter lenghts and he wont tell us how he analyses it.
>>>
>>> So you have no clue if your client measurements are correct? I would not accept this, you would need to reverse engineer your clients steps...
>>>
>>>>
>>>> Now we tried to read out momentary lufs, as it works with 400ms windows, but im not sure if i get correct values here.
>>>> As it shows -120db mLUFS for an example and on proTools it says
>>>> -23--24db (with DPMeterXP2)
>>>
>>> -120 is silence…
>>>
>>>>
>>>> Anybody an idea how to read out reliable momentary LUFS values with ffmpeg?
>>>
>>> Not sure how reliable it is, but it’s just in the output I would
>>> think…
>>>
>>> Bouke
>>>
>>>
>>>>
>>>> -----Ursprüngliche Nachricht-----
>>>> Von: ffmpeg-user <[hidden email]> Im Auftrag von
>>>> Gyan Doshi
>>>> Gesendet: Montag, 14. September 2020 09:50
>>>> An: [hidden email]
>>>> Betreff: Re: [FFmpeg-user] LUFS measurment for short length audio
>>>>
>>>>
>>>>
>>>> On 14-09-2020 01:15 pm, Bouke wrote:
>>>>>> On 09 Sep 2020, at 10:33, [hidden email] wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> Hi list!
>>>>>>
>>>>>>
>>>>>>
>>>>>> Can somebody help to measure LUFS for audio files under 0,4 seconds???
>>>>>>
>>>>> Cat it a couple of times first?
>>>>
>>>> A few more times is required. Total duration should be  >3 seconds.
>>>>
>>>> See https://superuser.com/q/1281327/
>>>>
>>>> Gyan
>>>> _______________________________________________
>>>>
>>>
>>> _______________________________________________
>>> ffmpeg-user mailing list
>>> [hidden email]
>>> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>>>
>>> To unsubscribe, visit link above, or email [hidden email] with subject "unsubscribe".
>>>
>>> _______________________________________________
>>> ffmpeg-user mailing list
>>> [hidden email]
>>> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>>>
>>> To unsubscribe, visit link above, or email
>>> [hidden email] with subject "unsubscribe".
>>
>> _______________________________________________
>> ffmpeg-user mailing list
>> [hidden email]
>> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>>
>> To unsubscribe, visit link above, or email [hidden email] with subject "unsubscribe".
>>
>> _______________________________________________
>> ffmpeg-user mailing list
>> [hidden email]
>> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>>
>> To unsubscribe, visit link above, or email
>> [hidden email] with subject "unsubscribe".
>
> _______________________________________________
> ffmpeg-user mailing list
> [hidden email] <mailto:[hidden email]>
> https://ffmpeg.org/mailman/listinfo/ffmpeg-user <https://ffmpeg.org/mailman/listinfo/ffmpeg-user>
>
> To unsubscribe, visit link above, or email [hidden email] <mailto:[hidden email]> with subject "unsubscribe".
>
> _______________________________________________
> ffmpeg-user mailing list
> [hidden email] <mailto:[hidden email]>
> https://ffmpeg.org/mailman/listinfo/ffmpeg-user <https://ffmpeg.org/mailman/listinfo/ffmpeg-user>
>
> To unsubscribe, visit link above, or email
> [hidden email] <mailto:[hidden email]> with subject "unsubscribe".

_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: LUFS measurment for short length audio

christian.will

<> On 14 Sep 2020, at 15:56, [hidden email] wrote:

><
> <
> <
>> <On 14 Sep 2020, at 14:27, [hidden email] <mailto:[hidden email]> wrote:
> <
>> <
>> <I tried my example with adding silence before and after and i get both times -23.3db LUFS for i & m.
> <
>><> What happens when you use -ss and -t besides the silence (to crop
>>>< the silence start / end, work here…)
> <
>< How does this work? Does it crop the silence from the file or is it just for not measuring the silence parts at beginning and end??
>< Do you have a command i can try?
>
>Put in -ss <duration added silence start in secs> -t <duration added silence at end in secs> after the -i <input>

Thanks!
But im not sure if i understand it correctly.
I used the -ss for the example with the silence in the beginning before and after the -i
Before the -i i get -120 again. After the -i i get the same value as without -ss option 23.3db.
So maybe im doing it wrong or it isnt working better then without the -ss option.








Bouke

>
>
>> Which is a 1db variation to the customers value. If all files are coming with a 1db difference, that would be something we could work with.
>> So we are not precisely here, but its good enough for now.
>> I wonder how the meters are measuring it. As they dont have problmes with durations.
>> We will try ...
>
>>> 1 dB is not really a big difference I would think, and since this is not broadcast I take it, it ‘should’ not matter, as long as all input gets to the same percepted value.
>
> Yes its not much, but its mostly due to controlling issues, not to hit
> the same value. So the measurement must be somehow exact, up to +-2db
> variation to make sure the controlling is useful. When it comes to
> close-up diaologs and heavy compression, 2 - 4 db can be a lot. But
> this is the minor case mostly 😊
>
>
> What are you doing, game assets?
> 😊 yep
>
>
> Bouke
>
>>
>>
>> -----Ursprüngliche Nachricht-----
>> Von: ffmpeg-user <[hidden email]> Im Auftrag von
>> Bouke
>> Gesendet: Montag, 14. September 2020 14:08
>> An: FFmpeg user questions <[hidden email]>
>> Betreff: Re: [FFmpeg-user] LUFS measurment for short length audio
>>
>>
>>> On 14 Sep 2020, at 13:54, <[hidden email]> <[hidden email]> wrote:
>>>
>>> Its all mono we are talking about here
>>>
>>> Full command line would be
>>> ffmpeg -nostats -i '#{filename}' -filter_complex ebur128 -f null -
>>> 2>&1 (i only forward this from the IT section, but its the standard
>>> ffmpeg lufs measurment as far as i know)
>>>
>>> yes, we dont know if the customer values are correct. The problem is, there is no correct if you dont use the same method/algo.
>>> There are different meters coming up with different values on LUFSs, specially if you are under 0,4s.
>>> You are right, the best would be to use the same method, but our customer wont share their method and we cant reverse engineer something we dont own.
>>>
>>> Yes, there ist the (m) value in the output, but i think its not very
>>> reliable ... as the file measured isnt silent 😊
>>
>> I would think M is not relevant, as it should equal I if the file is 400 Msecs… And I can reproduce the issue on a short file. But, if I cat the file with silence before / after, then measure with adding -ss yadda -t sourcedur it seems to work.
>> (But a looped input results the same values when scanned fully.)
>>
>>
>>
>> Bouke.
>>
>>
>>>
>>>
>>>
>>> -----Ursprüngliche Nachricht-----
>>> Von: ffmpeg-user <[hidden email]> Im Auftrag von
>>> Bouke
>>> Gesendet: Montag, 14. September 2020 13:41
>>> An: FFmpeg user questions <[hidden email]>
>>> Betreff: Re: [FFmpeg-user] LUFS measurment for short length audio
>>>
>>>
>>>> On 14 Sep 2020, at 13:23, [hidden email] wrote:
>>>>
>>>>
>>>> To cat means to loop the file until it is longer then 0,4s?
>>>
>>> yes
>>>
>>>>
>>>> Yes we tried, there is a variation of 3db or more, so it is kind of suboptimal.
>>>
>>> If it’s exact 3db, it smells like you might render the file to mono on catting, are you sure that’s not the case?
>>>
>>>> We also know the loudnorm command.
>>>
>>> Why, if you want to conform to R128 specs, you analyse, get the I
>>> value, and lower / up the volume by the measured Integrated minus
>>> target Integrated (in Db, one LU is equal to one dB)
>>>>
>>>> We use this command atm to read out values:
>>>>
>>>> ffmpeg -nostats -i 'filename' -filter_complex ebur128 -f null
>>>
>>> This might or might not work, if it’s 5.1, you would need to omit the LFE channel, and if there are multiple tracks you would need to patch the correct ones first.
>>> So, full command line / output missing :-) (I would never think I
>>> would write this…)
>>>
>>>> and it is fine with all files >0,4s. As it should be relating to the ebu128 definition.
>>>>
>>>> Anyway, our customer provides us with lufs values for shorter lenghts and he wont tell us how he analyses it.
>>>
>>> So you have no clue if your client measurements are correct? I would not accept this, you would need to reverse engineer your clients steps...
>>>
>>>>
>>>> Now we tried to read out momentary lufs, as it works with 400ms windows, but im not sure if i get correct values here.
>>>> As it shows -120db mLUFS for an example and on proTools it says
>>>> -23--24db (with DPMeterXP2)
>>>
>>> -120 is silence…
>>>
>>>>
>>>> Anybody an idea how to read out reliable momentary LUFS values with ffmpeg?
>>>
>>> Not sure how reliable it is, but it’s just in the output I would
>>> think…
>>>
>>> Bouke
>>>
>>>
>>>>
>>>> -----Ursprüngliche Nachricht-----
>>>> Von: ffmpeg-user <[hidden email]> Im Auftrag von
>>>> Gyan Doshi
>>>> Gesendet: Montag, 14. September 2020 09:50
>>>> An: [hidden email]
>>>> Betreff: Re: [FFmpeg-user] LUFS measurment for short length audio
>>>>
>>>>
>>>>
>>>> On 14-09-2020 01:15 pm, Bouke wrote:
>>>>>> On 09 Sep 2020, at 10:33, [hidden email] wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> Hi list!
>>>>>>
>>>>>>
>>>>>>
>>>>>> Can somebody help to measure LUFS for audio files under 0,4 seconds???
>>>>>>
>>>>> Cat it a couple of times first?
>>>>
>>>> A few more times is required. Total duration should be  >3 seconds.
>>>>
>>>> See https://superuser.com/q/1281327/
>>>>
>>>> Gyan
>>>> _______________________________________________
>>>>
>>>
>>> _______________________________________________
>>> ffmpeg-user mailing list
>>> [hidden email]
>>> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>>>
>>> To unsubscribe, visit link above, or email [hidden email] with subject "unsubscribe".
>>>
>>> _______________________________________________
>>> ffmpeg-user mailing list
>>> [hidden email]
>>> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>>>
>>> To unsubscribe, visit link above, or email
>>> [hidden email] with subject "unsubscribe".
>>
>> _______________________________________________
>> ffmpeg-user mailing list
>> [hidden email]
>> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>>
>> To unsubscribe, visit link above, or email [hidden email] with subject "unsubscribe".
>>
>> _______________________________________________
>> ffmpeg-user mailing list
>> [hidden email]
>> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>>
>> To unsubscribe, visit link above, or email
>> [hidden email] with subject "unsubscribe".
>
> _______________________________________________
> ffmpeg-user mailing list
> [hidden email] <mailto:[hidden email]>
> https://ffmpeg.org/mailman/listinfo/ffmpeg-user 
> <https://ffmpeg.org/mailman/listinfo/ffmpeg-user>
>
> To unsubscribe, visit link above, or email [hidden email] <mailto:[hidden email]> with subject "unsubscribe".
>
> _______________________________________________
> ffmpeg-user mailing list
> [hidden email] <mailto:[hidden email]>
> https://ffmpeg.org/mailman/listinfo/ffmpeg-user 
> <https://ffmpeg.org/mailman/listinfo/ffmpeg-user>
>
> To unsubscribe, visit link above, or email
> [hidden email] <mailto:[hidden email]> with subject "unsubscribe".

_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email [hidden email] with subject "unsubscribe".

_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: LUFS measurment for short length audio

Bouke-3

> On 15 Sep 2020, at 11:41, <[hidden email]> <[hidden email]> wrote:
>
>
> <> On 14 Sep 2020, at 15:56, [hidden email] <mailto:[hidden email]> wrote:
>> <
>> <
>> <
>>> <On 14 Sep 2020, at 14:27, [hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>> wrote:
>> <
>>> <
>>> <I tried my example with adding silence before and after and i get both times -23.3db LUFS for i & m.
>> <
>>> <> What happens when you use -ss and -t besides the silence (to crop
>>>> < the silence start / end, work here…)
>> <
>> < How does this work? Does it crop the silence from the file or is it just for not measuring the silence parts at beginning and end??
>> < Do you have a command i can try?
>>
>> Put in -ss <duration added silence start in secs> -t <duration added silence at end in secs> after the -i <input>
>
> Thanks!
> But im not sure if i understand it correctly.
> I used the -ss for the example with the silence in the beginning before and after the -i
> Before the -i i get -120 again. After the -i i get the same value as without -ss option 23.3db.
> So maybe im doing it wrong or it isnt working better then without the -ss option.
>


No clue how the -ss before or after will affect the R128 filter, but after -i <input> should work.

BUT, I think this is a pointless exercise if you do game assets.
The R128 standard was invented for entire shows, so in your case, the overall loudness of the final mix in the game.
A normal show consists of loud and silence parts. A game asset can be a gunshot far away, thus intended to be soft.
And hard to measure, as the echo will be soft / under the threshold of the filter.

I would normalise all files and be afraid of (true) peaks. I would think the game designers have a routine to dynamically set the volume of each asset based on conditions in the game.

Sorry, nothing more I can help you with.

Bouke


>>
>>
>>> Which is a 1db variation to the customers value. If all files are coming with a 1db difference, that would be something we could work with.
>>> So we are not precisely here, but its good enough for now.
>>> I wonder how the meters are measuring it. As they dont have problmes with durations.
>>> We will try ...
>>
>>>> 1 dB is not really a big difference I would think, and since this is not broadcast I take it, it ‘should’ not matter, as long as all input gets to the same percepted value.
>>
>> Yes its not much, but its mostly due to controlling issues, not to hit
>> the same value. So the measurement must be somehow exact, up to +-2db
>> variation to make sure the controlling is useful. When it comes to
>> close-up diaologs and heavy compression, 2 - 4 db can be a lot. But
>> this is the minor case mostly 😊
>>
>>
>> What are you doing, game assets?
>> 😊 yep
>>
>>
>> Bouke
>>
>>>
>>>
>>> -----Ursprüngliche Nachricht-----
>>> Von: ffmpeg-user <[hidden email]> Im Auftrag von
>>> Bouke
>>> Gesendet: Montag, 14. September 2020 14:08
>>> An: FFmpeg user questions <[hidden email]>
>>> Betreff: Re: [FFmpeg-user] LUFS measurment for short length audio
>>>
>>>
>>>> On 14 Sep 2020, at 13:54, <[hidden email]> <[hidden email]> wrote:
>>>>
>>>> Its all mono we are talking about here
>>>>
>>>> Full command line would be
>>>> ffmpeg -nostats -i '#{filename}' -filter_complex ebur128 -f null -
>>>> 2>&1 (i only forward this from the IT section, but its the standard
>>>> ffmpeg lufs measurment as far as i know)
>>>>
>>>> yes, we dont know if the customer values are correct. The problem is, there is no correct if you dont use the same method/algo.
>>>> There are different meters coming up with different values on LUFSs, specially if you are under 0,4s.
>>>> You are right, the best would be to use the same method, but our customer wont share their method and we cant reverse engineer something we dont own.
>>>>
>>>> Yes, there ist the (m) value in the output, but i think its not very
>>>> reliable ... as the file measured isnt silent 😊
>>>
>>> I would think M is not relevant, as it should equal I if the file is 400 Msecs… And I can reproduce the issue on a short file. But, if I cat the file with silence before / after, then measure with adding -ss yadda -t sourcedur it seems to work.
>>> (But a looped input results the same values when scanned fully.)
>>>
>>>
>>>
>>> Bouke.
>>>
>>>
>>>>
>>>>
>>>>
>>>> -----Ursprüngliche Nachricht-----
>>>> Von: ffmpeg-user <[hidden email]> Im Auftrag von
>>>> Bouke
>>>> Gesendet: Montag, 14. September 2020 13:41
>>>> An: FFmpeg user questions <[hidden email]>
>>>> Betreff: Re: [FFmpeg-user] LUFS measurment for short length audio
>>>>
>>>>
>>>>> On 14 Sep 2020, at 13:23, [hidden email] wrote:
>>>>>
>>>>>
>>>>> To cat means to loop the file until it is longer then 0,4s?
>>>>
>>>> yes
>>>>
>>>>>
>>>>> Yes we tried, there is a variation of 3db or more, so it is kind of suboptimal.
>>>>
>>>> If it’s exact 3db, it smells like you might render the file to mono on catting, are you sure that’s not the case?
>>>>
>>>>> We also know the loudnorm command.
>>>>
>>>> Why, if you want to conform to R128 specs, you analyse, get the I
>>>> value, and lower / up the volume by the measured Integrated minus
>>>> target Integrated (in Db, one LU is equal to one dB)
>>>>>
>>>>> We use this command atm to read out values:
>>>>>
>>>>> ffmpeg -nostats -i 'filename' -filter_complex ebur128 -f null
>>>>
>>>> This might or might not work, if it’s 5.1, you would need to omit the LFE channel, and if there are multiple tracks you would need to patch the correct ones first.
>>>> So, full command line / output missing :-) (I would never think I
>>>> would write this…)
>>>>
>>>>> and it is fine with all files >0,4s. As it should be relating to the ebu128 definition.
>>>>>
>>>>> Anyway, our customer provides us with lufs values for shorter lenghts and he wont tell us how he analyses it.
>>>>
>>>> So you have no clue if your client measurements are correct? I would not accept this, you would need to reverse engineer your clients steps...
>>>>
>>>>>
>>>>> Now we tried to read out momentary lufs, as it works with 400ms windows, but im not sure if i get correct values here.
>>>>> As it shows -120db mLUFS for an example and on proTools it says
>>>>> -23--24db (with DPMeterXP2)
>>>>
>>>> -120 is silence…
>>>>
>>>>>
>>>>> Anybody an idea how to read out reliable momentary LUFS values with ffmpeg?
>>>>
>>>> Not sure how reliable it is, but it’s just in the output I would
>>>> think…
>>>>
>>>> Bouke
>>>>
>>>>
>>>>>
>>>>> -----Ursprüngliche Nachricht-----
>>>>> Von: ffmpeg-user <[hidden email]> Im Auftrag von
>>>>> Gyan Doshi
>>>>> Gesendet: Montag, 14. September 2020 09:50
>>>>> An: [hidden email]
>>>>> Betreff: Re: [FFmpeg-user] LUFS measurment for short length audio
>>>>>
>>>>>
>>>>>
>>>>> On 14-09-2020 01:15 pm, Bouke wrote:
>>>>>>> On 09 Sep 2020, at 10:33, [hidden email] wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Hi list!
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Can somebody help to measure LUFS for audio files under 0,4 seconds???
>>>>>>>
>>>>>> Cat it a couple of times first?
>>>>>
>>>>> A few more times is required. Total duration should be  >3 seconds.
>>>>>
>>>>> See https://superuser.com/q/1281327/
>>>>>
>>>>> Gyan
>>>>> _______________________________________________
>>>>>
>>>>
>>>> _______________________________________________
>>>> ffmpeg-user mailing list
>>>> [hidden email]
>>>> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>>>>
>>>> To unsubscribe, visit link above, or email [hidden email] with subject "unsubscribe".
>>>>
>>>> _______________________________________________
>>>> ffmpeg-user mailing list
>>>> [hidden email]
>>>> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>>>>
>>>> To unsubscribe, visit link above, or email
>>>> [hidden email] with subject "unsubscribe".
>>>
>>> _______________________________________________
>>> ffmpeg-user mailing list
>>> [hidden email]
>>> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>>>
>>> To unsubscribe, visit link above, or email [hidden email] with subject "unsubscribe".
>>>
>>> _______________________________________________
>>> ffmpeg-user mailing list
>>> [hidden email]
>>> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>>>
>>> To unsubscribe, visit link above, or email
>>> [hidden email] with subject "unsubscribe".
>>
>> _______________________________________________
>> ffmpeg-user mailing list
>> [hidden email] <mailto:[hidden email]>
>> https://ffmpeg.org/mailman/listinfo/ffmpeg-user 
>> <https://ffmpeg.org/mailman/listinfo/ffmpeg-user>
>>
>> To unsubscribe, visit link above, or email [hidden email] <mailto:[hidden email]> with subject "unsubscribe".
>>
>> _______________________________________________
>> ffmpeg-user mailing list
>> [hidden email] <mailto:[hidden email]>
>> https://ffmpeg.org/mailman/listinfo/ffmpeg-user 
>> <https://ffmpeg.org/mailman/listinfo/ffmpeg-user>
>>
>> To unsubscribe, visit link above, or email
>> [hidden email] <mailto:[hidden email]> with subject "unsubscribe".
>
> _______________________________________________
> ffmpeg-user mailing list
> [hidden email]
> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email [hidden email] with subject "unsubscribe".
>
> _______________________________________________
> ffmpeg-user mailing list
> [hidden email] <mailto:[hidden email]>
> https://ffmpeg.org/mailman/listinfo/ffmpeg-user <https://ffmpeg.org/mailman/listinfo/ffmpeg-user>
>
> To unsubscribe, visit link above, or email
> [hidden email] <mailto:[hidden email]> with subject "unsubscribe".

_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: LUFS measurment for short length audio

christian.will


-----Ursprüngliche Nachricht-----
Von: ffmpeg-user <[hidden email]> Im Auftrag von Bouke
Gesendet: Dienstag, 15. September 2020 12:05
An: FFmpeg user questions <[hidden email]>
Betreff: Re: [FFmpeg-user] LUFS measurment for short length audio


> On 15 Sep 2020, at 11:41, <[hidden email]> <[hidden email]> wrote:
>
>
> <> On 14 Sep 2020, at 15:56, [hidden email] <mailto:[hidden email]> wrote:
>> <
>> <
>> <
>>> <On 14 Sep 2020, at 14:27, [hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>> wrote:
>> <
>>> <
>>> <I tried my example with adding silence before and after and i get both times -23.3db LUFS for i & m.
>> <
>>> <> What happens when you use -ss and -t besides the silence (to crop
>>>> < the silence start / end, work here…)
>> <
>> < How does this work? Does it crop the silence from the file or is it just for not measuring the silence parts at beginning and end??
>> < Do you have a command i can try?
>>
>> Put in -ss <duration added silence start in secs> -t <duration added
>> silence at end in secs> after the -i <input>
>
> Thanks!
> But im not sure if i understand it correctly.
> I used the -ss for the example with the silence in the beginning
> before and after the -i Before the -i i get -120 again. After the -i i get the same value as without -ss option 23.3db.
> So maybe im doing it wrong or it isnt working better then without the -ss option.
>
>
>
>No clue how the -ss before or after will affect the R128 filter, but after -i <input> should work.
>
>BUT, I think this is a pointless exercise if you do game assets.
>The R128 standard was invented for entire shows, so in your case, the overall loudness of the final mix in the game.
>A normal show consists of loud and silence parts. A game asset can be a gunshot far away, thus intended to be soft.
>And hard to measure, as the echo will be soft / under the threshold of the filter.
>
>I would normalise all files and be afraid of (true) peaks. I would think the game designers have a routine to dynamically set the volume of each asset based on conditions in the game.
>
>Sorry, nothing more I can help you with.
>
>Bouke


Thanks!
Well its not about the original mix, its about controlling and comparing single takes and the dialog if .... but ... dont worry. Thanks!



>>
>>
>>> Which is a 1db variation to the customers value. If all files are coming with a 1db difference, that would be something we could work with.
>>> So we are not precisely here, but its good enough for now.
>>> I wonder how the meters are measuring it. As they dont have problmes with durations.
>>> We will try ...
>>
>>>> 1 dB is not really a big difference I would think, and since this is not broadcast I take it, it ‘should’ not matter, as long as all input gets to the same percepted value.
>>
>> Yes its not much, but its mostly due to controlling issues, not to
>> hit the same value. So the measurement must be somehow exact, up to
>> +-2db variation to make sure the controlling is useful. When it comes
>> to close-up diaologs and heavy compression, 2 - 4 db can be a lot.
>> But this is the minor case mostly 😊
>>
>>
>> What are you doing, game assets?
>> 😊 yep
>>
>>
>> Bouke
>>
>>>
>>>
>>> -----Ursprüngliche Nachricht-----
>>> Von: ffmpeg-user <[hidden email]> Im Auftrag von
>>> Bouke
>>> Gesendet: Montag, 14. September 2020 14:08
>>> An: FFmpeg user questions <[hidden email]>
>>> Betreff: Re: [FFmpeg-user] LUFS measurment for short length audio
>>>
>>>
>>>> On 14 Sep 2020, at 13:54, <[hidden email]> <[hidden email]> wrote:
>>>>
>>>> Its all mono we are talking about here
>>>>
>>>> Full command line would be
>>>> ffmpeg -nostats -i '#{filename}' -filter_complex ebur128 -f null -
>>>> 2>&1 (i only forward this from the IT section, but its the standard
>>>> ffmpeg lufs measurment as far as i know)
>>>>
>>>> yes, we dont know if the customer values are correct. The problem is, there is no correct if you dont use the same method/algo.
>>>> There are different meters coming up with different values on LUFSs, specially if you are under 0,4s.
>>>> You are right, the best would be to use the same method, but our customer wont share their method and we cant reverse engineer something we dont own.
>>>>
>>>> Yes, there ist the (m) value in the output, but i think its not
>>>> very reliable ... as the file measured isnt silent 😊
>>>
>>> I would think M is not relevant, as it should equal I if the file is 400 Msecs… And I can reproduce the issue on a short file. But, if I cat the file with silence before / after, then measure with adding -ss yadda -t sourcedur it seems to work.
>>> (But a looped input results the same values when scanned fully.)
>>>
>>>
>>>
>>> Bouke.
>>>
>>>
>>>>
>>>>
>>>>
>>>> -----Ursprüngliche Nachricht-----
>>>> Von: ffmpeg-user <[hidden email]> Im Auftrag von
>>>> Bouke
>>>> Gesendet: Montag, 14. September 2020 13:41
>>>> An: FFmpeg user questions <[hidden email]>
>>>> Betreff: Re: [FFmpeg-user] LUFS measurment for short length audio
>>>>
>>>>
>>>>> On 14 Sep 2020, at 13:23, [hidden email] wrote:
>>>>>
>>>>>
>>>>> To cat means to loop the file until it is longer then 0,4s?
>>>>
>>>> yes
>>>>
>>>>>
>>>>> Yes we tried, there is a variation of 3db or more, so it is kind of suboptimal.
>>>>
>>>> If it’s exact 3db, it smells like you might render the file to mono on catting, are you sure that’s not the case?
>>>>
>>>>> We also know the loudnorm command.
>>>>
>>>> Why, if you want to conform to R128 specs, you analyse, get the I
>>>> value, and lower / up the volume by the measured Integrated minus
>>>> target Integrated (in Db, one LU is equal to one dB)
>>>>>
>>>>> We use this command atm to read out values:
>>>>>
>>>>> ffmpeg -nostats -i 'filename' -filter_complex ebur128 -f null
>>>>
>>>> This might or might not work, if it’s 5.1, you would need to omit the LFE channel, and if there are multiple tracks you would need to patch the correct ones first.
>>>> So, full command line / output missing :-) (I would never think I
>>>> would write this…)
>>>>
>>>>> and it is fine with all files >0,4s. As it should be relating to the ebu128 definition.
>>>>>
>>>>> Anyway, our customer provides us with lufs values for shorter lenghts and he wont tell us how he analyses it.
>>>>
>>>> So you have no clue if your client measurements are correct? I would not accept this, you would need to reverse engineer your clients steps...
>>>>
>>>>>
>>>>> Now we tried to read out momentary lufs, as it works with 400ms windows, but im not sure if i get correct values here.
>>>>> As it shows -120db mLUFS for an example and on proTools it says
>>>>> -23--24db (with DPMeterXP2)
>>>>
>>>> -120 is silence…
>>>>
>>>>>
>>>>> Anybody an idea how to read out reliable momentary LUFS values with ffmpeg?
>>>>
>>>> Not sure how reliable it is, but it’s just in the output I would
>>>> think…
>>>>
>>>> Bouke
>>>>
>>>>
>>>>>
>>>>> -----Ursprüngliche Nachricht-----
>>>>> Von: ffmpeg-user <[hidden email]> Im Auftrag von
>>>>> Gyan Doshi
>>>>> Gesendet: Montag, 14. September 2020 09:50
>>>>> An: [hidden email]
>>>>> Betreff: Re: [FFmpeg-user] LUFS measurment for short length audio
>>>>>
>>>>>
>>>>>
>>>>> On 14-09-2020 01:15 pm, Bouke wrote:
>>>>>>> On 09 Sep 2020, at 10:33, [hidden email] wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Hi list!
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Can somebody help to measure LUFS for audio files under 0,4 seconds???
>>>>>>>
>>>>>> Cat it a couple of times first?
>>>>>
>>>>> A few more times is required. Total duration should be  >3 seconds.
>>>>>
>>>>> See https://superuser.com/q/1281327/
>>>>>
>>>>> Gyan
>>>>> _______________________________________________
>>>>>
>>>>
>>>> _______________________________________________
>>>> ffmpeg-user mailing list
>>>> [hidden email]
>>>> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>>>>
>>>> To unsubscribe, visit link above, or email [hidden email] with subject "unsubscribe".
>>>>
>>>> _______________________________________________
>>>> ffmpeg-user mailing list
>>>> [hidden email]
>>>> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>>>>
>>>> To unsubscribe, visit link above, or email
>>>> [hidden email] with subject "unsubscribe".
>>>
>>> _______________________________________________
>>> ffmpeg-user mailing list
>>> [hidden email]
>>> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>>>
>>> To unsubscribe, visit link above, or email [hidden email] with subject "unsubscribe".
>>>
>>> _______________________________________________
>>> ffmpeg-user mailing list
>>> [hidden email]
>>> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>>>
>>> To unsubscribe, visit link above, or email
>>> [hidden email] with subject "unsubscribe".
>>
>> _______________________________________________
>> ffmpeg-user mailing list
>> [hidden email] <mailto:[hidden email]>
>> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>> <https://ffmpeg.org/mailman/listinfo/ffmpeg-user>
>>
>> To unsubscribe, visit link above, or email [hidden email] <mailto:[hidden email]> with subject "unsubscribe".
>>
>> _______________________________________________
>> ffmpeg-user mailing list
>> [hidden email] <mailto:[hidden email]>
>> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>> <https://ffmpeg.org/mailman/listinfo/ffmpeg-user>
>>
>> To unsubscribe, visit link above, or email
>> [hidden email] <mailto:[hidden email]> with subject "unsubscribe".
>
> _______________________________________________
> ffmpeg-user mailing list
> [hidden email]
> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email [hidden email] with subject "unsubscribe".
>
> _______________________________________________
> ffmpeg-user mailing list
> [hidden email] <mailto:[hidden email]>
> https://ffmpeg.org/mailman/listinfo/ffmpeg-user 
> <https://ffmpeg.org/mailman/listinfo/ffmpeg-user>
>
> To unsubscribe, visit link above, or email
> [hidden email] <mailto:[hidden email]> with subject "unsubscribe".

_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email [hidden email] with subject "unsubscribe".

_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".