As the title says Will you be considering adding support for m-TAGS in a future release?
m-TAGS gets around so many issues with the difference in support for tags in media files that I'm almost totally switched over now. Which sadly leaves me FB2K as only option to add/change/update tags. Would love to keep using MP3Tag for it's added functionality, but it does not yet know how to handle these files.
You can apply the Mp3tag export feature and use the Mp3tag export scripting language to create a text file of the wanted output format JSON, having all tag data from within a media file, which Mp3tag is able to read and to display.
I don't want or need to create m-TAGS files as these are already created for me by my media player as JSON formatted text files. What it however is not so good as is mass tagging. Which is why I still use MP3Tag. And unless I understood you wrong but as far as I understand and have experienced. MP3Tag is not capable of reading and displaying such files.
So why would I go to all the bother of creating an export for files that already exist and for instance, to which I would like to add additional data from e.g. Discogs or MusicBrainz?
My wish is that MP3Tag would be able to read such files (like it does with CUE files) and add/update the information contained within...(which it can't do with CUE files)
Mp3tag is already able to read a CSV alike text file, and to fill tag-fields with data from the text file.
With some programming effort within some Mp3tag actions, one can also read data from any text file, and write data into tag-fields.
Within the websource section of Mp3tag the reading of JSON sources is already implemented.
The main site is hosted and the hosting service is not one of the best...keep trying, it'll come back up again. May be not that exact moment but it will after the owner notices it and complains again.
There is the forum topic where it is somewhat described, but does not contain any documentation about the functionality
What is your hangup with my wish? I'm no programmer, and I don't need it to read CSV alike text files, the m_TAG files are in JSON format which doesn't even resemble CSV in the slightest. I want it to natively support m-TAG files as if they were media files... the same way it handles CUE files...
Also, the whole purpose of using m-TAG is to separate the tag info from the media files, so having an option to read text files and write the info to tags completely negates the reason why m-TAG was created. The main reason being that it allows adding tag information for media files that have limited or no support for built-in tag information
Partly incorrect, a single m-TAG file can either describe a single media file or a collection of multiple media files, comparable to a cue sheet. and it is not intended as a backup but as the primary container for meta data. In other words, media files are treated as if they are read-only and meta data will never be written to actual media files unless explicitly instructed by the user.
Furthermore, it allows the use of metadata for media formats which either have limited or no support for mediadata themselves. For instance, a m-TAG file can describe a streaming source and allows to store meta data not contained within the stream. In effect, it forms a totally separate layer, allowing for much greater flexibility in describing media regardless of the capability to store said meta data within the media file itself.
Currently MP3tag seems to support the reading of a cue sheet with this difference that it then proceeds to read in the media files referenced by the cue sheet. Any changed value however seems to be directly written to the media files and not to the cue sheet (due to the limitations of cue sheets)
What I would like to see is that MP3tag reads the m-TAG files as if they were media files, without also loading in the referenced media files (as the primary entrance is the m-TAG file itself) and any changes made written back to the m-TAG file(s).
I am aware of the fact that this could possibly lead to confusion if both the m-TAG file(s) and media files are located in the same folder (which is not a requirement for m-TAG files as they can be located in a totally separate location) if the user does not also have a column showing the actual filenames, but I trust that if someone uses m-TAG they will be aware of this fact and capable of using MP3tag's filter option to limit the view to the entries provided by the m-TAG file(s)
Any indication if there is a chance this functionality will get added some day in the future?
m-TAGS forms an additional layer between tagging application and media files, causing said media files to be effectively treated as read-only. m-TAGS stores/maintains any and all tag information in either a single file for all media files in a folder or a separate file for each media file without ever touching the media files themselves. Thus offering the same, wide range of tagging options for every type of media file (even in cases where those files are not capable of embedding said information.)
If you check the other suggestions in this forum you might see that you hardly ever get any feedback on the planned developments.
What you do get are hints on how to solve, in the meantime, possible problems that might have lead to the suggestion with the means of MP3tag and/or the help of other programs.