R128GAIN: An EBU R128 compliant loudness scanner Options

[pbelkner]

I've just uploaded on sourceforge a first version of r128gain, an EBU R128 (http://tech.ebu.ch/loudness) compliant loudness scanner:

http://sourceforge.net/projects/r128gain/files/

• process single files (tracks):
  
  • In order to just scan and analyze one file (WAV, FLAC or WV):
    
    CODE
    r128gain <file>
  • In order to scan, analyze and tag one file (currently only FLAC, result will be in <directory>):
    
    CODE
    r128gain <file> <directory>
  • In order to scan, analyze one file (WAV, WV) and encode and tag into FLAC (result will be in <directory>):
    
    CODE
    r128gain <file> <directory> flac
• recursively process directories (the content of a directory is considered an album):
  
  • In order to just recursively scan and analyze a directory:
    
    CODE
    r128gain <directory>
  • In order to recursively scan, analyze and tag a directory:
    
    CODE
    r128gain <directory> <directory>
    r128gain <directory>/* <directory>
  • In order to recursively scan, analyze a directory and encode and tag into FLAC:
    
    CODE
    r128gain <directory> <directory> flac
    r128gain <directory>/* <directory> flac

Tagging is currently supported only for FLAC:

• REPLAYGAIN_REFERENCE_LOUDNESS: always -23 LUFS (corresponding to EBU R128)
• REPLAYGAIN_TRACK_GAIN: loudness difference to -23 LUFS in LU measured for this track
• REPLAYGAIN_TRACK_PEAK: true peak measured at 192 kHz for this track
• REPLAYGAIN_ALBUM_GAIN: loudness difference to -23 LUFS in LU measured for the whole album
• REPLAYGAIN_ALBUM_PEAK: true peak measured at 192 kHz for the whole album

These tags should be honored by each Replay Gain compliant media player.

[googlebot]

I think you both have a valid point.

I also think that it is not very probable, that just because there is a tool now and some forum people decide to agree on a R128 tagging format, that there will be only a fraction of RG's device and player support anytime soon. It was different, when David started, because it filled a gap at its time, for which there were no solutions.

Until RG evolves into something allowing versioning, it can take ages. It might even never happen, since ID3 is such a mess. (The world of tagging could be such a better place without mp3.)

=> For an user with complete control over his own music library, it could be an attractive hack to rescan his library and write R128 estimated, but RG compatible, tags to his music collection. He would then have the benefits of both worlds, probably better loudness estimation due to gating, and instant playback support for most available hardware. RG enabled players don't really care what RG means or how the values were calculated. They just apply gain and prevent clipping.

Jdoering's approach to just use ref_pink.wav to get a relative offset between both approaches is very reasonable.

PS An additional tag could indicate, that the values are R128 based. A user could then choose to rescan all tracks, which do not have that, yet.

This post has been edited by googlebot: Jan 12 2011, 13:17

[pbelkner]

=> For an user with complete control over his own music library, it could be an attractive hack to rescan his library and write R128 estimated, but RG compatible, tags to his music collection. He would then have the benefit of both worlds, probably better loudness estimation due to gating, and instant playback support for most available hardware. RG enabled players don't really care what RG means or how the values were calculated. They just apply gain and prevent clipping.

That's exactly what I've tried to say. With R128GAIN you can do this just out of the box.

Jdoering's approach to just use ref_pink.wav to get a relative offset between both approaches is very reasonable.

I agree.

[2Bdecided]

Jdoering's approach to just use ref_pink.wav to get a relative offset between both approaches is very reasonable.

I agree.

That is exactly how it's supposed to work.

You can argue for or against the inclusion of an additional or different correction factor. It could be based on calculations from a large sample set, or from some theoretical presumption that one or other calculation is predictably and quantifiabley "wrong" with pink noise vs almost everything else. The latter might be justifiable, but the former wrecks the idea of having a real reference level.

If you're comparing two loudness measurements, neither of which have a reference level, then you're stuck with comparing results from a large sample set. But if one or both have properly defined reference levels, then that should be unnecessary - and will only reveal inaccuracies in one or other algorithm with the chosen sample set. Presumably you want to remove such inaccuracies. Hard coding them into the conversion factor doesn't seem right.


But like I said - you could argue it either way. I think unless there's strong evidence to the contrary, the simple approach, "just use ref_pink", is the one to stick with.


I think (I've always thought!) that a version tag might be useful.
I think existing tags must keep their existing meanings.
Using a new calculation method with the same reference level is absolutely fine.
I think inter-sample peaks might be better in a separate tag, not in the existing peak tags. Some processing (e.g. typically that within software players) cares about the values of the actual sample data, and doesn't care at all about inter-sample overs. The player may do things differently if the real samples go above 0dB FS (e.g. introduce soft or hard limiting, or soft clipping) which may decrease quality if applied when it's only inter-sample values that go above 0dB FS. (In practice it's rare for ReplayGained audio to have significant inter-sample overs but no on-sample overs - "loud/squashed" audio like that tends to get turned down by ReplayGain to a level where there's no chance of any values above 0dB FS either on or between samples)

Cheers,
David.

[Notat]

You can argue for or against the inclusion of an additional or different correction factor. It could be based on calculations from a large sample set, or from some theoretical presumption that one or other calculation is predictably and quantifiabley "wrong" with pink noise vs almost everything else. The latter might be justifiable, but the former wrecks the idea of having a real reference level.

The statistical processing in RG and the gate in R128 introduce non-linear behaviors that are difficult or impossible to compare mathematically or by using a single reference. This motivates the empirical/statistical approach.

Here's another (longer) study that takes a statistical approach. Loudness measurement implementation variations are considered including one with gating.

This post has been edited by Notat: Jan 13 2011, 15:42