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.

[jdoering]

Please pardon the noob here; hopefully I'm keeping up with the discussion even though most of this is far outside my normal domain. I'm sure you'll all set me straight if I'm on the wrong track!

Is a two-pass approach over the input really required? While I'm sure it's a reasonable approach; from a library perspective a single pass interface seems convenient (like the common ReplayGainAnalysis C code). In googlebot's steps 1 through 6; the loudness per block is calculated implicitly during step #2 and if I'm understanding correctly only that per-block loudness is needed for all of the remaining steps.

Now in a "maximum overlap" approach as suggested by pbelkner each input sample results in a block so the block count per second is of course very high (equal to the sample rate). In this case buffering the per-block loundness in a single-pass approach sounds ridiculous compared to a two-pass algorithm.

But in the minimum 50% overlap standard laid out by Tech 3341, Annex 1; the block count per second is fixed at 5 independent of the sample rate. If I'm understanding this correctly it means that buffering the per-block loudness would "only" require 18K samples per hour (versus 172 million for near 100% overlap). If the loudness samples are stored in 64-bits that's only a little over 700 KiB an hour of buffering. While it isn't bounded; it sounds reasonable for in memory buffering this application on modern hardware (considering tyipcal PC applications at this point, not embedded devices, etc).

I looks to me like there is a good reason to stay near the 50% minimum overlap.

-Jeff