For gated loudness of a segment, the EBU R128 spec requires a 50% window overlap. Maybe I'm missing something obvious - but I'm not seeing any indication of overlap in the code. Am I wrong?
$ sox -n sine.wav synth 0.3999 sine$ ./r128-sndfile sine.wav global loudness: -inf LUFS$ sox -n sine.wav synth 0.4 sine$ ./r128-sndfile sine.wav 1global loudness: -3.69 LUFS$ sox -n sine.wav synth 0.5999 sine$ ./r128-sndfile sine.wav 1global loudness: -3.69 LUFS$ sox -n sine.wav synth 0.6 sine$ ./r128-sndfile sine.wav 12global loudness: -3.69 LUFS$ sox -n sine.wav synth 0.7999 sine$ ./r128-sndfile sine.wav 12global loudness: -3.69 LUFS$ sox -n sine.wav synth 0.8 sine$ ./r128-sndfile sine.wav 123global loudness: -3.69 LUFS
PS An integrated mode live meter basically doesn't do anything different than a track based I-mode calculation. It has start, stop, and reset buttons to delimit the range.
PPS You don't have to redo the whole calculation each time. The absolute gating threshold does not change and must only be compared once per block. The relative gating threshold must be updated and re-applied after every new block. You may hit a drawback of using plain ANSI C, though. C++ would allow comfortable storing of block energies of virtually infinite number in dynamically growing memory structures like vectors or lists. It's not trivial to match the latter in performance/maintainability by hand coding in plain C. But when you've come so far, I'm sure you are going to find a solution.
And in the example of a 600ms input, it should be calculating the loudness for 0-400 ms and then 200-600 ms. Because in the code it looks like it might be doing 0-400ms and then 400-600ms. But again I might just be following along wrong - the #define macros made it hard to debug and follow along
$ sox -n sine.wav synth 0.2 sine$ sox -n noise.wav synth 0.2 noise$ sox sine.wav noise.wav sine.wav noise.wav sine.wav noise.wav sine.wav noise.wav test.wav$ ./r128-sndfile test.wav 0.6544170.6544120.6544120.6544120.6544120.6544120.654412global loudness: -2.53 LUFS
Ah, right, then. Well, then it would be helpful to add modes for retrieving momentary and short-term loudness, gated. Or maybe I'll just stick to using a fork that does what I need. Because using BS.1770 for normalization instead of track or album analysis is probably beyond its design scope anyway.
It could be interesting to plot short-term and integrated loudness and see how they influence each other.
Quote from: benski on 06 February, 2011, 04:36:03 PMAnd in the example of a 600ms input, it should be calculating the loudness for 0-400 ms and then 200-600 ms. Because in the code it looks like it might be doing 0-400ms and then 400-600ms. But again I might just be following along wrong - the #define macros made it hard to debug and follow along ebur128_calc_gating_block in line 390 is always called with samplerate*2/5 (400ms) as a parameter. So it will always analyse the last 400ms for each new block. A bit difficult are lines 256-275: I must check if the last 400ms "wrap around" the circular buffer, and handle that case separately.The first block differs from the others. This is probably because the filter states must get filled.
ebur128_filter_double(st, &audio_data, 400);ebur128_filter_double(st, &audio_data, 400);ebur128_filter_double(st, &audio_data, 400);ebur128_filter_double(st, &audio_data, 400);/* etc. */
It is doing window overlap. Otherwise, the block energies from the test in post 81 would be different, and not all 0.654412.
r128-sndfile -t album foo/ (tags files in the folder "foo" as an album)r128-sndfile -t album -r bar/ (recursively tag sub-folders of "bar", each sub-folder as an album)r128-sndfile -t album foo.ogg bar.ogg baz.ogg (tag files as an album)r128-sndfile -t track foo.ogg bar.ogg baz.ogg
Hi again,I've uploaded 0.2.0:[...]
It turned out that the text output of r128-ffmpeg changed somewhat. You can see it when you pipe the output to e.g. hexdump. So in my case piping the output to bc for calculation causes a syntax error.
And a suggestion: As I said I use your software for calculation of normalization. When it turns out that an audiofile has to be made "louder" I measure the given headroom with sox - actualy another time costing scan. Maybe it would be useful if you add a switch that outputs the highest true-peak within a given file.
$ ./r128-sndfile -l -p true ~/music/bad\ loop\ -\ Luo/*.flac-12.81 LUFS, LRA: 14.16 LU, true peak: 0.99826229, /home/jan/music/bad loop - Luo/bad loop - Luo - 01 Nio.flac-11.15 LUFS, LRA: 8.26 LU, true peak: 0.99095666, /home/jan/music/bad loop - Luo/bad loop - Luo - 02 Eri Valeire.flac-10.14 LUFS, LRA: 11.79 LU, true peak: 0.99171823, /home/jan/music/bad loop - Luo/bad loop - Luo - 03 Kauniit Ihmiset.flac-11.31 LUFS, LRA: 11.75 LU, true peak: 0.92898595, /home/jan/music/bad loop - Luo/bad loop - Luo - 04 Mmin.flac-26.13 LUFS, LRA: 14.87 LU, true peak: 0.25203928, /home/jan/music/bad loop - Luo/bad loop - Luo - 05 3b Or T.flac-14.10 LUFS, LRA: 11.40 LU, true peak: 1.02603507, /home/jan/music/bad loop - Luo/bad loop - Luo - 06 Kannas Nsp.flac---------------------------------------------------------------------------------11.75 LUFS, LRA: 13.34 LU, true peak: 1.02603507
r128-sndfile --gate -8.0 *.flac: -10.52 LUFSr128-sndfile --gate -10.0 *.flac: -10.77 LUFS
And here is 0.2.2, with a single change:- added "--gate" option to specify the relative gate. The standard uses a gate of -8 dB, but will switch to -10 dB in the next revision. This option is for testing only and will be removed when the standard is updated!
Hey Raiden you are great!!! Not only are you on the cutting edge of the spec but also do it all well. FYI I've tested libebur128 with the test set provided by Qualis Audio http://www.qualisaudio.com/downloads.htmand ALL test have passed perfectly!!! (except test #2 which is ac-3 encoded 5.1 and I'm not sure if libebur128 can handle this)
This signal is Dolby Digital encoded andstimulates all channels simultaneously, includingthe LFE.
-It should be sufficient to indicate 1 decimal point in dB figures. For example, some test that should measure -23.0 LUFS according to Qualis, measure -22,97 LUFS in libebur. Of course it is the same but it just doesn't look so good And I think EBU Tech docs use 1 decimal point always.
- Please make the True Peak measurement in dBTP!!! At first I thought the measurement was wrong (0,793..) but of course this is linear for -2.0 dBTP !! Good work!!!
Could someone guide me through the steps of how to build an executable for OSX from source code? is it complicated? Does it imply modifying the code? I have XCode (mainly because of some bundled apps) but I have no idea where to start