Bug when applying MP3 conversion

I had two shots at this about fifteen minutes ago. The bug is reproducible. Both reports were "SEND"ed, and I have preserved the input file.
Please let me know if you would like/need a copy.
Thanks
Chris

What’s the bug?

What are you trying to do?
Which version of Audacity?
What are the steps to reproduce the bug?
What do you expect to happen?
What actually happens?

(1) What’s the bug?

I am not quite sure. I applied an MP3 conversion macro, there was a pause of about one second, then a text-box window appeared with what I took to be intelligible stuff for Audacity and two buttons, from memory “Don’t Send” and “Send”. I saw no text that meant anything to me, for example “file corrupt” or “try again after selecting …” or similar.

(2) What are you trying to do?

I had an eighteen-second FLAC file that I wanted to convert to MP3 to send off to my client. I have run this macro many times before, I would say four hundred times since January 2022.

(3) Which version of Audacity?

As stated in my post: Win10/ Audacity 3.1.3

(4) What are the steps to reproduce the bug?

At my end:-

(a) Load the 787KB FLAC file into Audacity by executing the FLAC file, Win10 loads Audacity and hands it the file.
(b) Choose Tools, Apply macro, Mp3 Conversion.txt :-

Comment:_=“”
SelectAll:
Normalize:ApplyGain=“1” PeakLevel=“-1” RemoveDcOffset=“1” StereoIndependent=“0”
ExportMP3:

(5) What do you expect to happen?

I expect an MP3 file to appear in my export folder

(6) What actually happens?

As stated above, a message box, about a quarter the area of my screen pops up with Send/Don’t Send.
I chose “Send” both times, so in theory there is a pile of debugging data sitting somewhere.
Next time I will take a screen snapshot before choosing “Send”.

I say “reproducible” because it happened twice in immediate succession.
I made copies of my macros, audacity.cfg and the FLAC file.

Some eight hours later I have reproduced the bug. I have taken a screen snapshot, made a text copy of the pop-up box.
I have attached a ZIP file with as much data as I had thought to capture.

What is the protocol for reporting a bug and for supplying useful data? As far as I can see we have no “Bugs” forum, even to pose questions about 'What can I do better next time"

Thanks, Chris
20220919_1428.zip (903 KB)

As your ion concerns macros, I’ve moved the topic to the “Macros and Scripting” board.


That sounds like the crash report window, so the problem is that “Audacity crashed”.
The crash report may contain useful information for diagnosing crash bugs.


If you run it again with the same files, does it crash every time?
If you use a different file, does it crash?


Fwiw, I ran the default “MP3 Conversion” macro successfully with the “jsbach_28a-voice_schweitzer.flac” file you provided.


The protocol for sending bug information to the developers is to click the “Send” button.

For questions about bugs, just post in the most relevant part of the forum (for Windows users, that’s usually the “Windows” board, unless the question fits better on one of the other boards).

Thank you, Steve. At the time, all i knew was that “Audacity has crashed”, so I would not have thought of it necessarily as a Macro problem.

The crash report may contain useful information for diagnosing crash bugs.

… but not at all useful to me. As a programmer, i can see a stack report, but the data is couched in terms of identifiers known only to the Audacity programming team.

If you run it again with the same files, does it crash every time?
If you use a different file, does it crash?

I ran it yesterday afternoon (same FLAC/Macro) and it crashed again. I have not had a chance to try it with a different FLAC, but will be doing that today. I have a half-dozen tracks waiting to be processed but delayed that until I had learned the protocol for reporting crashes!

The protocol for sending bug information to the developers is to click the “Send” button.

Thanks. As far as I can see that doesn’t provide a means for anyone to get back to me with further questions; "Send"ing the crash report is a one-way channel for data; is that correct?

Thanks again, Chris

Yes, it’s one way. The process avoids sending personally identifiable information as far as possible, so the developers that receive the information don’t know who sent it and have no way of getting back to you. (Audacity Privacy Policy: https://www.audacityteam.org/about/desktop-privacy-notice/)

If you want someone to get back to you, use either this forum, or the new Audacity discord channel: https://discord.com/invite/audacity .
(Currently, you’re more likely to receive a prompt response here.)


Do let us know what happens.
By the way, was the Flac file that you sent (in the Zip) the exact same file that you had problems with?

I got as far as the SMS and I don’t do texting.



Do let us know what happens.
By the way, was the Flac file that you sent (in the Zip) the exact same file that you had problems with?

Delayed by work on the house.
I am about to retry the original FLAC three times and will report back.
Yes, it was the same FLAC.
Most times when a bug in anything develops i make copies of user files, in this case the FLAC, my audacity cfg, the macro body and so on, so that I can, if requested, try to duplicate the bug (always a good idea before posting), AND ring changes on the setup in dialogue with a team member.

'Twere no bad thing to have a list of “files to be secured” in the case of a bug report.
Cheers, Chris

Three essays, three failures but appears to have generated only two bug reports (five minutes ago)
Cheers, Chris
20220922_0616.zip (791 KB)

I’m not familiar with the abbreviation “SMA”, but discord is available through a web browser (I don’t do texting either, other than personal friends).


I’ll try that FLAC file on a Windows machine and see if I can reproduce the issue there.

A typo on my part; another reason that I don’t do SMS :laughing:

I’ll try that FLAC file on a Windows machine and see if I can reproduce the issue there.

Thanks Steve.
Let me know by email if you need any other data. I am now going to get bcak to recording …
Cheers Chris

:smiley:

I’ve tested, using the macro and Flac files that you provided, with Audacity 3.1.3 on Windows 10. I was not able to reproduce the crash - it worked as expected.

As a test, perhaps you could try changing the location of the macro-export folder. For example, try setting it to your Desktop.

If that makes no difference, you could try doing a complete reset of Audacity’s settings:
With Audacity closed. move the files:

  • audacity.cfg
  • pluginregistry.cfg
  • pluginsettings.cfg

to a safe backup location (so that you can move them back again to restore the Prefs), then restart Audacity.

Hello Steve.
As a good scientist I changed one aspect at a time:-

(1) I moved the three configuration files (and updated my AutoExec,bat to add the two plugin settings to my daily safe copies), executed the FLAC, and then Tools, Apply macro “MP3 Conversion”. Crashed and sent report about fifteen minutes prior to this post.
Untitled.png
(2) Then I Ctrl+P reset my macro output from B: to Desktop, and (image above) it appears to have worked. At any rate, it ran to conclusion.

I have only recently (past month?) been using B: as my macro output drive.

B: is a drive letter assigned to my daily blotter file by the autoexec.bat, as in:-

::
::	Make the daily blotter folder as drive "B"lotter
::
		@echo. |date
		@set yr=%date:~6,4%
		@set mt=%date:~0,2%
		@set dy=%date:~3,2%
		SET DAILY=%YR%%MT%%DY%
		SET FIRSTBOOTOFTHEDAY=
		if not exist T:\Blotter\%DAILY%		SET FIRSTBOOTOFTHEDAY=Y
		if not exist T:\Blotter\%DAILY%		MD T:\Blotter\%DAILY%
		if not exist B:\NUL subst B: T:\Blotter\%DAILY%

What is B:, to which I was directing macro-outoput?
Drive B: is a DOS SUBST for (today) “T:\Blotter\20220922”, but yesterday as “T:\Blotter\20220921” and tomorrow will be “T:\Blotter\20220923”.
Just like the fresh desktop blotter we used to see fifty years ago after the cleaning lady had removed the top layer of the blotter pad and discarded all our doodles, lunch dates, and Important Telephone Numbers and tossed that data into the rubbish bin.

I start each day with a fresh B:, you see.

What is T:?
T: is the Veracrypt assigned drive letter to a large encrypted partition on the only HDD in the laptop.

So, I am suggesting that the MP3 be written
via a SUBST
via an encryption
to a hard drive.

Right now my money is on Audacity getting confused with two or three layers of redirection, especially the DOS SUBST command

I await your next suggestion (which may well be “Stop using DOS SUBST for Audacity files!”)

Thanks, Chris

Haha, yes :smiley:

Though perhaps you could try using a symlink to the “B: drive”. (I’m not sure exactly how symbolic links work on Windows, but could be worth a try.)

I aimed at B: because it is a permanent location (rather than my transient RamDisk E:) and provides an archiving mechanism if all else fails (stretching backup to probably 2012).
I shall essay using T:\Blotter
That leaves my audio-book folders un-cluttered and still provides an audit-trail,

Question: Now that we think we know the problem, do you get to flag the latest few bug reports as “fixed” so that no-one spends time poring over the entrails?

Cheers, Chris

Do we know the problem yet? Is it SUBST causing the problem, or the encryption, or something else?

If you are using top level B: as your location for Macro output then that is the problem as there is a known and logged issue for that:
Audacity crashes on export from Macros to a top level drive #2471
https://github.com/audacity/audacity/issues/2471

I logged this on 25Jan22 abs sadly this remains open and unfixed …

Peter

Hello Peter.

“example F:\ it crashes! … With path: F:\macro it works …”

As I understand it, then, if in my Autoexec.bat I (daily) created not only a SUBStituted drive B:, but went on to MD a folder "B:\Stuff", then my macro-output could be stored on drive B …

On my decrypted partition drive T: I have a permanent folder "T:_Spare" where are archived older copies of MSWord’s Normal.dot template. I could as well direct macro-output to T:_spare\

In my case, the bug was triggered because macro output was directed to the root folder of a drive, correct?

Thanks, Chris