> On 14 Sep 2020, at 14:27, christian.w...@4-real.com 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 <ffmpeg-user-boun...@ffmpeg.org> Im Auftrag von Bouke
> Gesendet: Montag, 14. September 2020 14:08
> An: FFmpeg user questions <ffmpeg-user@ffmpeg.org>
> Betreff: Re: [FFmpeg-user] LUFS measurment for short length audio
>
>
>> On 14 Sep 2020, at 13:54, <christian.w...@4-real.com>
>> <christian.w...@4-real.com> 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 <ffmpeg-user-boun...@ffmpeg.org> Im Auftrag von Bouke
>> Gesendet: Montag, 14. September 2020 13:41
>> An: FFmpeg user questions <ffmpeg-user@ffmpeg.org>
>> Betreff: Re: [FFmpeg-user] LUFS measurment for short length audio
>>
>>
>>> On 14 Sep 2020, at 13:23, christian.w...@4-real.com 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 <ffmpeg-user-boun...@ffmpeg.org> Im Auftrag von Gyan
>>> Doshi
>>> Gesendet: Montag, 14. September 2020 09:50
>>> An: ffmpeg-user@ffmpeg.org
>>> 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, christian.w...@4-real.com 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
>> ffmpeg-user@ffmpeg.org
>> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>>
>> To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org
>> with subject "unsubscribe".
>>
>> _______________________________________________
>> ffmpeg-user mailing list
>> ffmpeg-user@ffmpeg.org
>> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>>
>> To unsubscribe, visit link above, or email
>> ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
>
> _______________________________________________
> ffmpeg-user mailing list
> ffmpeg-user@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org
> with subject "unsubscribe".
>
> _______________________________________________
> ffmpeg-user mailing list
> ffmpeg-user@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
_______________________________________________
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
