vgmstream M3U tagging ideas by bnnm at 7:38 PM EDT on August 13, 2017
While doing experiments I realized it's possible to trick foobar/winamp M3U to add tags without having to rewrite tons.
Basically checks are lax, so we can "encode" tags into a fake filename, and vgmstream could catch and interpret.
Format could be like: (rel/abs filename)(separator)(tag)(sep)(tag)(sep)...(ext). Ex: song.fsb | $title$=Uneternalessness Engrish|$artist=Sakuraba| %album% = Awesome |.fsb
When the player asks to open that "file", vgmstream divides it into actual filename + tags and nobody notices.
Other details: - exact tag format TBD - no global tags (as vgmstream only gets single filenames, doesn't read M3U). - separators preferably Windows non-file chars (? | *, but not : // as they mark protocol = no relative filenames) - last ext may be required, but any would do (= force exts into vgmstream). - tags could be commands too. Like "$s=3"=play stream #3, "$i"=disable looping, "$f"=force looping, etc. - XMPlay won't work as seems it checks if files exist. But maybe the author could add an option to disable that? - unicode/utf8 to be tested
Remember that for players like foobar2000, the M3U files would need to be parsed by VGMStream itself, and loaded in the background, as the player itself does not support M3U extensions, it merely loads a list of files from them and adds them to the player, discarding any comments and relying entirely on the supporting inputs to read tags.
Well, I tested it and seemed to work fine without any M3U mod, as this is still within the specification (='non-validated lines of any text resembling a filename').
foobar's M3U passes to ::g_is_our_path and ::open the 'full' fake filename ("file://c:\\" + "song.fsb|whatever you want here.fsb"), no checks done. You can then find_pos "|" and truncate the p_path, and continue internally with the actual filename + rest (=tags). Maybe has some side effects like the file_stats stuff?
I very much like the whole idea of m3u files as it allows for separating tagging from sound data, the former being way more volatile than the latter. As m3u is text based such files could then be managed and hosted using distributed version control (like on github) or using a centralized database (similar to e.g. vgmdb).
Then the last step to paradise would be automatically fetching the m3u files based on the set. ;o)