Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: m-TAGS component (foo_tags) (Read 160693 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: m-TAGS component (foo_tags)

Reply #300
My PSF decoders ignore the volume tag and read and write ReplayGain tags instead.
Yeah, was about to edit my post earlier as I didn't actually see any volume tag in the source code after all. I guess I naturally assumed since it's part of the original PSF spec.

And you can't expect an external database to override them, as they're read directly from the files every time you play them.
That's basically what I was thinking. Too bad.

Re: m-TAGS component (foo_tags)

Reply #301
Technically, I could make it read the tags, but that would require a direct interface to m-TAGS, as last time I was discussing it with Peter almost a decade ago, invoking the metadb to read your own tags from the core is kind of a no-no from decoders, as invoking the tag read call may trigger a new instance of your plug-in to read the tags from the file first. Which I suppose is fine if you have no race conditions, and don't mind the file being opened and read from multiple places simultaneously, or being read multiple times redundantly.

So, maybe point me at an API can call for tag info, and I may consider implementing it into all of my synthesizer plugins, but I'll only allow overriding simple things like the track length and fade duration, not anything that affects the actual emulation. For instance, half of the _tags that apply to USF files, the files could cause the plug-in to lock up the player if they're missing or misused.

Re: m-TAGS component (foo_tags)

Reply #302
As much as I appreciate the effort, I think I'd rather you didn't turn your component into something unnecessarily complex. Having a component interacting with another just sounds like a generally bad idea to me, and I'm personally more into portability and compatibility than convenience. If m-TAGS should change something that would affect your interface at some point, that just creates all the more problems.

Re: m-TAGS component (foo_tags)

Reply #303
Hi, is it possible to reference to a file different from location?
For instance have it point to a file based on a checksum or with the use of foo_biometric?
That would ensure that moving files wouldn't interfere with the mtags.
<3 f00

Re: m-TAGS component (foo_tags)

Reply #304
I've been using this plug-in for a while now.  I wanted to be able to add rating tags to music without changing the music files.  This does exactly what I wanted to do.  There is one feature that would really make it perfect for me.

I keep files that I have in lossless format in a separate directory structure from files that I only have in lossy format.  The two directory structures are identical.  When I acquire something in lossless format that I previously only had in lossy format the new files go into the lossless tree and the lossy only files and corresponding directories get deleted from the lossy only tree.  It would be great if I could just run the create m-Tags process and have the lossy only files removed.  It would be even cooler if the tags from the lossy only !,m-Tags that were not in the source files could be copied to the lossless !.m-Tags version.  Ideally, if deleting the file creates an empty directory the directory would also be deleted.

Thanks for this great plug-in!

Re: m-TAGS component (foo_tags)

Reply #305
Hey there. What a great component this is - so useful for syncing tag updates across multiple PCs, rather than having to copy megabytes of files. It has made managing my library so much easier. 8)

Just one thing (maybe mentioned already)... My layout uses %filesize_natural% in a couple places - which of course now display 2.4 KB instead of the actual 36 MB or so of each file. I guess there is no way around this behavior?

Cheers <3

Re: m-TAGS component (foo_tags)

Reply #306
I think m-TAGS is something that would need to be directly supported by foobar2000 for full compatibility with all other components.

Re: m-TAGS component (foo_tags)

Reply #307
«Failed to load DLL: foo_tags.dll
Reason: Unknown error code (3221225501)»

win xp x32 sp3, athlon xp (non-sse2 cpu)
QC, QA

Re: m-TAGS component (foo_tags)

Reply #308
«Failed to load DLL: foo_tags.dll
Reason: Unknown error code (3221225501)»

win xp x32 sp3, athlon xp (non-sse2 cpu)
0xC000001D (Illegal Instruction)

That'd probably be building with MSVC 2015 with the default SSE2 instruction support.

Re: m-TAGS component (foo_tags)

Reply #309
I think there should be option to add m-TAGS files for selected songs in playlist in the same folder as files when you right click on selected songs in playlist.
You can "right click -> Tagging -> Create m-TAGS files" but then you have to navigate to wanted folder.
This way it would be much faster.

Re: m-TAGS component (foo_tags)

Reply #310
Bug report?
I have several m-TAGS linked to music on another drive, files on D: and tags on E:. However certain .tags would fail to play the first track (returning decoding failure; unsupported format error), if another track (e.g. second or fifth track) from the same .tags file gets played first. Only if the first track gets played first, it would play just fine. However as soon as the playback advances or changes to next track of the same .tags file, playing the first track again will fail as well. This happens with many .tags files, but not all of them. I've double-checked maximum path limit on them, and they're below 200 chars. No special characters either. No weird/faulty tags. What do you think seems to be the cause?

You can check these console logs. I reproduced the bug by playing the first track, then second track, then back to first track on each .tags file. The first two .tags doesn't have this problem, and the last two does. Since the first track failed to play on the last two .tags, playback automatically advances to the second track, which the logs should record.

Here I attached two logs, one with verbose logging enabled and one without. I also attached the working and faulty .tags files, two of each respectively. Thanks in advance, and thanks again for the great component!

Re: m-TAGS component (foo_tags)

Reply #311
Hello!

I have a problem with streams. Tags are not displayed dynamically. They are fixed by. that are written in the m-tag file. Is it possible to show the values from the file when the stream is not running and display tags from stream when it is launched?

Re: m-TAGS component (foo_tags)

Reply #312
I think there should be option to add m-TAGS files for selected songs in playlist in the same folder as files when you right click on selected songs in playlist.
You can "right click -> Tagging -> Create m-TAGS files" but then you have to navigate to wanted folder.
This way it would be much faster.
Agreed. This is the reason I came here to ask.

When I right-click the playlist to save m-tags, I always want to save in the same folder as the music files. I do this very frequently, so it would be nice if you could avoid navigating the folders.

Re: m-TAGS component (foo_tags)

Reply #313
Bug report?
I have several m-TAGS linked to music on another drive, files on D: and tags on E:. However certain .tags would fail to play the first track (returning decoding failure; unsupported format error), if another track (e.g. second or fifth track) from the same .tags file gets played first. Only if the first track gets played first, it would play just fine. However as soon as the playback advances or changes to next track of the same .tags file, playing the first track again will fail as well. This happens with many .tags files, but not all of them. I've double-checked maximum path limit on them, and they're below 200 chars. No special characters either. No weird/faulty tags. What do you think seems to be the cause?

You can check these console logs. I reproduced the bug by playing the first track, then second track, then back to first track on each .tags file. The first two .tags doesn't have this problem, and the last two does. Since the first track failed to play on the last two .tags, playback automatically advances to the second track, which the logs should record.

Here I attached two logs, one with verbose logging enabled and one without. I also attached the working and faulty .tags files, two of each respectively. Thanks in advance, and thanks again for the great component!

This has been fixed by deleting all album art encapsulation in every single folder of where my .tags files are residing. I just type "del *.bin /s" on command prompt of my folder.

Re: m-TAGS component (foo_tags)

Reply #314
I think there should be option to add m-TAGS files for selected songs in playlist in the same folder as files when you right click on selected songs in playlist.
You can "right click -> Tagging -> Create m-TAGS files" but then you have to navigate to wanted folder.
This way it would be much faster.
Agreed. This is the reason I came here to ask.

When I right-click the playlist to save m-tags, I always want to save in the same folder as the music files. I do this very frequently, so it would be nice if you could avoid navigating the folders.


Oddly enough if you choose File -> m-TAGS you DO get the choice...  ???

Re: m-TAGS component (foo_tags)

Reply #315
I think there should be option to add m-TAGS files for selected songs in playlist in the same folder as files when you right click on selected songs in playlist.
You can "right click -> Tagging -> Create m-TAGS files" but then you have to navigate to wanted folder.
This way it would be much faster.
Agreed. This is the reason I came here to ask.

When I right-click the playlist to save m-tags, I always want to save in the same folder as the music files. I do this very frequently, so it would be nice if you could avoid navigating the folders.


Oddly enough if you choose File -> m-TAGS you DO get the choice...  ???

I realize I wasn't clear enough. I'll try again:

When I right-click the playlist to save m-tags, I want m-tags to presume that I want to save in the very same folder as the music files that I just right-clicked. This way I wouldn't have to browse/navigate to the folder.

As it is now, m-tags defaults to "Last used folder" or "My Documents", both of which seem unnatural to me.

Re: m-TAGS component (foo_tags)

Reply #316
Hi. Thanks for this app. It works the way I wanted it to.

Is it possible to somehow change or locate the music source? In case I move the music to a different location. Thanks.

Yes. the locator is editable as any other tag. Its name is "@". If you use scripts, then you can access it as "@" when writing, and as "$info(@)" when reading. For example, if you relocate an album to a different folder, you can use the the "Properties / Tools / Automatically fill values..." window like this:

Source: "Other..." / "$replace($info(@),'/<old folder>/','/<new folder>/')"
Pattern: @

After you click "OK" you will se the "@" tag listed among the tags. If you click "Apply", then the locators will be changed in the m-tags files.
 Of course you can do the same with masstagger, or you can "Add new filed..." manually in the properties window and manually edit the locator (Field name = @).

You could even display the "@" tag on the playlist (as a column on the Columns UI interface, for example) and edit it directly there. But I cannot frankly foresee that anyone would want the locator shown in the playlist! LOL

Needless to say, because an m-tags file is a text file, you can also directly edit the file or write an external script to change the locator ("@") tags.

I'd like to point out that @ alone for the pattern won't work when automatically filling values. Use %@%

Re: m-TAGS component (foo_tags)

Reply #317
Bug report?
I have several m-TAGS linked to music on another drive, files on D: and tags on E:. However certain .tags would fail to play the first track (returning decoding failure; unsupported format error), if another track (e.g. second or fifth track) from the same .tags file gets played first. Only if the first track gets played first, it would play just fine. However as soon as the playback advances or changes to next track of the same .tags file, playing the first track again will fail as well. This happens with many .tags files, but not all of them. I've double-checked maximum path limit on them, and they're below 200 chars. No special characters either. No weird/faulty tags. What do you think seems to be the cause?

You can check these console logs. I reproduced the bug by playing the first track, then second track, then back to first track on each .tags file. The first two .tags doesn't have this problem, and the last two does. Since the first track failed to play on the last two .tags, playback automatically advances to the second track, which the logs should record.

Here I attached two logs, one with verbose logging enabled and one without. I also attached the working and faulty .tags files, two of each respectively. Thanks in advance, and thanks again for the great component!

This has been fixed by deleting all album art encapsulation in every single folder of where my .tags files are residing. I just type "del *.bin /s" on command prompt of my folder.

I will have to look into it. The album art addition was  VERY RELUCTANTLY made following a specific request. That's because I knew it was prone to break, and also because of the necessity to use those hideous ".bin" files.

The proper way to embed artwork in m-TAGS is to have tags containing the paths (or, more generally, the URL's) to the images. Then reference those tags within the the art viewers' lists of sources. And I would be happy to provide special treatment for such a solution (i.e. providing automatic resolution of cover references, just like it's done with the locator "@").

Remember: embedded artwork == duplicated artwork. Who needs that???

Unfortunately, this would NOT be compatible with fb2k's embedded artwork manager, and that was the main objective of the request.

Re: m-TAGS component (foo_tags)

Reply #318
I think there should be option to add m-TAGS files for selected songs in playlist in the same folder as files when you right click on selected songs in playlist.
You can "right click -> Tagging -> Create m-TAGS files" but then you have to navigate to wanted folder.
This way it would be much faster.
Agreed. This is the reason I came here to ask.

When I right-click the playlist to save m-tags, I always want to save in the same folder as the music files. I do this very frequently, so it would be nice if you could avoid navigating the folders.


Oddly enough if you choose File -> m-TAGS you DO get the choice...  ???

I realize I wasn't clear enough. I'll try again:

When I right-click the playlist to save m-tags, I want m-tags to presume that I want to save in the very same folder as the music files that I just right-clicked. This way I wouldn't have to browse/navigate to the folder.

As it is now, m-tags defaults to "Last used folder" or "My Documents", both of which seem unnatural to me.


The reason why the context menu does not offer to save "in the same folder" is that there is no guarantee whatsoever that all selected media resides in the same folder, nor, in fact, that the media is located in a writable folder, or that is even local.

That said.... I do agree that I could have been a little less of a lazy ass and check if indeed all the selected files ARE in the same folder and act accordingly. I will look into that, and I may add the feature... if it does not affect my lazy ass too much ;-)

I am still surprised at why people even use the context menu, though. It is so much easier to create m-TAGS via the main menu or a script. But any feedback belying my assumptions is very welcome (and could make my ass less lazy...).

Re: m-TAGS component (foo_tags)

Reply #319
Hello!

I have a problem with streams. Tags are not displayed dynamically. They are fixed by. that are written in the m-tag file. Is it possible to show the values from the file when the stream is not running and display tags from stream when it is launched?

Yes it is. I already responded to this, but, in order to save you time, here is how:

You have create a "shadow" set of tags. For example, if the TITLE metadata is subject to change dynamically, do NOT create an m-TAGS file with that tag. Rather, use something like DEFAULT_TITLE (it could be the station name). Then use $if2(%TITLE%,%DEFAULT_TITLE%) to display the dynamic information when available and the m-TAGS value when not. If you use ColumnsUI, for example, the above is what you would write in the Column/Display field. And don't forget to make DEFAULT_TITLE and not TITLE the Linked Meta Field for online editing!!!

Please note that dynamic technical tags (non-metadata tags, like dynamic bit rate, etc.) are always transparently relayed by m-TAGS.

Re: m-TAGS component (foo_tags)

Reply #320
Hey there. What a great component this is - so useful for syncing tag updates across multiple PCs, rather than having to copy megabytes of files. It has made managing my library so much easier. 8)

Just one thing (maybe mentioned already)... My layout uses %filesize_natural% in a couple places - which of course now display 2.4 KB instead of the actual 36 MB or so of each file. I guess there is no way around this behavior?

Cheers <3


There is a way, but I decided not to use it. It may be prone to break other components of fb2k. As far as fb2k is concerned, and in all of its inner workings, the m-TAGS file completely encapsulates the media. That is, for fb2k the m-TAGS file "IS" the media file. So, I present it with the m-TAGS file size and timestamp, and NOT the encapsulated media size and timestamp.fds

Admittedly... I could add a couple of generated tags, for those values, derived from @REFERENCED_FILE

Re: m-TAGS component (foo_tags)

Reply #321
Great to see you're back!

For some reason the m-TAGS properties (@,Referenced file,etc) won't show up anymore on the Properties window. I can still call them through title formatting though. I'm on latest version for both the component and foobar2000.

Also is it possible for the m-TAGS creator to allow title formatting for the "Folder-wide .tags name"? Something like %album%.tags would be better than !.tags I suppose :)

Re: m-TAGS component (foo_tags)

Reply #322
Glad to see this plugin is still alive and kicking. Still one of my favorite (and most used) fb2k plugins to date.

I ran into an interesting situation when writing tags for foo_youtube and foo_input_spotify sources.

Both these plugins have the ability to pass album / artist artwork and display them in the built-in fb2k artist / album artwork panels.

However, once I write the m-tag file for said files, the artist / album artwork data isn't passed along to the m-tags file.

I was wondering, is it possible to configure m-tags (via either built-in functionality or an external / custom script) to snatch the associated displayed artist / album artwork when creating m-tags?

Thanks again for the awesome plugin.

Re: m-TAGS component (foo_tags)

Reply #323
Can you please include option in foobar playlist (right click) to create m-tags file in same folder where selected files are (without asking where to put m-tags file)?
If all selected files are not in same directory that command should put m-tags file in latest path all selected files have in common.

I also found a bug when I try to convert files under m-tags "playlist" with attached cover art with m-tags (.bin file). This however doesn't happen when m-tags file is pointing to .cue file. Only when pointing to audio files whether they have cue sheet attached to them or not.
Error message says: An error occurred while transferring attached pictures (File is already in use)
What use? It says that every time.

Re: m-TAGS component (foo_tags)

Reply #324
Hi luigimercurio,

First of all, many thanks for the great component. fb2k+m-TAGS combination is really essential for me to organise my huge collection. Everything has worked nicely for me so far, until it comes to album art.

I have an m-TAGS file like below
Code: [Select]
[
    {
        "@" : "01. Track 1.mp3",
        "TITLE" : "Track 1",
        "TRACKNUMBER" : "1",
        "ALBUM" : "Some album",
        "ARTIST" : "Some artist",
        "DATE" : "2017"
    },
    {
        "@" : "02. Track 2.mp3",
        "TITLE" : "Track 2",
        "TRACKNUMBER" : "2"
    }
]
named as myalbum.tags stored in the same folder as *.mp3 files. I also have a JPEG file named myalbum.tags.icon.bin stored in the same folder. And I load the tag file to play in foobar2000. The music plays fine. I have an Album Art Viewer panel that I set to display Icon.

The problem is: when I double-click on Track 1 to play it, the icon image is shown. But when I select Track 2 (or any other track if the tag file contains more, Track 1 is still playing), [no image] is shown instead of the image in myalbum.tags.icon.bin. When I select back Track 1 (it is still playing), the album art doesn't appear again ( I guess same issue as Replies 249 here and 255-257 here). When I right-click on any track in the album (Track 1 is still playing) to open the Context Menu and choose Tagging > Manage attached pictures, I will get the error message Attached editing picture failure: File is already in use (same issue as Replies 230 here and 261 here, and probably 323 above).

I know you gave some explanation about the locking (here and here) but what I find strange is that if another track other than Track 1 is playing, I don't have any problem, everything works as I expect (album art shown on selecting any track in the album, and I can right-click to manage attached pictures). So the problem is really with the first track in the tag file. If fb2k locks file during playback, why does locking only happen to first track in the tag file, given that the actual media files are being played?

After realising that the album art problem only happens to the first track in the tag file, I thought of creating a dummy track
Code: [Select]
[{},
    {
        "@" : "01. Track 1.mp3",
        "TITLE" : "Track 1",
        "TRACKNUMBER" : "1",
        "ALBUM" : "Some album",
        "ARTIST" : "Some artist",
        "DATE" : "2017"
    },
    {
        "@" : "02. Track 2.mp3",
        "TITLE" : "Track 2",
        "TRACKNUMBER" : "2"
    }
]
This will of course add an unplayable dummy track to the playlist when loaded to the player. I can then remove this dummy track from the playlist and play all tracks as normal. But this is really annoying when I load many albums to the playlist at once. I use Edit > Remove dead items but it doesn't work.

Then I saw this suggestion (Reply 275) of hiding referred media inside the tag file. If such implementation is possible, I can hide my dummy first track. Any update on that?

You also mentioned "Pure" m-TAGS files. Could that be any help?

I wouldn't have any of the above problems if I could specify a path to my icon file. fb2k only allows path to Front, Back, Disc covers and Artist image, yet the Album Art Viewer panel can display 5, including Icon. In case you wonder why I have to use Icon, I resort to it as a solution to my problem on multiple front album covers here

Any idea to properly display Icon album art when playing media files via m-TAGS is much appreciated.