I am currently using macOS Catalina Version 10.15, which I updated to today. Prior to that I was using Audacity version 2.1.1.0. I had the FFmpeg library before the update and was able to export audio to AMR (it was also included in the File Type dropdown whenever I’d export audio). Now it is no longer on the File Type dropdown. It does appear whenever I go to ‘Configure custom FFmpeg options’ and ‘Show All Formats’, however when I attempt to export under this I get the message “FFmpeg : ERROR - Can’t open audio codec 0x15005” and it is unable to export.
I am aware of the supported bit rates and sample rates for the format, and that it requires audio in mono. I’m not sure if there are certain considerations needed to make AMR export successfully when using the custom FFmpeg options. I have ffmpeg.55.64bit.dylib, which I updated to today. Prior to this I believe I was using ffmpeg.utils.52.64bit.dylib. AMR still plays fine on Audacity and is able to be exported into other formats. Did I miss something when updating the library or is this happening for other people?
As far as I’m aware, Audacity has never had built-in support for exporting AMR format, but on macOS, Audacity supports the Apple QuickTime API, which gives Audacity the ability to support additional formats. Unfortunately, Apple have discontinued the QuickTime API.
We know that there are several (maybe many) combinations of Format and Codec that so not worg in Custom FFmpeg Export in Audacity.
Very few are documented or logged as bugs (Opus is one of the few that is)
One day when I am really bored and have a lot of time on my hands I may try to work through the full set of of Format and Codec combinations and document those that work and those that don’t - but don’t hold your breath …
Update: There are 99 Formats available - some just have one or two suggested Codecs available - but others have many. You appear to be able to force any Codec with any Format - and there are 65 Codecs - doing the math I make that 6,435 possible combinations to test
So, do you wanna log a bug for:
a) more meaningful error message on Windows (I’ve not tested on Mac yet)
b) inconsistency in error message W10 v. Linux
c) both
The current error message is “correct”, even if a bit terse. I think that this comes up so infrequently that it’s OK as it is (though useful for us to know what the problem is, for the rare occasions that it does crop up).
From a quick look at the code, Windows is failing to export in a different place to Mac / Linux.
The code looks to see if the codec exists.
In the case of Linux / Mac, it doesn’t, hence “Support for this codec is probably not compiled in.”
The code then looks to see if the codec + options can open.
Linux / Mac don’t get this far.
The Windows version of FFmpeg does get this far because it has the codec, but it doesn’t work - the codec can’t be opened.
Hence the error “Can’t open audio codec”.
It is arguable whether this is a “bug” or “limitation”, but it looks like the “problem” is in FFmpeg rather than in Audacity itself.
I notice that there is a comment: // As of Jan 4, 2011, the default AC3 encoder only accept SAMPLE_FMT_FLT samples.
// But, currently, Audacity only supports SAMPLE_FMT_S16. So, for now, look for the
// “older” AC3 codec. this is not a proper solution, but will suffice until other
// encoders no longer support SAMPLE_FMT_S16.
My conjecture is that it is a similar limitation for the AMR codec(s), in that even though there are AMR codecs present in the Windows version of FFmpeg, Audacity does not fulfill all of the requirements of these specific codecs.
I think that the underlying problem here is that Audacity has no way of knowing whether a specific codec will work, until the user tries to use it. There are multiple ways that codecs can fail, but the reasons are mostly quite technical, so it’s difficult to give error messages that are easily understandable for users.
I think that what the developers would like to do, is to automatically detect the codecs, rather than having a hard coded list of codecs.
A hard coded list of codecs has the downside that if the user updates FFmpeg so that it supports more formats, Audacity would not be able to access those new codecs because they are not in “the list” of supported codecs.
The downside of automatically detecting the codecs, is that Audacity can’t know if the detected codecs actually work.
I think that the solution is for Audacity to ship with its own version of FFmpeg built in, but allowing users to use their own external FFmpeg if they wish.
The built-in FFmpeg would only contain “free” codecs (that comply with Audacity’s GPL license, and US patent laws) that work with Audacity.
An external FFmpeg would probably support more formats, but as now, there’s no guarantee that all codecs will work.
