Audacity can no longer find lame

[rpspringuel (Fr. Samuel Springuel)]

I have Audacity installed via MacPorts and as of Sunday morning it was working just fine. I went to use it today, however, and it's now complaining that it cannot find LAME. I did update some MacPorts ports and installed some others on Sunday afternoon, but neither LAME nor Audacity was part of that update (based on the fact that only one version of both is installed on the system, if there's a log I can check to verify that, please let me know). As best I can tell the library its looking for is /opt/local/lib/libmp3lame.dylib, and that file is present, but when I point Audacity to it manually it can't open it. Any ideas on what might have broken things and how to fix it (I've already tried uninstalling and reinstalling the audacity port)?

PS: When can we expect an upgrade to Audacity 2.2.1? It's been out since December 6th, 2017.

[RJVB (René Bertin)]

Dependencies of Lame may have been updated which could lead to problems, but in principle those should have been signalled by port -v rev-upgrade.

The best I can suggest is
1) Look in the audacity log (Help/Diagnostics/Show log) for more information why Lame fails to load
2) Generate the support data from that same submenu, and see if that contains a clue
3) Use the Download feature for Lame and point Audacity to that library. That may help point the finger at Audacity or at Lame.

Something else you can try is

> sudo port deactivate -f audacity lame
> sudo port activate lame audacity

That should fix bitrot, ever you issue is caused by that.

Finally, sudden inexplicable errors that arise when your uptime is measured in months rather than weeks sometimes also just go away with a reboot.

I'll see if it's a lot of work to upgrade the port, if not I'll post a patch one of these days.

[rpspringuel (Fr. Samuel Springuel)]

The log only states the following:

14:40:38: Attempting to load LAME from system search paths
14:40:38: Loading LAME from libmp3lame.dylib
14:40:38: Error: dlopen(libmp3lame.dylib, 1): image not found
14:40:38: load failed
14:40:38: Attempting to load LAME from builtin path
14:40:38: Loading LAME from /Library/Application Support/audacity/libs/libmp3lame.dylib
14:40:38: Error: dlopen(/Library/Application Support/audacity/libs/libmp3lame.dylib, 1): image not found
14:40:38: load failed
14:40:38: (Maybe) ask user for library
14:41:15: Failed to locate LAME library

That seems to tell me what I already knew, but perhaps there's something I'm missing. The support information doesn't seem to add anything to this (at least I can find no mention of LAME outside of the log file).

I've tried the deactivate->activate cycle to no avail. I will reboot and (if that doesn't work) attempt to download LAME directly and point Audacity to it later. Right now I have to get on to some other stuff.

[RJVB (René Bertin)]

Replying to rpspringuel:

The log only states the following:

14:40:38: Attempting to load LAME from system search paths
14:40:38: Loading LAME from libmp3lame.dylib
14:40:38: Error: dlopen(libmp3lame.dylib, 1): image not found
14:40:38: load failed
14:40:38: Attempting to load LAME from builtin path
14:40:38: Loading LAME from /Library/Application Support/audacity/libs/libmp3lame.dylib
14:40:38: Error: dlopen(/Library/Application Support/audacity/libs/libmp3lame.dylib, 1): image not found
14:40:38: load failed

In my case it says

23:34:11: Attempting to load LAME from previously defined path
23:34:11: Loading LAME from /opt/local/lib/libmp3lame.0.dylib
23:34:11: LAME library successfully loaded

What you're seeing suggests that Audacity (all of a sudden?) started trying to load libmp3lame via the standard system library search path, which probably doesn't include /opt/local/lib. Or that /opt/local/lib somehow and all of a sudden disappeared from that search path. Either assumption is rather unlikely.

The mention of a "previously defined path" in my case indicates that I probably pointed Audacity to LAME once before. Question is of course why that feature doesn't work for you...

[kencu (Ken)]

I had to manually select the LAME library from within Audacity to have it find the MacPorts' installed version (Preferences -> Libraries -> MP3 Library -> Locate -> Browse)

then allow File type: Dynamic Libraries *dylibs

and then navigate to /opt/local/lib and select /opt/local/lib/libmp3lame.dylib

17:34:25: Attempting to load LAME from system search paths
17:34:25: Loading LAME from libmp3lame.dylib
17:34:25: Error: dlopen(libmp3lame.dylib, 1): image not found
17:34:25: load failed
17:34:25: Attempting to load LAME from builtin path
17:34:25: Loading LAME from /Library/Application Support/audacity/libs/libmp3lame.dylib
17:34:25: Error: dlopen(/Library/Application Support/audacity/libs/libmp3lame.dylib, 1): image not found
17:34:25: load failed
17:34:25: (Maybe) ask user for library
17:34:25: Failed to locate LAME library
17:36:30: Attempting to load LAME from previously defined path
17:36:30: Loading LAME from /opt/local/lib/libmp3lame.0.dylib
17:36:30: Actual LAME path /opt/local/lib/libmp3lame.0.dylib
17:36:30: LAME library successfully loaded

[rpspringuel (Fr. Samuel Springuel)]

then allow File type: Dynamic Libraries *dylibs

This step is what made things work. Without it behavior was the same as before. Looking more closely, it seems that /opt/local/lib/libmp3lame.dylib is a symlink to /opt/local/lib/libmp3lame.0.dylib which, as noted in the log @kencu posted, is what actually gets loaded (the lines are the same in my log now). So it seems that Audacity is having trouble following the symlink. Why it would have trouble now, but not before, I have no idea. Further, even though I selected /opt/local/lib/libmp3lame.dylib the library location now points specifically to /opt/local/lib/libmp3lame.0.dylib which means once it stopped forcing the filename to libmp3lame.dylib it could (and did) follow the symlink. Again, no idea why this change in behavior.

Numbers in the position of that 0 usually relate to the version number, thus allowing multiple versions to exist side-by-side (with the symlink pointing to the "default"), but LAME reports itself to be in version 3.100 so I'm not sure if that applies in this situation.

Well, at least I'm back up and running at this point.

[RJVB (René Bertin)]

Here's what I see on Linux (same Audacity build as the one in Macports, but using Ubuntu's LAME):

10:22:09: Attempting to load LAME from system search paths
10:22:09: Loading LAME from libmp3lame.so.0
10:22:09: Actual LAME path /usr/lib/x86_64-linux-gnu/libmp3lame.so.0.0.0
10:22:09: LAME library successfully loaded

As you can see, Audacity tries to use the system search path here, which could just mean it just does dlopen("libmp3lame.so") although that would not typically return the actual filename from which the library is loaded. Regardless, LAME is a true shared library and thus has a version number in its library filename.

Audacity does nothing but resolve the symlink. Without having looked at the code I am betting that having to do the "Allow file type" step is NOT because of the version number which also exists on Linux (and actually changes the file extension aka type there). I'm also betting that it only shows the actual file used for support/debugging reasons. Where do you find that "allow filetype" option, btw? I wasn't aware of it (or completely forgot about it); I could look into setting the option by default for the next release.

which means once it stopped forcing the filename to libmp3lame.dylib it could (and did) follow the symlink.

No offense, but that makes as little sense as suddenly no longer doing something. Theoretically it makes no sense at all because you have to do some very specific gritty work to distinguish a symlink from its destination. There is no reason for Audacity to do that here (on the contrary) so why would an installed build all of a sudden start doing that?

[kencu (Ken)]

given that this issue is described in the port notes, along with the basic fix, perhaps I can close off this ticket for you, RJVB?

[RJVB (René Bertin)]

Yes, please do.

[rpspringuel (Fr. Samuel Springuel)]

No offense, but that makes as little sense as suddenly no longer doing something. Theoretically it makes no sense at all because you have to do some very specific gritty work to distinguish a symlink from its destination. There is no reason for Audacity to do that here (on the contrary) so why would an installed build all of a sudden start doing that?

I have no idea why, I'm just trying to state what is happening, not explain it. If I had any clue as to why I would have proposed a fix.

And the option described is at the bottom of the file selection dialog. Click on the "Options" button to expose it.

[RJVB (René Bertin)]

Of course, that was me reasoning aloud.

I probably didn't notice the "Options" button at all on the file selection dialog, no wonder I couldn't find the option :-/