Feature Request: Optional embedding of import format string in import data file

General Discussion
1

Merry Christmas / Happy New Year / Happy Holidays, all.

In response to Florian’s Christmas newsletter call for feature requests, here’s one that ranks as that which I would second-most like to see (my first choice having been shot down previously).

I do a LOT of importing of tags, usually in large groups. Probably my longest and most complicated import format string is:

%track%. “%title%” (%songwriter%) — %dummy%#CRLF#ART: %artist%#CRLF#PRS: %personnel%#CRLF#REC: %date_rec%#CRLF#CMT: %comment%#CRLF#PRD: %producer%#CRLF#ENG: %engineer%#CRLF#COPYRIGHT: %copyright%

I have that string saved with a title under “Convert > Text file - tag > Format string > Manage history…”, and use it as a starting point for customized format strings for various audio files I have, which may or may not require all of the tags specified in that full format string as shown above. I think it would be nice if I could optionally embed/include the exact format string to be used as the first line in the file containing the data to be imported. Perhaps this could be facilitated by having the first line of the file automatically interpreted as an import format string if it meets certain criteria, such as beginning with %, or having a checkmark box in the dialog to get the import format string from the file instead of using whatever’s entered in the dialog?

2

As it happens, I am dealing with similar problems when choosing masks for Convert Filename to Tag for one particular file source. This source has quite a few variations in the tag sequence, uses a comma plus a space as the delimiter (sometimes hard to see), and is in a foreign language.

Using the dropdown slowed down the process but the slowest part of all was and is identifying which mask to use.

So I created a Notepad file to hold all the mask variations used by that particular source. I added to the list as I found more variations. I keep this Notepad file open when I am working with Convert Filename to Tag:

HardthausenMasks
HardthausenMasks648×408 143 KB

I can scan the variations shown in Notepad much faster and more accurately than in the dropdown. And in Notepad the masks are organized and larger and easier to read. When I find a match, I copy and paste into the Filename to Tag converter.

Your suggestions are rather ambitious but perhaps my Notepad solution will help in the meantime.

3

Thanks for the suggestion. Actually, my workflow is already fairly similar, though using Notepad++ (highly recommended, especially if you rely on regular expressions like I do) instead of regular Notepad, and while I don’t generally store a bunch of import format strings in one particular text file, I do usually work them out in a file or an unsaved NPP tab. But I’m already creating/editing the file of import data — separately, or sometimes I work out the import format string in the same file before cutting/pasting to MP3Tag’s import dialog — and it would definitely be smoother if I could just leave the import format string in that file and have it used like that.

4

The drawback of that function would be that you cannot change an existing list without editing the import text file, e.g. if you want to import only a certain set of fields but ignore the rest with %dummy%.

I agree that it would be a nice feature if the function would

  • read the first line from an import text file perhaps with an option ticked "First line contains field list"
  • offer that format string for modification
  • use the matching format string for the import after the user has hit OK.

I would not like a blind automatism that might lead to unwanted side effects.

5

Thanks for your input. I think I could be happy enough with your proposal, but feel I should point out that, for my purposes anyway, once I’ve embedded an import format string within a particular import data file, that string has already been tailored specifically for what I want imported from the file, and ideally, should never be needed to import from again (barring any future hard drive crashes or other data loss, of course). Or you’re thinking the same import format string might get retained in the dialog and inadvertently re-used for the next import operation, assuming the next one doesn’t involve its own embedded format string?

All this is subject to Florian’s discretion and programming wisdom, of course, but how about:

  • If an embedded format string is found in the selected data file, the content of the format string field does not change BUT gets ghosted and made non-editable

OR:

  • If this feature is implemented using a checkbox in the dialog to manually indicate the presence of an embedded format string, then when the checkbox is checked, as above (content of the format string field does not change BUT gets ghosted and made non-editable)

  • It might not be a bad idea to also implement some kind of intelligence so that if the checkbox is NOT checked but the data file turns out to have an embedded data string as its first line anyway, that line is ignored