> On 15 Sep 2020, at 11:41, <christian.w...@4-real.com>
> <christian.w...@4-real.com> wrote:
>
>
> <> On 14 Sep 2020, at 15:56, christian.w...@4-real.com
> <mailto:christian.w...@4-real.com> wrote:
>> <
>> <
>> <
>>> <On 14 Sep 2020, at 14:27, christian.w...@4-real.com
>>> <mailto:christian.w...@4-real.com> <mailto:christian.w...@4-real.com
>>> <mailto:christian.w...@4-real.com>> 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 <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 <mailto:ffmpeg-user@ffmpeg.org>
>> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>> <https://ffmpeg.org/mailman/listinfo/ffmpeg-user>
>>
>> To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org
>> <mailto:ffmpeg-user-requ...@ffmpeg.org> with subject "unsubscribe".
>>
>> _______________________________________________
>> ffmpeg-user mailing list
>> ffmpeg-user@ffmpeg.org <mailto:ffmpeg-user@ffmpeg.org>
>> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>> <https://ffmpeg.org/mailman/listinfo/ffmpeg-user>
>>
>> To unsubscribe, visit link above, or email
>> ffmpeg-user-requ...@ffmpeg.org <mailto: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 <mailto:ffmpeg-user@ffmpeg.org>
> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
> <https://ffmpeg.org/mailman/listinfo/ffmpeg-user>
>
> To unsubscribe, visit link above, or email
> ffmpeg-user-requ...@ffmpeg.org <mailto: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".
