m-TAGS component (foo_tags)

2012-09-24 03:51:08

m-TAGS (foo_tags)

I created this for my own use. I am sharing it because if I have a need for it, maybe someone else does too....

The m-TAGS format offers a simple yet powerful solution to the media-metadata separation problem, which impacts the efficience of digital music collections and media distribution services alike. An m-TAGS file is media-independent. It just contains metadata (tags) describing a certain media source and a locator which identifies the source to which the metadata applies.

The format of an m-TAGS file is very simple. Each tag is represented by a pair "<tag name>" : "<tag value>", with the special "@" tag containing the location of the media resource. This format allows the defininion of any tag name and the assignment of any value to a tag. Support for multivalued tags is included, as well as for multi-part media indexing.

For a first "taste" of how the m-TAGS mechanism works, select File / m-TAGS / Create m-TAGS (in same folder) from the main menu. Then browse to a folder where you have some audio files and press OK.

A new file will be created in your folder, named !.tags. If you open this file with any text editor, you will see that it contains the metadata of your audio files in plain text. You can edit the metadata directly if you wish.

If you drop the file into a foobar2000 playlist, it looks like your audio files are loaded into the playlist, just as if you had dropped a playlist file. However, if you look at the properties of the playlist entries, you will notice that the !.tags file was loaded instead.

Your audio files will play normally, but any changes to the metadata will be reflected in the !.tags file, and NOT in the audio files. As long as you use m-TAGS files to load your music into foobar2000, your audio files will play normally, but they never be touched by foobar2000. They will be treated as "read-only" audio sources. Even the replaygain tags will be read and written from / to the !.tags file.

Note: keep in mind that also all move / copy / delete file operations will be performed on the m-TAGS files!

Notes (mostly generated by feedback):

1. The component will generate UTF-8 files. It will still be able to read non-UTF-8 files.

2. You can change the default name for multi-reference m-TAGS file from "!" to another name (Preferences / Advanced / Tagging / m-TAGS / m-TAGS creator).

3. There is an option to always write all tags for each media source, without implementing the "cascading" optimization. It may simplify scripting on m-TAGS files (Preferences / Advanced / Tagging / m-TAGS / m-TAGS creator).

4. there is a command line option to create m-TAGS files "in-place" given a certain folder. It behaves exactly as if the provided folder had been selected using "File / m-TAGS / Create m-TAGS (in same folder)". The syntax is:

If you know how to create a shell context-menu script, then you can use the above command to "m-TAG" on the fly a folder and all subdirs from within Windows Explorer. Obviously, fb2k will start if it is not open. However, if you use

1) you can now write the tags from an m-TAGS file back to the media files;2) m-TAGS will not attempt anymore to automatically load technical information from remote media files (i.e. URI's);3) a new predefined tag "DURATION" allows to specify the duration of a track when technical information is not automatically loaded (it is ignored otherwise);4) a new advanced setting option was added for the m-TAGS creator to retain media file extensions (i.e. scanning "track.mp3" will generate a "track.mp3.tags" file, rather than a "track.tags" file).

1) m-TAGS files now encapsulate album art data. They reflect album art data present in the media file, and allow editing of the album art, but, abiding to m-TAGS philosophy, the album art is NOT inserted/removed into the media file until explicitely requested via the Tagging/Write m-TAGS to media files menu command. Album art is kept in binary files located in the folder where the m-TAGS file is.

2) "Pure" m-TAGS files are now supported. These are files without locators. They do not encapsulate any playable media, but they can be used by other input components to store metadata without having to write a specialized mechanism. All metadata i/o (including album art data i/o) can be deferred to the m-TAGS component. An instance of the input component may be obtained by simply calling input_entry::g_open_for_info_read(p_info_read_instance, NULL, <path to m-TAGS file>, p_abort) or input_entry::g_open_for_info_write(p_info_write_instance, NULL, <path to m-TAGS file>, p_abort).

The extension for a pure m-TAGS file is ".mtags". Note that you must obtain an m-TAGS input instance to load/save tags from/into an ".mtags" file using fb2k's SDK, because these files will NOT be recognized as media files (as they are not, indeed media files, nor files encapsulating media). As such, they will be trated in a playlist context just like any other non-recognized file.

When you use fb2k SDK calls, you MUST append an asterisk to the file path, because the pseudo-extension ".mtags*" IS recognized by the m-TAGS input component, while ".mtags" IS NOT (as previously explained). For example, if you want to store your metadata in a file named "C:/Music/My Album/album.mtags" then you can obtain an m-TAGS I/O instance by calling input_entry::g_open_for_info_write(p_info_write_instance, NULL, "C:/Music/My Album/album.mtags*", p_abort).

Similarly, you can obtain an album art editor for the same file by calling album_art_editor::g_get_interface(p_album_art_editor, "C:/Music/My Album/album.mtags*").

3) Input instances and album art editors may be opened for files which do not exist yet. In such case, m-TAGS automatically creates an empty, single-tracked m-TAGS component, and the file is only created if tags are edited and committed. This way, there is no need to physically create a pure m-TAGS file until it is actually needed (i.e. until tags are edited by the user or tags are insterted by the calling input component and a commit requested).

This mechanism is expecially useful when writing input components which offer support for network URI's. Developers may concentrate on connection and decoding issues, leaving m-TAGS to carry out metadata and album art I/O operations on pure m-TAGS files stored in a designated folder. These files could be indexed so that if a network URI is loaded again, the metadata is automatically loaded.

m-TAGS component (foo_tags)

I tried it, and it crashed foobar without crash dump (latest foobar on XP up to date)First crash was when I hit Cancel on opened dialog to browse for mtag location, and second time when I tried to access command from context menu. No third time, I removed it.

What I noticed in this small interval, is that it asks user to browse for location to save this mtag file, while I expected that this file should be placed in same folder as audio file(s) itself.For me this is annoying in the same way as foobar' own cover embedding, when user has to browse for location and items source folder isn't considered - that's why I never use it.

m-TAGS component (foo_tags)

I tried it, and it crashed foobar without crash dump (latest foobar on XP up to date)First crash was when I hit Cancel on opened dialog to browse for mtag location, and second time when I tried to access command from context menu. No third time, I removed it.

What I noticed in this small interval, is that it asks user to browse for location to save this mtag file, while I expected that this file should be placed in same folder as audio file(s) itself.For me this is annoying in the same way as foobar' own cover embedding, when user has to browse for location and items source folder isn't considered - that's why I never use it.

romor:

Thanks for taking the time to tell me about the crash.

When did you download the component? I had a name clash problem and I substituted the DLL last Saturday. It should (hopefully) work now: http://m-tags.org/foo_tags,dll.

If it still crashes (or if you'd rather not bother reinstalling it), then would you please be kind enough to let me know what components do you have installed? My "name clash" issue still produced crash reports, so the problem you experience may be a different one, after all.

-------------------

As for the file location, you can choose it to be the same one where the audio files are. In fact, this is how I use it myself, and that is why I created a menu item "Create m-TAGS (in same folder)" to do just that. The location you have to browse for is the location of the audio files. If you select the root folder where all your files are, then it will create m-TAGS files in all the subfolders where it finds audio files, i.e. you can "m-tag" your whole library "in-place" in one shot. Note that if you do that, then you should also change "Preferences / Shell Intagration / Restrict incoming files to" to "*.tags" (again, that is what I do myself). Otherwise if you drop a folder in foobar2000, then both the m-TAGS file(s) and the original media files will be loaded (i.e. all your files will be duplicated). This does not happen, of course if you choose a separate folder as the location of the m-TAGS files.

The reason that it asks you to choose a folder in the context menu is that in general you can select files from your playlist that are located in different folders. If they are all in the same folder, then you just have to select that folder.

m-TAGS component (foo_tags)

That is the version I've tried, I downloaded it couple of minutes before reporting. It's bit exact with current link you postedDon't know, but usually foobar catches the crash and creates dump. In both cases I experienced crash, crash files are created but empty.I'll PM you my component list.

---Great to learn about avoiding browse dialog, I guess I didn't have enough time to see everything Thanks

m-TAGS component (foo_tags)

This might be what I need. So this mod does not add any tags to the audio file at all? I needed a way to tag audio files but still continue seeding them to others.

I do not understand what you mean when you say "seeding them to others", so I do not know if you can accomplish that.

It's a reference to online file sharing via BitTorrent, where you offer, or "seed", files to other users via a peer to peer network. This tool will save file sharers from having to create copies of their (likely ill-begotten) gains for tagging.

m-TAGS component (foo_tags)

It's a reference to online file sharing via BitTorrent, where you offer, or "seed", files to other users via a peer to peer network. This tool will save file sharers from having to create copies of their (likely ill-begotten) gains for tagging.

Yes, you can do that, although... you shouldn't !!!

As long you use m-TAGS, foobar2000 will leave the files alone when you change tags. Playback will work as usual.

m-TAGS component (foo_tags)

- The sorting in EsPlaylist is very strange (using: %album% %date%. Sort incoming files: %path%).- The !.tags-file only list the first track with ALBUM. I guess it only shows if a track differs from a tag, (to keep it smaller and more efficient, maybe?)

Found that Waveform Seekbar didn't displayed the waveform (with analyze tracks not in media library disabled). Adding !.tags in Restrict to under File types in Media Library solved it.

m-TAGS component (foo_tags)

It's a reference to online file sharing via BitTorrent, where you offer, or "seed", files to other users via a peer to peer network. This tool will save file sharers from having to create copies of their (likely ill-begotten) gains for tagging.

BitTorrent can be and is used to distribute music legally (e.g. etree.org) just as Foobar2000 is used to play and organize music regardless of the source. Both are tools that can be used as the user sees fit.

m-TAGS component (foo_tags)

This is a great concept, and one that I'd love to implement for my own collection.

One problem comes to mind immediately: no portable MP3 player currently supports this kind of tagging, so to really be useful to anyone with one of these devices, there'd have to be some kind of on-the-fly writing of ID3/whatever tags to files transferred to the player, the same way that lossless files are often transcoded to MP3 on the fly when transferring to a portable device that can't handle lossless codecs.

m-TAGS component (foo_tags)

It's a reference to online file sharing via BitTorrent, where you offer, or "seed", files to other users via a peer to peer network. This tool will save file sharers from having to create copies of their (likely ill-begotten) gains for tagging.

BitTorrent can be and is used to distribute music legally (e.g. etree.org) just as Foobar2000 is used to play and organize music regardless of the source. Both are tools that can be used as the user sees fit.

I'm not blaming the protocol for its users, but I wanted to make sure that the most common use of it didn't go unmentioned.

m-TAGS component (foo_tags)

It's a reference to online file sharing via BitTorrent, where you offer, or "seed", files to other users via a peer to peer network. This tool will save file sharers from having to create copies of their (likely ill-begotten) gains for tagging.

BitTorrent can be and is used to distribute music legally (e.g. etree.org) just as Foobar2000 is used to play and organize music regardless of the source. Both are tools that can be used as the user sees fit.

m-TAGS component (foo_tags)

- The sorting in EsPlaylist is very strange (using: %album% %date%. Sort incoming files: %path%).- The !.tags-file only list the first track with ALBUM. I guess it only shows if a track differs from a tag, (to keep it smaller and more efficient, maybe?)

Found that Waveform Seekbar didn't displayed the waveform (with analyze tracks not in media library disabled). Adding !.tags in Restrict to under File types in Media Library solved it.

Andreas:

- I cannot be too specific about the esPlaylist issue, because I do not know what you mean for "strange". But maybe the following will help.

By default, m-tags generates ONE m-tags file per folder, and foobar2000 treats that as a multitrack file (with subindexes for each track). If you sort by %path%, your results may be "weird" because the %path% does not contain the track index. That is why it is recommended to always sort by %path_sort% (which understands indexes) rather than by %path% in foobar2000. If this is the problem, as I suspect, then you may avoid it either by changing the sorting rule from %path% to %path_sort%, or by cheking the option "Preferences / Advanced / Tagging / m-TAGS / Create a separate m-TAGS file for each source file". This way, rather than seeing a "!.tags" file, you should end up with one ".tags" file per audio file.

- You are right about your observation. The m-TAGS file obeys the following rule:

m-TAGS component (foo_tags)

This is a great concept, and one that I'd love to implement for my own collection.

One problem comes to mind immediately: no portable MP3 player currently supports this kind of tagging, so to really be useful to anyone with one of these devices, there'd have to be some kind of on-the-fly writing of ID3/whatever tags to files transferred to the player, the same way that lossless files are often transcoded to MP3 on the fly when transferring to a portable device that can't handle lossless codecs.

If you transcode your files before copying them onto the portable device, then you do not have a problem, because if you transcode a file loaded into foobar2000 via an m-TAGS file, then the transcoded (output) file will indeed contain the same tag values present in the m-TAGS file.

If you do NOT transcode, then you will have to copy the tags back into the media files. With foobar2000 you can do that by simply copying and pasting the tags from and to the respective "Metadata" tabs of the "Properties" window. You can also do it in batch (all-at-once).

m-TAGS component (foo_tags)

Very promising plugin but it has issues with folders with names containing letters with diacritical marks or punctuation.

If said folder is opened as the source folder using File > m-TAGS > Create m-TAGS (in same folder), it will fail. (Interestingly, if you open a folder as source without diacritics in its name but containing subfolders that do have them, it works).

If said folder is opened as the source folder using File > m-TAGS > Create m-TAGS (in separate folder), it will fail to create a file but will create a destination folder with a name cut off at where it encounters diacritics or punctuation. (Unfortunately, I could only delete the folders using an elevated command prompt I believe this may have been caused by selecting a destination folder which had diacritics in its name. I'm not really interested in trying to re-create this).

If contents of said folder are selected in a playlist by clicking on a Grouping or by selecting them, using right-click Tagging > Create m-TAGS file resulted in a file containing all tracks, all of which loaded and played in foobar if I selected a destination folder which didn't contain diacritics or punctuation in its name (Oddly however, it seems to cause foobar to immediately add the tags file to the library. I have to investigate this further to be sure). Selecting the contents folder as the destination folder results in failure to create a file but will create a destination folder (again with a name cut off at where it encounters diacritics or punctuation) in the parent folder (Luckily I was able to simply delete the folders).

Other things I noticed:

Using right-click Tagging > Create m-TAGS file in Album List Panel has varying degrees of success. Selecting various parent nodes usually resulted in 1) creation of a file containing all tracks of which either only the first album/folder or random tracks from various albums/folders loaded in foobar 2) creation of a file which either did not contain all tracks or did not contain all albums/folders 3) failure to create a file.

Selecting a parent Grouping (%album artist% in this case) in NG Playlist and using right-click Tagging > Create m-TAGS file resulted in a file that contained all tracks from all albums/folders, all of which loaded and played in foobar .

I'm not too familiar with foobar. Is the file path not accessible for use with File > m-TAGS > Create m-TAGS (in same folder)? I'm wondering why one has to set the source and destination with this option.

m-TAGS component (foo_tags)

It was due to the fact that I had removed the transcoding to UTF-8 of file paths selected through the main window (and that should also explain why diacritical marks were working in subdirs: they were still properly transcoded to UTF-8). UTF-8 transcoding is back.....

Thanks for pointing out the Album List panel issue. I had never used the file creator within that panel. I confirm the odd behaviour and I will look into it.

I am not sure about your comment on the "limited accounts". If you have a limited account on the network, then I assume it is just right that you cannot access the network files. Maybe I am not understanding, though....

Regarding your final question: Yes the file path is accessible, but the "Create m-TAGS (in same folder)" does not use information on the playlist or album list. They may be all empty, at that. The "right click" version uses the paths. The main menu commands can create m-TAGS files from a folder, traversing all the subdirectories, whatever this folder is. You can select your C:\ folder and it will create m-TAGS files for ALL your media in the C disk. Again, I hope I understood the question!

m-TAGS component (foo_tags)

Using right-click Tagging > Create m-TAGS file in Album List Panel has varying degrees of success. Selecting various parent nodes usually resulted in 1) creation of a file containing all tracks of which either only the first album/folder or random tracks from various albums/folders loaded in foobar 2) creation of a file which either did not contain all tracks or did not contain all albums/folders 3) failure to create a file.

Ben:

It looks like foobar2000 does not like modeless operations when it comes to the album list handles. I changed the operation to modal (i.e. blocking) and it seems to work. The random results were due to f2k releasing the handle list before the operation was completed, with obvious random results.

m-TAGS component (foo_tags)

The network folders are accessible but not with your component via m-TAGS File menu entries. What I meant by "limited" account was someone using a Standard user account on their computer instead of an Administrator account. The dialog that opens when using m-TAGS File menu entries doesn't allow for choosing a source folder beyond the user account which renders them useless to a Standard user whose media is stored on the network. (Conversely, the dialog that opens when using m-TAGS right-click menu does allow one to select a destination folder on the network when using a Standard account).

m-TAGS component (foo_tags)

The network folders are accessible but not with your component via m-TAGS File menu entries. What I meant by "limited" account was someone using a Standard user account on their computer instead of an Administrator account. The dialog that opens when using m-TAGS File menu entries doesn't allow for choosing a source folder beyond the user account which renders them useless to a Standard user whose media is stored on the network. (Conversely, the dialog that opens when using m-TAGS right-click menu does allow one to select a destination folder on the network when using a Standard account).

Ben:

The main difference between the "context" operation and the "main menu" operations is that the first uses "GetSaveFileName" to browse for files, while the second uses "SHBrowseForFolder". It looks like something that works in the first does not work in the second. I am not a Windows networking super-expert, so you may know better than me. I played a bit with the BROWSEINFO flags used by SHBrowseForFolder and I changed them to "BIF_SHAREABLE | BIF_NEWDIALOGSTYLE | BIF_NONEWFOLDERBUTTON" (I had "BIF_RETURNONLYFSDIRS | BIF_NEWDIALOGSTYLE | BIF_NONEWFOLDERBUTTON"). Alas, I have no way to test the changes on my network (everything works on mine). If you know what I should change, or if you can test the DLL with the new flags (http://m-tags.org/foo_tags.dll), I will welcome your help and feedback.

m-TAGS component (foo_tags)

No, I still cannot access network folders on the NAS from a Standard account. My knowledge is rather limited. I'm sorry I cannot help you beyond testing. Someone may be able to help you with the problem if you posted an inquiry in the Development forum.

As for your python scripting demo, I find it very interesting. You point out that if the tags are in a single file, as opposed to "one-per-media-file", then things need to be approached differently. This is VERY MUCH the case, and it is because, by way of optimization, m-TAGS does not store all tag values for all entries, but "cascades" the values through the entries. This means that you would have to write a special algorithm to read the m-TAGS file.

I have the algorithm, of course. Let me know if you need it. But I wonder if I should add an option to create m-TAGS files WITHOUT cascading the values, for people who would like to take advantage of their JSON format for scripting. The inpact in space and loading time would probably be minimal anyway.