As I see it: a new function is needed to cater for a particular workflow. And I am eager to learn what the benefit of that workflow would be as currently I use a different approach. And it could well be that I use the existing functions in a complicated way and there would be an easier way.
So far, when I look at that what I have learned so far about the new function it eases the detour over an external program that I found so far not be necessary.
On the contrary, I find the step with external program (and not to say "spreadsheet") more long-winded than a direct manipulation in MP3tag.
But it could be that I do not see the ne function's advantage as I do not know the details.
What I have gathered so far: there are unnamed editor functions in the external editor.
I would find an answer to @LyricsLover's statement
useful.
It could be that as a consequence of our exchange here I would better adapt my workflow to use the new function.
I'm sorry, but I find it hard to follow the way you express things.
It is very simple.
I gather information from multiple sources including my own analyses of track characteristics, info available on web pages, or even just OCR (or manual entry!) of information on the case insert. These I just dump into a plain text file as I find them. Call it my scratch pad.
I then use straight-forward text manipulation (eg global text replacement) to sanitise the information into the fields I want to apply as tags, and tweak anything that needs correcting.
Applying the information in my scratchpad to the file tags is then a case of copying each field and pasting it into the required tag in MP3Tag.
All I am talking about is being able to copy and paste tab-delimited plain text into the MP3Tag display of files and tags just as if it were a spreadsheet. That would be one operation as opposed to (say) 60 (three tags for each of 20 files, for example).
Doing this purely within MP3Tag instead of having a scratchpad means copying strings from multiple sources, and reformatting them individually instead of as a collection — even more tedious and prone to human error.
I think perhaps you people are too used to the indexing having been done for you in the on-line databases. As I said, the CDs I use are not often in the databases, and even if they were I would prefer to do it myself, plus I have data only relevant to me.
From what I gather, your idea is to be able to select these strings, copy them from the source document and paste them directly in the Extended Tags window, and have Mp3Tag automatically assign tag headers and tag values from these strings, divided by some defined separator character (tab, comma, etc). The source data would be curated by yourself from multiple sources / manual input.
Is this the gist of it?
If it is, you can almost do this with the 'Text file - Tag' conversion: it would (just) require of you to save your data to a text file, and them use the aforementioned tool to import these strings into tags. (EDIT: yes this has been suggested above; my point was to make a comparison between what you ask and what is already available).
If it's not, maybe a visual representation (simple drawing or screenshot) would be (more) useful to help to get your point across.
But Mp3tag is not a spreadsheet. It uses a different concept altogether.
It can take a while for new users to adapt their workflow to use Mp3tag to its best advantage. It certainly took me a while. But apparently you want to keep your previous copy and paste workflow and to alter Mp3tag to adapt to that.
I am glad that I hardly ever have to use copy and paste with Mp3tag. Its capabilities allow me to achieve my tagging goals by other means. And I feel that those means are easier, more efficient, and less prone to error.
So I think that we will just have to disagree on that.
I leave you with a final thought: if your copy and paste ideas are so desirable, why is it that they have never been implemented, after all these years? Perhaps the reason is that they are simply not needed by most users. It's all a matter of workflow.
No, completely not! Nothing to do with the extended tag editor.
I take it you have never pasted information from (say) a table in a document to cells in a spreadsheet? If you prepare a plain text file like this ("[TAB]" and "[CR]" are just place-holders for actual tab and CR characters):
...then copy it and paste it into a spreadsheet cell (eg) B6, the result would be "String1" pasted into B6, "String2" pasted into C6, "String3" into D6, then "String4" into B7, and "String5" into C7.
What I'm saying is that, in MP3Tag, with a listing of (say) filename, genre, tempo, artist, title, pasting the above into the tempo tag in file 3 would update tempo, artist, and title tags for file 3 and temp and artist for file 4.
I'm making a purely visual association between the separate tab-delimited items in the paste and where they end up, no need to specify at all.
This is the part that I think has caused others to question the suggestion that this feature request is any faster than the copy/paste you are already doing. If you already have your disc ripped you can have the files open in mp3tag. At that point, as fast as you can copy from any one source you can paste to the destination file and field in mp3tag. Common fields like Album or AlbumArtist can quickly be done for all files at once by selecting them all and pasting the data into the tag panel while the individual title (and perhaps Artist for compilations) would need to be done track by track.
I too struggle to understand how this can take any more time than pasting pieces arbitrarily into whatever plain text, document, or spreadsheet editor you are using, and then spending time there to organize this information into a consistent format that can then be used to copy/paste or import into mp3tag.
I get that this is your current workflow and your idea has been vetted well. But it isn't going to get anywhere further to posture it's value without the dev's consideration.
And yes I too have many outlier discs that didn't come up with any data from online sources, or some that did were so wrong the info wasn't worth using. These are usually rare cases, and need manual input. That's just the nature of the beast with online info. But the amount of time it takes for 10-15 tracks on each of these discs is hardly worth making wholesale changes to an app. Just enter the data and move on.
Not so, because it is a lot quicker to grab the whole content from source than go through it selecting dribs and drabs. Once it is in a text editor, it can be formatted as a whole. It's just the ability to paste as a whole which is missing.
I agree, and I do (where the data is consistent across multiple tracks).
That is indeed what I have to do.
The suggestion for a new feature is just that: a suggestion for consideration if the developers feel inclined. All this "why would you want to do that" or "there are other ways", because the various commenters personally have no use-case, is irrelevant. It's not like I'm new to MP3Tag and just asking out of the blue, I do use the existing facilities... this block paste is something which would be genuinely useful to me, and if me then presumably others too.
Frankly I am exasperated people dive in to criticise rather than support an idea. Discuss the technical difficulties of implementation by all means, but it seems counterproductive to just diss it.
If I'm understanding correctly, you'd have something like the following.
You would have your various headers - ALBUM, ARTIST, TRACK, TITLE, etc. Then the corresponding values are entered below. Your mp3tag columns would match your source columns from left to right. You would load the group of files into mp3tag and if necessary, sort them to match the data source. After selecting and copying the data from your source, you would then select the top left-most file in mp3tag, and paste. This would write the data to a group of "cells" that match the source data, and (presumably) any other fields would be ignored /left as-is.
Is that accurate?
I'm pretty sure Foobar2000 can do this or something very similar using its tools - import from clipboard feature. Not at home right now so I can't verify though. I don't think it's visually represented, either. Might be worth reviewing. Or maybe it's just a variation on suggestions made above that don't meet the need. Free to try though!
Off topic:
Take it as a compliment that your idea is being dissected so thoroughly - if it was fully understood and deemed solved or otherwise useless, the participation rate of this thread would be lower.
Not to say I don't understand where you are coming from - you have an idea, you want to share it, but it feels like others may not agree. I believe the responses you're getting are really about clarification as opposed to pushback. Again, I get that it may not feel that way.
Also, be aware that some of the forum members here may not speak English as their first language, even if they are fluent enough that that fact isn't evident. I don't say that to criticize anything you've said, but to try to bridge the gap between your efforts to articulate your suggestion and the responses you get. Much as you are doing the best you can, so are they.
You could enlighten us and describe your use-case in detail esp. the need to accumulate the data in an external program instead of directly in MP3tag.
Just some further thinking:
So far it is not possible in MP3tag to select a single cell as "cell". As soon as you click on a cell it changes to edit mode.
If you want to select a range of files, then it currently only possible to select the whole line but not a section of fields.
Unclear to me is also the behaviour if the area from the source does not match the selected area in MP3tag (if that would be possible after implementation).
If the MP3tag area is smaller, should there be an error message to force the user to adapt either source or target? Should the data simply be inserted into the selected area and everything that does not fit be discarded?
If the MP3tag area is larger than the source should data be repeated or the extra "cells" be left untouched?
If the source has empty cells should existing contents in MP3tag be left as it is or should it be deleted?
What I would like to point out: getting the block handling right require a lot more than just a modification of the selection method.
So I think it would only be fair to describe under which circumstances the new way has such striking advantages to be worth the effort.
