python-audio-tools icon indicating copy to clipboard operation
python-audio-tools copied to clipboard

Published 20 hours ago • verified publisher icon tuffy

No MP3 support in OS X 10.9

Open intuited opened this issue 10 years ago • 6 comments

I've installed lame using brew install lame --universal. I've acquired the python-audio-tools source via git, and have checked out version 2.21. Running make install after doing make distclean (and after lame installation) doesn't produce any error or warning messages. Output from make probe indicates that an mp3 library is present. However, mp3 shows up in red when I do audiotools-config.

which lame gives /usr/local/bin/lame; lame's library is at /usr/local/lib/libmp3lame.dylib.

I'm similarly unable to use other formats like ogg and mp2 despite having also installed their packages. However, they are not listed as present by make probe.

intuited avatar Jul 25 '14 16:07 intuited

Have you also installed libmpg123? Lame is needed for encoding, but mp3 and mp2 won't be available unless they have both the encoder and decoder (in this case mpg123 is used to decode both mp3 and mp2). The same is true for vorbisfile, which is needed for ogg decoding.

It should be possible to split formats into those that are "write capable" and "read capable" such that one might be able to encode mp3 with only lame but not decode it, but I haven't gotten around to that yet.

tuffy avatar Jul 26 '14 16:07 tuffy

Yep, libmpg123 was also installed via brew install mpg123 before compilation. It's located at /usr/local/lib/libmpg123.dylib.

Though actually, I'm realizing that libmpg123.dylib is not a universal binary (as per running file on it). That's possibly the issue. Is there a way to build python-audio-tools so that it is compatible with 64-bit libraries? brew doesn't provide a --universal option when installing the mpg123 package.

PS I noticed an error message when building python-audio-tools earlier when I had the non- --universal version of lame installed, but I don't get that message currently at all.

intuited avatar Jul 27 '14 17:07 intuited

Tried building on an ubuntu VM. It looks like the problem is definitely that 32-bit libraries are needed.

Steps:

  • installed libmpg123-dev, libmp3lame-dev (the non-dev packages were already installed)
  • cloned the git archive
  • created a new branch at tag v.2.21, checked it out
  • ran sudo make install
  • at this point audiotools-config showed mp3 in red.
  • installed libmpg123-dev:i386 and libmp3lame-dev:i386
  • ran sudo make clean; sudo make distclean; sudo make install
  • now audiotools-config shows mp3 in green.

VM OS is an updated Ubuntu 14.04.1 LTS.

There were no error or warning messages displayed during the build either time.

intuited avatar Jul 31 '14 20:07 intuited

That would explain why I hadn't been able to duplicate the problem under OS X. I've been compiling mpg123 from source with XCode which generates 32-bit and 64-bit dylib files for libmpg133 and the linker had been skipping the 32-bit one. I'll have to see if there's some way to get distutils to detect that condition and put up an appropriate warning at build-time.

tuffy avatar Aug 01 '14 00:08 tuffy

I'm still confused as to why I can't continue with just a 64-bit libmpg123.dylib. I've verified that python is running as 64-bit; why does it need a 32-bit library to link to? Does this mean that I'll have to build libmpg123.dylib from source, as well as the various other libraries for other formats? Is it normal for this to happen under linux also? I don't recall having this problem with my old 64-bit linux machine.

intuited avatar Aug 01 '14 23:08 intuited

Still wondering what I should do to get this running. I tried compiling mpg123 myself but there were errors in the compilation that I don't have time to look at.

intuited avatar Aug 26 '14 18:08 intuited