[X] Incorrect Tools behavior

I have this quite long running problem with Mp3tag in conjunction with Audacity. I have described it already on Audacity's forum: http://forum.audacityteam.org/viewtopic.ph...49&p=304479 [so this post will be a slight rework of that old post from that link]

The problem comes down to this:

Tools > Option > Tools
defined as
Name: Audacity [not important]
Path: C:\Program Files (x86)\Audacity\audacity.exe
Parameter: "%_PATH%"

[This Mp3tag Option has been a subject of this helpful post: /t/17592/1]

This gives me the ability to execute via keyboard shortcut [or right click sub-menu] an order to send selected files from Mp3tag straight to the Audacity [for the purpose of seeing it in spectrogram]. And this works perfectly for one file: Audacity opens it in a maximized window. This also works in the same way for two files: each is opened in a separate instance in maximized form. But when I select three or more files and execute this tool in Mp3tag, then one file is opened correctly but the second one, the third one and so on are opened usually all together in one big [second] instance; and thus showing up not in a full view but in a squeezed vertically form

If this wasn't a bug, also only one instance should be opened for two files, dividing place inside it for those two. But instead Audacity chooses to treat one as one, two as two but three or four or five as two. Also when the loading process of more than two files is taking place I can see: first instance being opened with one file maximized > second instance being opened with second file maximized > third file being opened in second instance which now has room inside it split between the second and third file

Also: when there are more files that take more space on a hard drive [and so the overall loading process is prolonged], sometimes I get for example a mix up like
first instance - with 1 file
second instance - with 3 files
third instance - with 2 files

And this pretty much unforeseeable behavior disrupts my workflow

This problem is constant and continues to be throughout updates of Mp3tag, Audacity and Windows. The fact the I can see for a split second a proper behavior on the second file / instance would indicate that it is the sole fault of Audacity [the receiver] and not Mp3tag [the sender]. But I am also using file handler FreeCommander [http://freecommander.com/en/downloads/] in the same way [as as sender] without that problem: every time I get one instance per one file, no matter how many of them I select at the same time. To achieve that I use "favorite toolbar" icon / keyboard shortcut [not to be confused with "favorite folders"] set in FC like that:
Name: Audacity [not important]
Program or folder: C:\Program Files (x86)\Audacity\audacity.exe
Start folder: %ActivDir%
Parameter: %ActivSelName%
Enclose each selected item with "
Run: Separate for each selected item

Only sometimes I get a messages saying "File removed from the list of recent files". [And then I can close that message and open that particular file from within the Audacity; or drag the file over Audacity and release it; or load some other file and then try to load the old one from within FC - so it's not the fault of the file]

I'm running up to date Windows 7 x64, Audacity 2.1.2, Mp3tag 2.77 and FreeCommander XE 2016 Build 715 32-bit public

On the forum for Audacity that crazy behavior of Mp3tag has been confirmed; and it was suggested to seek answers on the Mp3tag forum

I would do the same if I were on the audacity forum: you get an answer but the answer does not really help.
The question is: why doesn't audacity open all files in the same way but squeezes some files in an mdi interface?

What you could try: call a separate shell for each audacity instance.
I found the start command:
so if you use not just
C:\Program Files (x86)\Audacity\audacity.exe
start "C:\Program Files (x86)\Audacity\audacity.exe"
and some more parameters from the technet article above, it might lead to success.
I do not use audacity, so I cannot test it.

"Separate shell" meaning: to start a separate command line for every file?

That is what I have been testing already:

'/Q/D/U/C START "AUDACITY" /MAX "C:\Program Files (x86)\Audacity\audacity.exe" "'%_PATH%'"'

No luck. I've tried


and some variations with

" "
' '

After those further tests, all I can tell is this: Audacity chokes on larger queue

If I load some 20 files that are 1-5 second long, I get 20 instances

If I load 5 files that are 10 minutes long, here's what happens: all are started but then stopped near the beginning of the loading process [which I can see on a progress bar], with only one file being loaded to the end; and then second one and third one. And I get 2 instances- because length [size] of each of them was very similar

If I load files of different length, varying for example from few seconds do 10 minutes, that I get all that crazy behavior. Because some files are loaded fast enough [to get separate instance] while others get caught in a traffic jam and as a result get mixed with others

Investigate Audacity LOF files: http://manual.audacityteam.org/man/lof_files.html
Then, use an export script instead of a tool.

To open all selected files in one Audacity window:

$filename($getEnv(USERPROFILE)\Desktop\List of Files for Audacity.lof)
$loop(%_path%)file "%_path%"

To open one Audacity window with each selected file:

$filename($getEnv(USERPROFILE)\Desktop\List of Files for Audacity.lof)
file "%_path%"

A downside:
I believe that only ANSI file paths are acceptable.

FYI: a link to the middle of a thread discussing evaluation of audio files by sight.

But how is this whole process suppose to work?
a] I select files
b] I use CTRL + E
c] I select proper export script
d] I crete a new LOF file [listing those currently selected files]
e] I have to... manually load up that LOF file to the Audacity?

I could workaround that manual load by creating a BAT file sending that LOF file to the Audacity, and place that BAT file as a Tool in Mp3tag [and so evoke it with a keyboard shortcut]. But this whole process would require a lot of clicking

Although it must be said that your solution to that bug is valid: files listed in LOF are loaded one by one, in a separate instances

But that this say to us, that this bug is the fault of Audacity?

Yes, if there are some illegal characters in filenames of those files listed in that LOF file, that whole list [file] is not recognized correctly by Audacity [and you get an error about it]

A huge obstacle in the quest for a smooth workflow

I've taken o look at it and I see I must read it thoroughly, because it this the kind of info that I am after for some time now [/t/17591/1]

So thank you very much for that link

Go to Options > Messages.
Make sure "at exporting tags" has a check-mark.
This causes a message to be displayed after exporting which asks: "Display Export file now?"
If you answer "Yes", the LOF file will be opened by its default application, which is Audacity.

BTW, this is how scripts can be executed.
More information: passing multiple selected items to external tool

What bug? I don't see a bug in Audacity or Mp3tag.

If we could find a way to write the short file paths (also called 8.3 or DOS) to a LOF file, the file path character restriction would be overcome.
Audacity shows the long file names, even when given the short path.

I have tried methods using DOS and VBS, but have found failures in each.
Maybe I'll try again.

After creating first LOF file, I opened it Notepad to check what exactly was written in it; and associated that format with Notepad

So after re-associating LOFs with Audacity, whole process doesn't differ that much from using a Tools- only two additional [closely places on screen] clicks are required, the rest is automated and no additional external elements are required [like a BAT]

So your workaround is very neat, thank you very much for this solution

I was referring to that queued choking on larger files in Audacity. Here it is again:

In the thread that you evoked [passing multiple selected items to external tool], there is a statement

So is it a limitation or is it a bug?

And does it have something to do with that multiple instances choking behavior I just quoted?

I'm asking because my problem with Mp3tag-Audaciity communication comes down to this: one file = no problem; more files = possible problem

And that is way over may head

If you have time and will to do so, then please do

Try my new export script, found here: Send tracks to Audacity with an export script.

Thank you very much

I will surely tell about it on Audacity's forum, in the thread I started about this Mp3tag-Audacity issue

It took me ridiculous amount of time, for which I'm sorry, but I've finally did do it:


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.