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