Convert Text file -> Tag limited number of fields?

Did the developer of MP3tag intend setting a limit on the number of fields in a text file for the Convert: Text file -> Tag function?

I believe I found such a limit. I constructed a format string with fifteen fields in it, including %_filename_ext%. Specifically my format string looked like this:


For one solid hour I tried to get this to parse and it wouldn't parse.

Finally I eliminated the last two fields, %involvedpeople% and %comment%.

And the routine parsed my lines exactly with what remained.

It would appear, therefore, that a line in a text file can hold up to thirteen fields. The program seems unable to parse any line having more fields than that.

I had hoped to create an all-purpose format string that could handle absolutely any information I would want to put into a tag. This includes the %involvedpeople% field, which holds entries for pianists, harpsichordists, organists, trumpeters, and other instrumental (and vocal) soloists (the conductor has his own field), as well as for arrangers. (Like the conductor, the composer has his own field.)

But it would now appear that I must remove certain fields, the entries of which would be guaranteed the same for all tracks in an album. Things like %albumartist%, %album%, and %year%, to name three. I can do that, but it would have helped to have some documentation so advising.

I just created a data file with 19 fields and it worked.
Here is the field list:

So I think we would have to have a look at the data as well.
and here is the dummy data:
Bravo Hits 102@Jonas Blue@Various Artists@106@Sampler@Jonas Blue@1@Pop@alle:;@1@deu@2018@me|128@2018-07-11T11:00:00Z@ganz geil@Nicky Romero fe Quarterback&Junior J - Bittersweet@3/44@2018@Gröhlemeyer

Must the %involvedpeople% file always end in a semicolon, even if only one "involved person" exists?

Here's a format string I just tried--and nothing worked.


And the data:

1.mp3@Mozart: Piano Concertos Nos. 23 and 17@Orchestre De Chambre Jean-François Paillard@Piano Concerto No. 23 in A Minor, K. 488 (1st Movement)@1st Movement@Allegro@1@@Classical@Jean-François Paillard@W. A. Mozart@Piano:Gyorgy Sebok

What strikes me:
the list of fields ends with %involvedpeople instead of %involvedpeople%

The separator that you use is also part of the data: @Classical - this is not allowed. You would have to mask that like "@Classical"

The first part was a copy-and-paste failure on my part. My format string ends with %involvedpeople%, as I agree it should.

I had intended the genre name to be "Classical." I think what you're looking at, is that the "Discnumber" field is empty. I had intended this to be a generic format string that could handle a single-disc album, a double album, or a boxed set.

%albumartist% %album% %artist% %title% %movement% %movementname% %track% %discnumber% %genre% %conductor% %composer% %involvedpeople%
Mozart: Piano Concertos Nos. 23 and 17 Orchestre De Chambre Jean-François Paillard Piano Concerto No. 23 in A Minor, K. 488 (1st Movement) 1st Movement Allegro 1 Classical Jean-François Paillard W. A. Mozart Piano:Gyorgy Sebok

If I convert the data and the field list into a table I get this result.
The alignment does not match.

Try this one. I sent you a trucated file by mistake.
One more thing: could it be that when I tried to copy and paste the format string from a text editor, I ended up copying in a carriage-return/linefeed sequence to the end of the string? Would that have blown it up? I begin to wonder...

1.mp3@Jean-François Paillard@Mozart: Piano Concertos Nos. 23 and 17@Orchestre De Chambre Jean-François Paillard@Piano Concerto No. 23 in A Minor, K. 488 (1st Movement)@1st Movement@Allegro@1@"@Classical"@Jean-François Paillard@W. A. Mozart@Piano:Gyorgy Sebok

The masking of the Classical genre is only temporary, to satisfy the comment parser.

OK, masking apparently is not really necessary.
This data imports without any message and fills all the fields as far as I can tell.

Problem solved.
In every instance in which the file failed to parse, I had copied and pasted the format string into the dialog box from a text editor. I had reasoned that composing the format string ahead of time would aid my memory.
Sadly, that kind of copy-and-paste introduces stray invisible characters, which I believe are a carriage return and linefeed. If those characters make it into the format string field, the program will choke on them. It will expect to find a CR-LF delimiter at the end of each line and won't know how to interpret what it does find. Hence the parsing failure.
When I typed in my long format string directly, the file parsed correctly, and within a second (for nineteen files).