add EBU R128 loudness/peak value tags

[robUx4]

It seems for the ITU_BS_1770_LUFS we can just tell to normalize to -23, and for other sources the values should be shifted ? cc @bb010g

[robUx4]

We could use a big-endian float storage as we the EBML reader already has support for it. Or we could use the Q7.8 integer value as a string, as in Opus.

[bb010g]

It seems for the ITU_BS_1770_LUFS we can just tell to normalize to -23, and for other sources the values should be shifted ? cc @bb010g

I would explicitly recommend against normalization to -23 LUFS. If that means using a fixed-point encoding over a floating-point encoding to avoid the drop in accuracy when further from 0, then I think that's a better alternative. If a ITU_BS_1770_LU is specified in loudness units relative to -23 LUFS instead, then I'm sure that people will start encoding relative to their chosen LUFS instead of properly configuring their players to normalize to a target LUFS, like what's happened with ReplayGain tags. Using LUFS won't ensure that non-compliant metadata will never happen, but it will hopefully reduce the number of cases because people will realize that they're shifting an absolute value.

Avoiding confusion by implementers and authors (compared to the ReplayGain tags that they're used to) is also why I proposed including the units in the tag titles. Any change in units would require new tags anyways, and it makes it clearer when the tags are used wrong.

[t-rapp]

I agree that storing the absolute (integrated) loudness value in LUFS sounds less error-prone, rather than a gain value relative to some reference value.

I'm open to whether the tag names should start with something like "ITU_BS_1770", or the maybe more widely known "EBU_R128". Also I have no preference regarding the value format, but using a binary float seems to be fine.

[robUx4]

I would explicitly recommend against normalization to -23 LUFS. If that means using a fixed-point encoding over a floating-point encoding to avoid the drop in accuracy when further from 0, then I think that's a better alternative.

No it's a floating point number (binary) value.

Using LUFS won't ensure that non-compliant metadata will never happen, but it will hopefully reduce the number of cases because people will realize that they're shifting an absolute value.

But if the reference is floating that means we have to also store the reference so we can match different loudness levels. In the end the source value translated means the same thing as -6 / -29 stored separately. If the playback is targetting a general loudness of -18 it's the same amplication (or compression?) to apply regardless of the original loudness. Or am I missing something ?