Export Multiple: incorrect output - file names not numbered correctly

I believe that I have found a small bug in the Export Multiple filename routine.

Specifically, EM does not use the track number to name output files, but the file sequence number for that specific EM execution. So even though we specify a track number for tracks on side 2 of an LP, the filename sequence starts over at 1, not at the side 1 track count + 1.

This is hardly a killer bug , but this appears to be incorrect output to me.
Alternatively, of course, if this is EXPECTED behavior, then it is less than optimal since part of the point of numbering files is to be able to sort them by file name and have them appear in the correct order.

System: Audacity 2.3.2 Windows 10 64 bit

Reproduction steps:

  1. Record Side 1 of LP - do noise reduction, labels for track titles, etc.
  2. Record Side 2 of LP - do noise reduction, labels for track titles, etc.
  3. Load project for Side 1
  4. Edit Metadata as appropriate - include a Tag for ‘LP Side’ = 1; uncheck “don’t show when exporting audio”; save for reuse
  5. Export Multiple to MP3 - choose appropriate output folder; split on labels; numbering before label/track name
  6. accept each metadata display as each track is processed
  7. Examine output results (use mp3tag or equivilant)
    ==> notice filenames are CORRECT, e.g. “01_sideonetrackone” for track 1 etc <==
  8. Load project for Side 2
  9. Edit Metadata as appropriate - load saved metadata file, set ‘LP Side’ = 2; uncheck “don’t show when exporting audio”
  10. Export Multiple to MP3 - choose appropriate output folder; split on labels; numbering before label/track name
  11. edit each metadata dialog at it is displayed - renumber track number starting at side 1 track count + 1 and increase for each
  12. Examine output results (use mp3tag or equivilant)
    => notice filenames are WRONG, e.g. “01_sidetwotrackone” for track 6 etc (if side 1 had 5 tracks) <=

The metadata track number tag is being set correctly, however the numbering for the filename ‘prefix’ is NOT being built from the track number tag.

There are literally dozens of additional options that “could” be added to Export Multiple, but as with most things in Audacity, it was decided to keep the interface as simple as possible while still retaining a good amount of flexibility.

For your use case, the solution is to include the track number in the label names, rather than using the automatic numbering feature in Export Multiple (which always starts at “1”).

Alternatively, you could place sides 1 and 2 in the same track and Export Multiple both sides, though that would not allow you to list “side 1” / “side 2” in the metadata.

Thanks for your reply, Steve.

There are literally dozens of additional options that “could” be added to Export Multiple, but as with most things in Audacity, it was decided to keep the interface as simple as possible while still retaining a good amount of flexibility.

I understand completely. On the other hand, there is nothing simple about an interface that produces incorrect output . ‘Incorrect output’ should not be engineered in just because it is the ‘easy’ thing to do. Frankly, I’m rather surprised that you consider ‘correct output’ an “additional option that could be added”.

For your use case, the solution is to include the track number in the label names, rather than using the automatic numbering feature in Export Multiple (which always starts at “1”).

Sorry, NO, that is NOT a solution nor is it an acceptable workaround.

Your suggestion produces correct file names but incorrect titles. That is not just irritating, but flat out wrong.

A better workaround is: 1) after the export multiple for both sides, open the folder with MP3tag. 2) Ensure the files are in the correct order by sorting on the track number tag. 3) Renumber the tracks to include a leading zero if necessary. 4) Rename the files using an appropriate tag to filename pattern like %track%_%title%.

Keith

Further to my earlier reply.

Alternatively, you could place sides 1 and 2 in the same track and Export Multiple both sides, though that would not allow you to list “side 1” / “side 2” in the metadata.

Yes, that is a viable solution. I could edit the metadata ‘on the way through’ to change the side number, just as I currently change the track numbers for the second side. This would be fairly straight forward.

However, it would start to get unwieldy as the number of side grew to 4 or 6. You’d have to adjust the inter-song gaps at the beginning and end of each side, and this moves the location of the all the labels so then you have to adjust them all.

Keith

Not if you set Sync-Lock to be on - see: Sync-Locked Track Groups - Audacity Manual

Alternatively when editing make your selection in both the audio and the label track.

WC

I am failing to understand what the problem (or possible bug) might be here

  1. get some audio
  2. create three labels a, b and c
  3. Export Multiple
  4. choose Numbering before Label/Track Name
  5. Export
  6. observe 3 files - 01-a.wav 02-a.wav 03-a.wav

alternatively

  1. get some audio
  2. create three labels 01 a, 02 b and 03 c
  3. Export Multiple
  4. choose Using Label/Track Name
  5. Export
  6. observe 3 files - 01 a.wav 02 a.wav 03 a.wav

This all looks perfectly sound to me, expected behaviour as documented in the Audacity Manual.

The second method is what I used when I transcribed thousands of LPs and tapes some while back, using this to ensure that my recorded tracks remained in the right order.

WC

Personally I preferred to edit my metadata in iTunes (and separately on my X30 “jukebox”) once I had transferred the files there - the metadata editor in iTunes worked much better for me than trying to manage it in Audacity.

WC

I don’t understand why you say that the output is “incorrect”. I’m unclear about your provide “Reproduction steps”.

What does “Edit Metadata as appropriate” mean? What are you entering for the metadata?
Where are you entering “include a Tag for ‘LP Side’ = 1” ?

You are correct except that I am doing those steps TWICE, once for side 1 of an LP and again for side 2 of an LP. The first side results in files 01_ 02_ 03_. Then when I do side 2, I specify in the metadata the track number to use for each track, (4, 5, 6). I EXPECT the output files to be named 04_ 05_ 06_. That is, the file name should be built from the track number.

Thanks, I’ll check that out.

ITunes is not an option. Even if we were talking about the Apple version in this forum :unamused:

I mean I expect that the number appended to the beginning of the filenames produced should be equal to the track number recorded in the metadata.

What does “Edit Metadata as appropriate” mean? What are you entering for the metadata?

It means I’m filling in the fields on the Metadata tag sheet - Artist, Title, Genre, Year, etc.

Where are you entering > “include a Tag for ‘LP Side’ = 1” > ?

I have added several ‘custom tags’ using the Audacity editor for that purpose. One such tag I added is ‘LP Side’ specifically so I could sort the tracks in MP3Tag before renumbering them in order to rename the files. The ‘LP Side’ is not a necessary condition for this problem.

I suspect the problem could be shown by just changing the track number to something outrageous when exporting ANY file. I haven’t tried this, but if you set the track number to, say, 47, and export that it will still build a filename that starts ‘01_’ instead of ‘47_’.

What do you expect to happen with those custom tags?
What is actually happening with those custom tags?

It’s your use of words like “etc” that make it impossible to understand what you are trying to say. We don’t know what you mean by “etc” unless you tell us. You have told us that “etc” includes some “custom tags”, but not exactly what tags you are supplying.

Where does the documentation suggest that metadata is passed through to the file name? (metadata plays no part in naming the exported files).

What do you expect to happen with those custom tags?

I expect Audacity to write them to the metadata on the file.

What is actually happening with those custom tags?

Audacity is actually writing them to the metadata on the file.

I don’t understand why this is causing you confusion about the issue. The custom tags are not involved in the issue.

Track number is NOT a ‘custom’ metadata field, it is a standard field present in all metadata output formats.
Track title is NOT a ‘custom’ metadata field, it is a standard field present in all metadata output formats.

It’s your use of words like “etc” that make it impossible to understand what you are trying to say. We don’t know what you mean by “etc” unless you tell us.

OK. I’ll apologize for that.

“etc.” means “and so forth” and is used to denote that there are other items that would just be tedious to list and not add any value to the discussion.

You have told us that “etc” includes some “custom tags”, but not exactly what tags you are supplying.

You are focusing on irrelevant detail instead of addressing the issue at hand. Audacity is handling the custom tags exactly as it should be. The custom tags I added have no bearing on that issue. You do not need to use any custom tags to replicate the problem.

The problem is NOT IN THE METADATA. The problem is that the output file NAME, that is the name the operating system sees, is not being built properly. The file should be named by combining the track number from the metadata with the track title from the metadata. This has nothing to do with custom tags in the metadata - it has to do with using a loop counter to name the file instead of the actual track number.

Where does the documentation suggest that metadata is passed through to the file name? (metadata plays no part in naming the exported files).

Well, the track name is part of the metadata, it comes from the labels we put into the project, so yes, in that way, the file name does come from the metadata because the label is a piece of metadata.

But I get your point, you are saying that the routine that cuts the file gets its name from the labels before it constructs the metadata object, and therefore does not have access to the metadata.

My point is that this is a design decision which results in “incorrect output” because the expectation of most people who number file names is that the filenames match the track number.

OK I see. That is the way that you would have designed Audacity, but it is not the way that the feature was designed. This is not a “bug”, it is a disagreement about how Export Multiple should handle metadata and file names.

What Audacity actually does regarding the file name when performing “Export Multiple”:
If exporting based on “tracks”, then the name of the track is used as the file name, otherwise export is based on “labels” and then the label is used as the file name.
Because you can’t have two files in the same directory with the same file name, attempting to write a second file with the same name as an existing file would overwrite the existing file. That would defeat the point of “Export Multiple”, so to avoid overwriting existing files, Audacity will append a number to the file name in this case so that each exported file has a unique name.

Example:
If you have 3 tracks, named “AAA”, “BBB”, and “AAA”, and no labels.
Export multiple is “based on tracks”.
The Exported files will be named “AAA”, “BBB” and “AAA-2”.
The “-2” has been appended to the file name of the second file that would otherwise have overwritten the first “AAA” file.

Export multiple is always based on “tracks” OR “labels” (not both), so the file names come form either the track names, OR the label name.

If you name the tracks as “AAA-1”, “AAA-3”, and “AAA-2”, and export multiple WAV files based on tracks, then the file names will be (respectively): AAA-1.wav, AAA-3.wav, and AAA-2.wav, but because the metadata “track number” tag just increments from “1”, the metadata track numbers will still be 1, 2 and 3 respectively, because that was the order of the tracks in the project.

If you name the tracks as “AAA-1”, “AAA-3”, and “AAA-2”, and export multiple WAV files based on tracks, then the file names will be (respectively): AAA-1.wav, AAA-3.wav, and AAA-2.wav, but because the metadata “track number” tag just increments from “1”, the metadata track numbers will still be 1, 2 and 3 respectively, because that was the order of the tracks in the project.

Yes, I this is a good strategy to avoid naming collisions - i.e. putting a unique number into the file name.

This still doesn’t really address the issue though. Audacity must be checking for unique label/track names BEFORE it starts writing the file because, according to your example, it only appends a number if it detects a collision. But, if we tell it specifically to ALWAYS put a number into the file name by checking the 'Numbering before label name/track name" option, Audacity doesn’t need to do any checking what-so-ever because the resulting filename is guaranteed to be unique (unless… see below).

The question then becomes, where do we get that sequence number from? Clearly, Audacity is getting it from a loop counter; my argument is that it should come from the output track index as stored in the metadata.

Here is my reasoning:

First the scenario that I am trying to ‘clean up’. We record an LP, side one is saved as Project A; side two is Project B. The LP tracks are labeled. For the sake of the discussion lets suppose that the first LP track on BOTH sides is labeled ‘AAA’ and there are 5 track/labels on each side.

\

  1. We export multiple Project A into FolderZ with numbering ON.
    => So FolderZ now contains 5 files, the first one has the name 1_AAA.wav.

  2. Now we export multiple Project B into the same FolderZ with numbering ON.
    => and we have a name collision error when the Side 2 label 1_AAA.wav file is attempted.

Notice that the user has NO WAY to avoid this collision name because the sequence number is generated from an internal loop counter of some sort.

On the other hand, and the point I’m trying to make is, the user DOES have control over the metadata track index, because Audacity gives the user the chance to modify the metadata before it writes it to the file, and it does this for all track/label metadata sets before it begins to write any of the files.

If the metadata track index was used instead of an internal sequence number the scenario would shake out like this:

  1. We export multiple Project A into FolderZ with numbering ON.
    => Just as before FolderZ now contains 5 files, the first one has the name 1_AAA.wav.
    => This is identical to item (1) above

  2. Now we export multiple Project B into the same FolderZ with numbering ON
    => If the user did nothing, we would get the same name collision as before, because the metadata track number starts at 1 each time.
    => This is identical to item (2) above since the user did nothing to chance the default metadata track index.

However, we CAN change that metadata track number before Audacity begins to write the files. So instead:

  1. Now we export multiple Project B into the same FolderZ with numbering ON.
    => Audacity presents us with the Metadata edit form, once for each track/label it is going to export
    => As each edit form is presented, we change the track number to ‘6’, ‘7’, ‘8’, ‘9’, '10, each in turn
    => Audacity uses the track number for the file name and Side 2 label 6_AAA.wav is written and there is no name collision.

This is the specific reason that I refer to the current situation as ‘incorrect output’ even though I fully realize it is the designed result. The design, as coded, is GUARANTEED to produce a name collision in the scenario as presented, even though the design is specifically supposed to avoid that problem - as described by you in your reply.

Furthermore, as an end user, I expect to have control over the output file name as much as practical - and this suggestion does just that.

Finally, the implementation should be quite simple, I think, (though of course I am not looking at your code), I am not suggesting that you ‘turn off’ the collision detector code at all. Rather I suggest that before you check for file name collisions, however you do it, you add another step if the user has asked for file numbering, simply prepend the metadata track index to the file name instead of the loop counter.

Audacity is “open source”, which means that you are free to modify the source code as you wish. If you create a new feature, you are welcome to submit a “pull request” and your new feature will be considered for inclusion in the next Audacity release.

The example workflow in the manual avoids the name collision (Sample workflow for LP digitization - Audacity Manual) by recording both sides into one track, and then export multiple with the entire track.

Another way to avoid that naming collision would be to create two folders, one called “Side1” and the other called “Side2”.

Another way to avoid that naming collision is to ensure that you use unique label names.