Audacity Bug Summary
••• Introduction •••
••• Keywords •••
    Audacity 3.0.3 development began 19th April 2021

Audacity Bugzilla



Bug 2178 - Mac: Export to (external program) fails with errors
Mac: Export to (external program) fails with errors
Status: CLOSED NOT-A-BUG
Product: Audacity
Classification: Unclassified
Component: Application Core
2.3.3
Per OS macOS
: P3 Repeatable
Assigned To: Default Assignee for New Bugs
:
: 1919 (view as bug list)
Depends on:
Blocks: 1302 2204
  Show dependency treegraph
 
Reported: 2019-07-27 09:35 UTC by Peter Sampson
Modified: 2020-03-27 13:03 UTC (History)
7 users (show)

See Also:
Steps To Reproduce:
1) get some audio 2) File > Export > Export Audio 3) choose (external program) 4) On Mac: observe both export commands fails with an error 5) On Windows observe: the lame export command works but the ffmpeg command fails
Release Note:
Group:Exports *On Mac in "Export to (external program)" with either the LAME or FFmpeg Commands that the dialog offers, the export fails and an error message will be shown.
First Git SHA:
Group: ---
Workaround:
None
Closed: 2020-03-27 00:00:00
petersampsonaudacity: Test‑OK‑Win+
petersampsonaudacity: Test‑OK‑Mac+


Attachments
Image of Windows external program ffmpgeg export failure (83.47 KB, image/png)
2019-07-27 09:45 UTC, Peter Sampson
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Peter Sampson 2019-07-27 09:35:40 UTC
On Mac trying to Export to (external program) with either the lame or ffmpeg Commands selected I get a pair of error messages of the form

1) overwrite issue
>"NoOverwritePromptEVV9hn" already exists do you want to replace it
>A file or folder with the same name already exists in
>the folder Documents. Replacing it will overwrite its
>current contents

2) Clicking on the Replace button yields the second error message
>ffmpeg -i, -, /Users/petersampson/Documents/test.aiff"
>
>execvp(FFmpeg, i, -, /petersampson/Documents/test.aiff) failed with error 2!

A similar message 2 appears for lame s the command with "lame" replacing "FFmpeg"

As far as I can tell this is not a regression - and certainly not a recent regression.
Comment 1 Peter Sampson 2019-07-27 09:45:58 UTC
Created attachment 842 [details]
Image  of Windows external program ffmpgeg export failure

On Windows selecting the lame Command in Export to (external program) appears to work fine.

But selecting the FFmpeg results in the attached failure dialog.

There is nothing the error message 1 in Mac in Comment #0

On Windows this also appears not to be a regression - and certainly not a recent regression.


As this occurs on Windows and Mac, assume all three platforms
Comment 2 James Crook 2019-07-28 06:55:47 UTC
I think on windows this is just an 'uninformative error message'
"Unable to find a suitable output format" means that the program name suffix was not found or was not a valid export type such as .wav or .aiff.

If I give a file name such as junk.wav, the ffmpeg export completes successfully.

I think this is best handled by documentation of the 'export to external program' feature.  That can refer to the ffmpeg command line documentation with lots of details of different flags and options.

Other possible improvements include:
- A help button on the 'Command Output' dialog.
- Massaging of the Command Output Dialog, e.g. we detect certain phrases in error messages and when seen, add our own text above.
- Change the default ffmpeg command to ffmpeg -i - "%f.wav"
- Detect a missing suffix on the file name, and if using the default ffmpeg command line either add .wav silently or prompt the user to add a suffix.

What to do needs discussion.  I'd say best demote this to P4 (it has been around for a long time without complaint), improve the documentation and if any one of the possible improvements is done, close the bug.
Comment 3 Peter Sampson 2019-07-28 07:48:08 UTC
(In reply to James Crook from comment #2)
>What to do needs discussion.  I'd say best demote this to P4 
>(it has been around for a long time without complaint)

Done.

I'll have a think about the documentation - no promises ...
Comment 4 Peter Sampson 2019-07-28 10:26:27 UTC
(In reply to Peter Sampson from comment #3)
>I'll have a think about the documentation - no promises ...

Basically this page: https://alphamanual.audacityteam.org/man/Exporting_to_an_External_Program

Needs to say in an alert div:
> 1) only half works on Windows (lame not ffmpeg)
> 2) doesn't work at all on Mac
> 3) Linux...
with an ednote to remove that, once this bug Bug #2178 is fixed


I have no idea what happens with this on Linux and no way of finding out - can somebody please advise
Comment 5 James Crook 2019-07-28 11:16:24 UTC
Believed fixed on windows.
https://github.com/audacity/audacity/commit/2b15aa28cacf9f50722b054b31291ace85945b00

Now on windows if you use ffmpeg and don't give an extension, wav will be assumed.
Comment 6 Peter Sampson 2019-07-28 12:27:20 UTC
(In reply to James Crook from comment #5)
Testing on W10 with audacity-2.3.3-alpha-305-2b15aa28cacf9f50722b054b31291ace85945b00

As James write in Comment #5
>Now on windows if you use ffmpeg and don't give an extension, 
>wav will be assumed.

and indeed this is the case.


If you use lame with no extension a file with no extension is created - but this file is playable.  You can also force an extension on lame if required.


Looks to be ok on Windows.



I cannot retest on Mac yet - and I stll have no idea what happens with this on Linux
Comment 7 Steve Daulton 2019-07-29 07:08:19 UTC
(In reply to Peter Sampson from comment #6)
When using "External Program", the entered command needs to be correct, and the chosen file name should be valid. If either of these are not correct, then I'd call that "user error".

The "External Program" option does not automatically append a file extension. I'd call that a "limitation" (rather than a "bug") and it should be documented that the user must supply an appropriate file extension when entering the file name.
(I note that the alpha manual does say this).

If either the "command" is incorrect, or the file name has no file extension, or the file name is invalid, I see errors (on Linux), which is to be expected. The error messages are not very user friendly, but I'd describe this feature as one for experts and not for novice users.

The "command" may include the file extension, in which case the file name should be entered without a file extension. 
For example, the export command:

ffmpeg -i - "%f.wav"

and file name

mytest

produces a WAV file: "mytest.wav"

I don't see a "bug" here (on Linux), but I agree that the error messages are not very user friendly.
Comment 8 Peter Sampson 2019-08-07 11:19:44 UTC
(In reply to Steve Daulton from comment #7)
Testing on Mac with 2.3.3 alpha jc005

Steve wroteI
>ffmpeg -i - "%f.wav"
>and file name
>mytest
>
>produces a WAV file: "mytest.wav"

they dom't on Mac - in both cases I still get an error "failed with error 2!"

and I still get an error with the two cammands that prepoulate that dropdown
>ffmpeg -i - "%f"
>lame - "%f"


Yes these are "expert" tools - but surely what is supplied by default with the app should just work ?
Comment 9 Peter Sampson 2019-08-29 07:52:15 UTC
Promoting this to P3 with a release note and no workaround

And I have added an advice div the the Manual: 
https://alphamanual.audacityteam.org/man/Exporting_to_an_External_Program#Format_Options
Comment 10 Peter Sampson 2019-11-16 09:12:29 UTC
Once this is fixed we can then test Bug #1302
Comment 11 Leland Lucius 2020-03-24 01:42:31 UTC
> 1) overwrite issue
> >"NoOverwritePromptEVV9hn" already exists do you want to replace it
> >A file or folder with the same name already exists in
> >the folder Documents. Replacing it will overwrite its
> >current contents
> 
A partial fix (that darn NoOverwrite...) message will contain an actual filename as of fix:

https://github.com/audacity/audacity/commit/b1226c
Comment 12 Leland Lucius 2020-03-24 01:50:05 UTC
(In reply to Peter Sampson from comment #0)

> 2) Clicking on the Replace button yields the second error message
> >ffmpeg -i, -, /Users/petersampson/Documents/test.aiff"
> >
> >execvp(FFmpeg, i, -, /petersampson/Documents/test.aiff) failed with error 2!
> 
Do you happen to remember where you got your "ffmpeg" program?  If not, can you either email it to me or throw it in a dropbox?  The version I have I built myself and have uploaded it to dropbox.  I'll email you the link.  You don't have to try it (I know you're cautious), but I'd really like to try yours or tell me where you got it.
Comment 13 Peter Sampson 2020-03-24 06:40:27 UTC
(In reply to Leland Lucius from comment #12)
>Do you happen to remember where you got your "ffmpeg" program?

Yes Leland, I got it in the normal "authorized" way from Buanzo's site - via the route of foillowing the link from the Audacity app you get when it can't find FFmpeg - or the Download button in Libraries preferences.

In Libraries prefs Audacity tells me my version of FFmpeg is

>F(55.33.100),C(55.52.102),U(52.66.100)

and on My Mac the download process automagically put it in

>/Library/Application Support/audacity/libs/FFmpeg.55.64bit.dylib
Comment 14 Leland Lucius 2020-03-24 11:05:22 UTC
I AM able to reproduce this and I know why I wasn't seeing it before.  I generally start Audacity from the command line, so it picks up my PATH and in my PATH I have the location of where the "ffmpeg" program is located, "/usr/local/bin" in my case.

But, I just tried downloading one of the Github action builds and got the same "execvp()" error you got.

So, I believe your "ffmpeg" executable isn't being found.  Do you happen to know where it is?  If so, manually add the path to the command like:

    <path to prgram>/ffmpeg -i - "%f"

Or you can "Browse" for it and then add the "-i - "%f"" bit.
Comment 15 Leland Lucius 2020-03-25 09:53:50 UTC
Peter, have you had a chance to look around on your Mac for the "ffmpeg" command?  I'm sure if you are able to find it and add full path in the export dialog, you're export would run just fine.

I think the only "real" fix for the execvp() error is to just capture it and display a more informative message.
Comment 16 Leland Lucius 2020-03-26 14:59:18 UTC
I've committed a change that will ease the pain somewhat.  This isn't the final fix as I wanted a bit of feedback.

https://github.com/audacity/audacity/commit/8ef0bf3

If the user does not specify an extension, which may be perfectly legal for the command being used, a Warning dialog will be shown asking if it they are sure.  This is a true Warning dialog with an option to disable it (and re-enable in Preferences).

In addition, the command string will be parsed, the command name extracted and searched for in the users PATH.  If it isn't found, the user is prompted.

What I'm not sure about is that second check.  Should the user be asked if it's okay to proceed with "OK" and "Cancel" buttons?  Or should it just be a true error and them an "OK" button only with a return to the Export dialog?
Comment 17 Peter Sampson 2020-03-27 08:40:23 UTC
(In reply to Leland Lucius from comment #16)
After a week of banging my head against a brick wall a- and some very patient coaching from Leland is actually closable "NOT-A-BUG".

My first mistake was to insist on trying the pair of "Commands" that are shipped with Audacity.   These work on Linux and Windows BUT they don't work on Mac.  If you read the Manual page *very* carefully it does tell you that these commands don't work on Mac (which is the original basis of this bug).

So following coaching from Master of The Dark Arts - Professor Lucius I

1) downloaded that latest FFmpeg 4.2.2 for Mac from the official ffmpeg.org site
2) unzipped that and placed it on my Mac's desktop
3) got some audio
4) File > Export >Export Audio
5) selected (external program)
6) browsed for the pathing in the export dialog (as the Manual tells you)
7) added to that  -i - "%f"   constructing a good command
8) ensured that the output file had an extension test.m4A
9) pressed Save

10) there is a residual  - a message complaining about the path (Leland knows about this - we are discussing this off-list.
11) Observe: test.m4A is exported properly to my desktop (it plays and reimports just fine)



>If the user does not specify an extension, which may be perfectly legal for 
>the command being used, a Warning dialog will be shown asking if it they are
>sure.  This is a true Warning dialog with an option to disable it 
>(and re-enable in Preferences).
I confirm this works - I forgot to add an extension at step 8 the first time I tried.



>In addition, the command string will be parsed, the command name extracted 
>and searched for in the users PATH.  If it isn't found, the user is prompted.
>
>What I'm not sure about is that second check.  Should the user be asked if 
>it's okay to proceed with "OK" and "Cancel" buttons?  Or should it just be a 
>true error and them an "OK" button only with a return to the Export dialog?
I get this message even when I have a legal absolute path - that is the residual mentioned at Step 10

I will leave this open for now to deal with the residual.
Comment 18 Peter Sampson 2020-03-27 08:44:33 UTC
Having struggled through all this I plan to make some updates to the Manual page of exporting via an external program to provide some greater clarity
https://alphamanual.audacityteam.org/man/Exporting_to_an_External_Program

For a start the intro could be a lot clearer (and ne made easier to read)/

I'm also not convinced about the title "Exporting to an External Program"
It might be better expressed as
>Exporting using an External Program

If no-one disagrees I shall be changing that with a DISPLAYTITLE
Comment 19 Leland Lucius 2020-03-27 09:00:27 UTC
(In reply to Peter Sampson from comment #18)
> I'm also not convinced about the title "Exporting to an External Program"
> It might be better expressed as
> >Exporting using an External Program
> 
I think "using" is more correct.
Comment 20 Peter Sampson 2020-03-27 10:36:11 UTC
Testing on macOs 10.15.4 with Audacity 2.4.0 6302e89

This now all works fine

1) I can expoert with an externall ffmpeg app and get a good file output
2) no more error message for a viald but absolute path
3) an invalid pathe generates a good message wher the only option is the OK to ACK


Next I shall test on W10 with an external FFmpeg app - just to be sure ...
Comment 21 Peter Sampson 2020-03-27 10:49:30 UTC
Testing on W10 with Audacity 2.4.0 6302e89

All looks good

1) can export with the built-in command for ffmpeg still

2) downloaded a 64-bit 4.2.2 ffmpeg for Windows from ffmpeg.org
I was able to export successful via an absolute path and with no error messages.

Accordingly I shall close this off.

This may have been "NOT-A-BUG" but it has helped us knock off some rough corners and improve this functionality - and helped us (me that is) observe the shortcomings in the Manual.


Many thanks go to Leland for his forbearance and patience hanging on in there with me as I struggled through these "molasses in January" ...
Comment 22 Peter Sampson 2020-03-27 13:03:28 UTC
*** Bug 1919 has been marked as a duplicate of this bug. ***