vgmrips

I've been looking into VGM and I quite like the format, but there are some things I don't know about the format yet regarding tags. I really like to tag my music thoroughly and players like foobar currently support custom tags for most emulated formats outside of VGM. However, upon further inspection, it seems that foobar adds these tags by simply attaching an APETAG spec to the end of the file format. This leads me to the VGM format -- it doesn't currently support APETAG with Foobar, so data like replaygain is stored only on the database. I also like to use tags to categorize my music by moods, so I also lose my ability to bake tags such as that into the file format.

So my question is this: Are there any plans to expand tag support for VGM to allow for custom tags? Additionally, would it be possible to use something like APETAG in order to add extra metadata to a given VGM format without breaking for the format specifications? It seems like it would currently be hard to expand the tagging data due to the layout of the binary format, so I'm assuming that additional metadata tags would need to be addressed with a different system.

I'm in absolutely the same boat (see thread), I use foobar2000 quite intensively and rely on most of the standard ID3 fields, for instance I use hashtags in the genre field, which I then use for autoplaylists queries. VGM is a great format in most ways, certainly much more helpful than other chip formats with regards metadata, but unfortunately it still isn't ideal. I even looked into using the foo_run component to initialise vgm_tag.exe on the target file... I can say that it works, but it isn't straightforward, and I imagine you still wouldn't be able to add genre, track/disc numbers, custom fields etc.

EDIT: one other option you could try (and I am investigating at the moment) is using the foo_tags component - it simply writes metadata to a separate file, and can contain whatever tag information you want. I am seriously considering this option for VGM and various tracker formats, but it does introduce new problems (for example, redundant media library entries.)

_________________
http://iridescentaudio.co.uk

Sorry for the double-post, but I think I've found a solution for us. If you are going to use a third party component, you are likely better off NOT using the M-Tags component and rather using the External Tags component instead: http://www.foobar2000.org/components/vi ... ernal_tags. I will explain why & the difference between the two as best as I've understood it.

M-Tags: The way this works is a little idiosyncratic, initially you select the M-Tags menu option in foobar2000, which opens a browse-to-directory prompt, and it generates .tags file(s) for all files in a selected directory (not always what you want.) The TAGS files can then be opened just like any music format. The tags are stored in plain text format, which has some obvious advantages, but one of the biggest drawbacks is that your media library will likely pick up duplicate media library entries for the source format and the TAGS files (meaning you'd have to nuke the tag information out of VGMs as well, so that you don't have two of everything.) Also, for some formats like MIDI, it changes the reported Codec information to "TAGS" which is not helpful at all.

External Tags: This component works more like you'd expect, and in a more transparent way. There's an "edit external tags" menu option added under the Tagging menu for selected files. It then creates .tag file(s) which are stored in APEV2 format, which I believe is what you wanted. You won't have separate media library entries for your tags, which IMO is a huge plus over M-Tags. Nothing really changes about your library other than that you can magically tag things you couldn't tag before, so long as you remember to do it the correct way.

Ultimately a more robust VGM format is always welcome but I am glad that this is at least a half-way feasible solution.

_________________
http://iridescentaudio.co.uk

Yes, external tags will probably work for now. Also, using an automated database backup for foobar also keeps VGM metadata that you've assigned. I would definitely like this to be supported at some point by VGM proper, though.

Absolutely, it would save quite a few headaches.



I'm actually not a great fan of foobar2000's internal storage of metadata, precisely because of the complications it introduces into the backup strategy. I'd like to turn that feature off now that I no longer have a use for it (afaik), though I imagine it isn't possible. The DB doesn't seem to work for Genre and other fields in VGM format anyway, for some reason, so I would still have to use foo_external_tags. I might set up an automated backup of the DB to Dropbox anyway, for peace of mind.

The other problem that feature causes is that I often accidentally edit tags on a VGM, MOD, MID etc. the standard way, rather than using the "Edit External Tags" option. In older versions of fb2k you would get bombed out if you tried to do this, which is now actually what I want. Usually I notice immediately when I've made this mistake and delete the tags back out, but not always... I simply don't like the thought of volatile tag info that is hidden away out of sight. I think those DB tags are very sensitive to file path as well. Still, at least we're having fun.

_________________
http://iridescentaudio.co.uk

Vgm players should be able to handle "junk" (not in the literal sense of the word) at the end of files, so any custom tag format that just puts the tag info at the end of the file should not interfere with vgmplay.

Though, once again, we at vgmrips don't maintain the fb2k plugin, it's done by some Japanese dude, so there's nothing that can be done from our side to enable custom tag support.

Good to know about the junk data at the end of VGM being supported. I know that foobar doesn't support extra tags that way, but it may mean I can patch Clementine to optionally add Apetag data to the end of the file for unsupported metadata entries. (Though playback currently isn't really great on that without manually overwriting libgme installations with Kode54s more recent install.)