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 <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".
