compile on OSX fails on aclocal

Hi, I am trying to compile on OSX 10.14.6 and have hit snag.. clone master.. configure

jamieg$ make
CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/sh /Users/jamieg/teemmpp/leqm-nrt/missing aclocal-1.15 
/Users/jamieg/teemmpp/leqm-nrt/missing: line 81: aclocal-1.15: command not found
WARNING: 'aclocal-1.15' is missing on your system.
         You should only need it if you modified 'acinclude.m4' or
         'configure.ac' or m4 files included by 'configure.ac'.
         The 'aclocal' program is part of the GNU Automake package:
         <http://www.gnu.org/software/automake>
         It also requires GNU Autoconf, GNU m4 and Perl in order to run:
         <http://www.gnu.org/software/autoconf>
         <http://www.gnu.org/software/m4/>
         <http://www.perl.org/>
make: *** [aclocal.m4] Error 127
Jamess-MacBook-Pro:leqm-nrt jamieg$ aclocal
Jamess-MacBook-Pro:leqm-nrt jamieg$ aclocal --version
aclocal (GNU automake) 1.16.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv2+: GNU GPL version 2 or later <https://gnu.org/licenses/gpl-2.0.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

So, to get to the other wise.. I hand edited the Makefile and pointed to the version of aclocal and automake.

Then, I hit the following error.

10 warnings generated.
mv -f .deps/leqm-nrt.Tpo .deps/leqm-nrt.Po
gcc  -g -O2 -I/usr/include/ffmpeg -I/usr/include/di -Wl,--no-as-needed -lm -lpthread -lrt -lavformat -lavcodec -lavutil -L/usr/lib/di -o leqm-nrt leqm-nrt.o  -lpthread -lm -lavutil -lavformat -lavcodec 
ld: warning: directory not found for option '-L/usr/lib/di'
ld: unknown option: --no-as-needed
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [leqm-nrt] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2
Jamess-MacBook-Pro:leqm-nrt jamieg$

I am not well versed in C compilation.. /usr/lib/di directory does not exist..

Not sure har to hammer it though now.. Help appriciated. get back to me if you would like to teamviewer into my macbook to get access to this natively to chase down these bugs..

I discovered running automake before configure Probably mention this in the readme on how to compile on OSX.

fixed the aclocal issue. and now we get to the same issue....

10 warnings generated.
mv -f .deps/leqm-nrt.Tpo .deps/leqm-nrt.Po
gcc  -g -O2 -I/usr/include/di -Wl,--no-as-needed -lm -lpthread -lrt -lavformat -lavcodec -lavutil -L/usr/lib/di -o leqm-nrt leqm-nrt.o  -lpthread -lm -lavutil -lavformat -lavcodec 
ld: warning: directory not found for option '-L/usr/lib/di'
ld: unknown option: --no-as-needed
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [leqm-nrt] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2
Jamess-MacBook-Pro:leqm-nrt jamieg$

Ok, I have spent an hour or so looking for /usr/lib/di..
I just reread your other message and it mentiones "Dolby DI for speech gating"

Where do I get this please. I imagine thats whats missing.

If you want to compile just as you did before with sndfile, I would suggest to forget for now autotools and use the following from inside leqm-nrt:

gcc -g -O2 -DHAVE_LIBSNDFILE -DVERSION=\"0.20\" -lm -lpthread -lrt -lsndfile -o src/leqm-nrt src/leqm-nrt.c -lrt -lpthread -lm -lsndfile

For linking with ffmpeg if you have a version > than 4.0 and if includes are located where indicated, you should use:

gcc -g -O2 -DHAVE_LIBAVCODEC -DHAVE_LIBAVFORMAT -DHAVE_LIBAVUTIL -DVERSION=\"0.20\" -I/usr/include/ffmpeg -lm -lpthread -lrt -lavformat -lavcodec -lavutil -o src/leqm-nrt src/leqm-nrt.c -lrt -lpthread -lm -lavutil -lavformat -lavcodec

Dolby Dialogue Intelligence is proprietary code that you can obtain from dolby.com here:

https://professional.dolby.com/support/dolbys-speech-gating-reference-code/

It is free, but you have to sign an agreement.

But this is only needed if you want to experiment with speech gating. I am also trying to see if I can create an alternative with TensorFlow with CNN.

If you have installed the Dolby Library in the corresponding directories you can opt to link with sndfile or ffmpeg with the following:

gcc -g -O2 -DHAVE_LIBSNDFILE -DHAVE_LIBDI -DVERSION=\"0.20\" -I/usr/include/di -lm -lpthread -lrt -lsndfile -L/usr/lib/di -o src/leqm-nrt src/leqm-nrt.c -ldi -lrt -lpthread -lm -lsndfile

gcc -g -O2 -DHAVE_LIBAVCODEC -DHAVE_LIBAVFORMAT -DHAVE_LIBAVUTIL -DHAVE_LIBDI -DVERSION=\"0.20\" -I/usr/include/ffmpeg -I/usr/include/di -lm -lpthread -lrt -lavformat -lavcodec -lavutil -L/usr/lib/di -o src/leqm-nrt src/leqm-nrt.c -ldi -lrt -lpthread -lm -lavutil -lavformat -lavcodec

I hope you can solve with this for the moment. I need to work more to have the configure / Makefile working.

Let me know.

But if you install Dolby DI library and include (this must be done manually) in the same places as I did, it should also work if you do: autoreconf -i configure make

I am not sure about the login requirement. The site has no login page..

I logged into the Dolby Developer site. But that made no difference. "And Do Not Track" is disabled..

Where is the login page to access this? Can you send me the URL please.

PLUS, I am very interested in DI as a loudness measurement, especially in pre show ads as they revolve around dialog. I think it would be very interesting to add the DI loudness measurement.

SECOND, the compile details. I would suggest you cut and paste that detail about compiling by hand into the README.md https://bitli.pro/Nh43_800c42cf file.

Finally, I'll try compiling on my MAC and into a Alpine docker file later today and see if I can get the log out of this newer version. Though, when I manage to get the dolby lib, I will have a quick look.. Can it produce a NUMBER and a LOG as I am aiming for with leqm?

Also, I passed your question in regards to: how would you apply LKFS to Cinema sound, considering the surrounds are 3db lower...strangely nothing yet.

I'll put this question to you. So I take it, because the surround channels (82db) are 3db lower than the front channels (85db), the LKFS result value is not representative. but does this matter when we are using it more for comparative analysis over domestic expectation.

Raising the surround channels by 3db and applying the reading would be the most appropriate path?

Regards, James Gardiner [m] +61 4 12 997011

CineTechGeek Suite 129, 9 Hall Street, Port Melbourne, VIC 3207 [p] +61 3 9686 5415

www.digitall.net.au https://bitli.pro/Nh44_06bacc3f -- www.finishingroom.com.au https://bitli.pro/Nh45_afb4b073 -- www.clubmovie.com.au https://bitli.pro/Nh46_03738967 -- www.cinetechgeek.com https://bitli.pro/Nh47_1066f4da

On Fri, Jun 26, 2020 at 5:37 AM lucat notifications@github.com wrote:

But if you install Dolby DI library and include (this must be done manually) in the same places as I did, it should also work if you do: autoreconf -i configure make

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/lucat/leqm-nrt/issues/6#issuecomment-649777668, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAZGTDXORZW2IY22VNPYXVDRYORRFANCNFSM4OHQMQOQ .

Ok your instructions above. There is an issue with -lrt. library cannot be found as I imagine its the Dolby Lib. I removed it from the compile command and all was OK.. I was then able to apply leqm-nrt directly onto a DCP mxf audio essance.. And it did work.

Jamess-MacBook-Pro:leqm-nrt jamieg$ src/leqm-nrt /opt/dcinenet/storage/assetlib/by_code/3nvZQpfRdvvU7YJe9GfFVG/a/COUNTDOWN_TLR_S_EN-XX_AUNZ_51_2K_SCINT_20190910_SS_IOP_OV/COUNTDOWN_TLR_S_EN-XX_AUNZ_51_2K_SCINT_20190910_SS_IOP_OV_6aea5984-1089-44_pcm.mxf 
leqm-nrt  Copyright (C) 2011-2013, 2017-2020 Luca Trisciani
This program comes with ABSOLUTELY NO WARRANTY,
for details on command line parameters see --help
First argument is the audio file to be measured.
Other parameters can follow in free order.
This is free software, and you are welcome to redistribute it
under the GPL v3 licence.
Program will use 1 + 7 slave threads.
[mxf @ 0x7f92e4001400] "OPAtom" with 2 ECs - assuming OP1a
This stream has 6  channels and a sample rate of 48000  Hz
The data is in the format s32
Using input channel calibration for 5.1 configuration:
0 0 0 0 -3 -3
Leq(M): 83.8882
Jamess-MacBook-Pro:leqm-nrt jamieg$

See other "now closed" issue in regards of using --logleqm.

I have a question, I see the LKFS option now. And a quick 1 item sample shows the result is the same for using the ffmpeg, ebur128 filter. And as we are discussing how electonicly, due to Cinema having -3db in the surrounds. (As your 0 0 0 0 -3 -3 output from your command indicates..) does that mean your measurments of LKFS takes that into consideration?

In terms of this issue, if you add the example of how to compile it as above to the README.md, you should close this issue.

Hi James,

thank you for your feedback.

librt: librt has nothing to do with Dolby DI. It is required on linux, but apparently not on Mac.

LKFS: No, this implementation is the one for broadcast material. No account for cinema replay levels. It should give you exactly the same results like ebur128 in ffmpeg. Otherwise as I told you I would have called it something else. I added it to have some means to check the integration of speech gating, as the only documentation from Dolby pertains LKFS. So my integration is not exactly on the spot where it should be because for a reference file coming with the library I get -25.12 instead of -24 LKFS(DI). I have still to figure out where this difference is coming from. But LKFS implementation should be fine as far as I have tested.

What I did is to create another hybrid that takes cinema replay levels into account. I called it Leq(M, LG). It is the same as LKFS that is with 75% overlapping window and thresholds but with M weighting and account for replay levels. This is almost necessary to have because if you measure Leq(M, DI) that is Leq(M) with DI on something that has almost no dialogue the measurement is no more meaningful. There must be a minimal percentage of dialogue, so that the measurement with speech gating becomes meaningful. Also my version of Leq(M, DI) is strongly derived from LKFS (but sure enough with the right replay levels). But this approach has his drowbacks because M weighting greatly lowers the audio spectrum where speech appears. So I would also like to create other variants with A and maybe C weightings to experiment with.

Dolby website: I don't know anything about this login requirements. I think it could be new or something broken on there web page. I think one have to ask their administrator, I do not know how I can help with Dolby Web site. I could download an year or so ago without any problem. But I do not remember if I had to login. Maybe they changed something?

Modifying the results from ebur128 filter applying some gain preventively: Not raising but lowering by -3dB and possibly by -4.5 prior to applying a non modified LKFS algorithm as I said is what I would suggest to do for your use if you do not want to change the ffmpeg ebur128 code.

Sorry, but I do not understand the meaning of the phrase "but does this matter when we are using it more for comparative analysis over domestic expectation". Do you mean, that you are not interested in the final absolute measurements, but in comparing between measurements for different audio materials? I would say that different audio materials can result in the same integrated measurement, but this is mediated by the replay levels of the different channels, so comparing different audio materials measurement will not simply scale the results uniformly, because the different materials do not have the same signal distribution a mong the channels. So I would suggest it does matter.

Still all these measurements are a sort of simulation, they will never 100% account for what will be perceived in a cinema room. Still I find one should try to avoid all logic errors at least in theory.

Charles passed me and you an article more than one year ago by someone who has written a lot on these questions. Do you still have this email from him? It was 16th Dec 2018. I strongly suggest that you take a look at all the attachments, you will find there all the things you need... plus others...

But I think that person is now working at Fraunhofer in Germany, I do not know him personally but he would possibly have good suggestions. Do you know him?

Regards

Luca

LKFS: No, this implementation is the one for broadcast material. No account for cinema replay levels. It should give you exactly the same results like ebur128 in ffmpeg. Otherwise as I told you I would have called it something else. I added it to have some means to check the integration of speech gating, as the only documentation from Dolby pertains LKFS. So my integration is not exactly on the spot where it should be because for a reference file coming with the library I get -25.12 instead of -24 LKFS(DI). I have still to figure out where this difference is coming from. But LKFS implementation should be fine as far as I have tested.

My position on this is that, yes Cinema uses Leq(m) but every DAW (Digital Audio Workstation) software comes with LKFS. As such, many audio producers, at the end of the day, are likely using LKFS loudness to create the final mix. Its what they know and use every day for everything else. In cinema land LKFS is likely to be used for Ads and potentially all preshow content that was not mixed by a larger production facility. As it's not a common workflow for them, they are unlikely to bother with ADDING a Leqm loudness meter and setting up their speakers with historical settings.

If we do do some measurements, I want it to be relevant to the way the industry works and understands.

So right now, after sleeping on it. Even though it's wrong, a lot of producers will likely be using the wrong way so it has a form of relanence to them as they have a position of reference.

What I did is to create another hybrid that takes cinema replay levels into

account. I called it Leq(M, LG). It is the same as LKFS that is with 75% overlapping window and thresholds but with M weighting and account for replay levels. This is almost necessary to have because if you measure Leq(M, DI) that is Leq(M) with DI on something that as almost no dialogue the measurement is no more meaningful. There must be a minimal percentage of dialogue, so that the measurement with speech gating becomes meaningful. Also my version of Leq(M, DI) is strongly derived from LKFS (but sure enough with the right replay levels). But this approach has his drowbacks because M weighting greatly lowers the audio spectrum where speech appears. So I would also like to create other variants with A and maybe C weightings to experiment with.

Think of me as a jockey. I don't care what horse I ride, I just need a horse to ride. I don;t care what I use to measure, I just want to make sure it's understood, close to a recommended standard as possible so the industry will not simply take the numbers as random rubbish.

Dolby website: I don't know anything about this login requirements. I think it could be new or something broken on there web page. I think one have to ask their administrator, I do not know how I can help with Dolby Web site. I could download an year or so ago without any problem. But I do not remember if I had to login. Maybe they changed something?

Have you tried to login and download it again? Can you archive that? Just want to know if it's me.. and if it did work, how did you login to allow the download.. It's very strange as the website in question has no login page or indication of a login but the download page says you must login.. That's what I am seeing anyway. So yes, you're probably right, there may be an error in the hosting.

Modifying the results from ebur128 filter applying some gain preventively: Not raising but lowering by -3dB and possibly by -4.5 prior to applying a non modified LKFS algorithm as I said is what I would suggest to do for your use if you do not want to change the ffmpeg ebur128 code.

This would likely be the best path as I prefer to stay away from the code as then errors in that area are not on the table. However, that's only if doing this has any recognised substance by the industry.

Sorry, but I do not understand the meaning of the phrase "but does this matter when we are using it more for comparative analysis over domestic expectation". Do you mean, that you are not interested in the final absolute measurements

Yes, there is some truth to this. As the research is more about, in my mind, identifying trends where people are departing from how the standards are being used on a region by region basis. So if in the analysis we can see certain regions are tracking along the expected loudness levels for the content type by another region is not. We can then look deeper into it or potentially inform that region.. They are out of step with the rest of the world.

The problem I see and why we are doing research is.. Before digital cinema, all audio had to go through a Dolby calibrated room, and was programmed to a volume based on level 7 of a cinema processor. Now we are digital, this no longer happens.

Have we wandered away from a common target volume due to this change? Is there a problem here that may result in a region getting loudness restriction introduced into cinema? (A nightmare for exhibitors)

HOW DO WE KNOW IF SOMETHING IS WRONG if no one is looking/measuring content around the world? Even if content is being produced by respective production facilities around the world, could there be different regions applying the standards slightly differently?

The actual target loudness is important but more important is showing divergence from the mean.

, but in comparing between measurements for different audio materials? I

would say that different audio materials can result in the same integrated measurement, but this is mediated by the replay levels of the different channels, so comparing different audio materials measurement will not simply scale the results uniformly, because the different materials do not have the same signal distribution a mong the channels. So I would suggest it does matter.

I am not the expert in this area. If you consider this important, we will have to add it to the system. But I would like your opinion on how the industry does work and even if wrong, does the issue of producing a measurement they are familiar with in regards to what they do every day also meaningful?

Still all these measurements are a sort of simulation, they will never 100% account for what will be perceived in a cinema room. Still I find one should try to avoid all logic errors at least in theory.

Charles passed me and you an article more than one year ago by someone that has written a lot on these questions. Do you still have this email from him? It was 16th Dec 2018. I strongly suggest that you take a look at all the attachments, you will find there all the things you need... plus others...

But I think that person is know working at Fraunhofer in Germany, I do not know him personally but he would possibly have good suggestions. Do you know him?

He may be a reader of the ISDCF mailing list. The place to go for all the head techs on these issues.

I think I did scan it, and do remember looking something on this, but again, as its not my main focus my retention is not very strong. Python, Docker containers, postgres, Javascript and user interface frameworks. I have enough in my head..

On this, and seeing the newer features of the leqm-nrt. With the --leqmlog --buffersize 100 Adding --lkfs You could add Time leqm lkfs (space delimited values) And as you allow the channel config --chconfcal It would probably be easier to go with your tool for measuring all these values. What is your opinion on that?

James

Regards

Luca

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://bitli.pro/NkvN_ff02bd71, or unsubscribe https://bitli.pro/NkvO_fccc33f7.

Hi all, Just a note on this. Had to build this on a Mackbook pro M2 Max, used brew list libsndfile then, on configure.. CPPFLAGS="-I/opt/homebrew/Cellar/libsndfile/1.2.2/include" LDFLAGS="-L/opt/homebrew/Cellar/libsndfile/1.2.2/lib" ./configure

Then, dies on gcc -g -O2 -Wl,--no-as-needed -L/opt/homebrew/Cellar/libsndfile/1.2.2/lib -L/usr/lib -L/usr/lib/di -L/usr/local/lib -L/usr/local/lib/di -o leqm-nrt leqm-nrt.o -lsndfile -lpthread -lm with an error on --no-as-needed, so cd'ed in to the src directory and ran the command again, removing that option. AND also the include paths for the di library, which I don't have.

`gcc -g -O2 -Wl -L/opt/homebrew/Cellar/libsndfile/1.2.2/lib -L/usr/lib -L/usr/local/lib -o leqm-nrt leqm-nrt.o -lsndfile -lpthread -lm' Got an executable. installed by hand.

lucat / leqm-nrt

compile on OSX fails on aclocal #6