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: External Tags (Read 68168 times) previous topic - next topic
0 Members and 4 Guests are viewing this topic.

Re: External Tags

Reply #375
???  Now the tag edits are going to the file and not the db!
It's your privilege to disagree, but that doesn't make you right and me wrong.

Re: External Tags

Reply #376
Thanks for this component, Case.

A few questions:

1. Is it possible to force foobar to automatically *always* write external tags to SQL db and never to the audio files themselves (also never to any pre-existing .tag files)?

For example, is setting:
  • Use only SQLite (fastest)
  • Always write external tags in preferred format
  • Take over all tagging
in advanced preferences enough? Or is the "Create External Tags" command still required for the initial external tags SQL db seeding?

2. When the above configuration is in effect and after all files in foobar's media library are already tracked by the external tags SQL db, will new untracked files added to the media library be automatically handled by the SQL db when editing metadata?

3. Finally, what about untracked files in a temporary playlist (*not* in the media library), is "Create External Tags" required? And will the external tags db remember those files forever or will they eventually be purged after the playlist is deleted?

Re: External Tags

Reply #377
???  Now the tag edits are going to the file and not the db!
Or maybe as well as – I haven't checked.
It's your privilege to disagree, but that doesn't make you right and me wrong.

Re: External Tags

Reply #378
A few questions:

[...]

Answering myself after some brief testing:

  • Use only SQLite (fastest)
  • Always write external tags in preferred format
  • Take over all tagging

is enough to automagically direct all tagging operations to the SQLite database, even for new, untracked files. That covers my questions 1 and 2.
It is possible to override this with the "Edit file tags" context menu command.

As for question 3, my quick tests suggest that edits to files outside foobar's media library remain in the SQLite db indefinitely, or at least the automatic purge doesn't happen as soon as the next foobar startup.

Is there any periodic purge of obsolete entries (ie, files not currently reachable from the media library) in the SQLite database?

Re: External Tags

Reply #379
Waveform Minibar (mod) gives user configuration over the format of the database index used for storing the track waveform.  I would find that useful for External Tags too.
It's your privilege to disagree, but that doesn't make you right and me wrong.

Re: External Tags

Reply #380
Kinda too vague to be a feature request, kinda too vague to be a question about unintended behaviour - but maybe clarify that yes it works this way and yes it works as intended, so that it can be explained in the wiki article?

If the .tag file is modified outside foobar2000, then "Commit External Tags to Files" does not catch it - I need to reload info from tags first. (Similar about Renamer.)
I am not sure if this is intended behaviour or if there was any intention behind it. But copying .tag(s) is one way to synchronize a library, and then a .tag file will be overwritten from outside fb2k, and ... you get my drift.

On the other hand, not reloading did save me from a lot of work upon a crash - then the contents of the external tags were fb2k's database, apparently.

So ... keep  "Commit External Tags to Files" as is, and in addition a "Commit (reloaded) External Tags to Files" ... ?
Of course, there will be too many thinkable combinations: commit with or without deleting, commit with or without reloading, and Case has to author it and ... but anyway. Worth considering.

Re: External Tags

Reply #381
maybe clarify that yes it works this way and yes it works as intended, so that it can be explained in the wiki article?

That goes for album art handling too. It doesn't handle album art with .tag files - does it with database and/or ADS stored tags?

Re: External Tags

Reply #382
If the .tag file is modified outside foobar2000, then "Commit External Tags to Files" does not catch it - I need to reload info from tags first.
It works like the internal "Rewrite file tags" command. Commits the info it currently sees. That part works like I think it should. Would be scary if it wrote different data than you expected.
But it could be considered a bug that foobar doesn't detect that the metadata has changed when the .tag file dates are different. I see I have written functions to handle timekeeping of tags for all formats, but the code is currently not utilized. All file stats come from the actual audio files. I don't remember why I made it this way, it nothing appears to break I'll change this.
 
That goes for album art handling too. It doesn't handle album art with .tag files - does it with database and/or ADS stored tags?
Something else wrong with art handling, or same issue that externally added art isn't visible without reload?
Note that ADS support is identical to regular .tag. The ADS is accessed simply by using a different filename.

Re: External Tags

Reply #383
when the .tag file dates are different.
Might test. Is it modification date it will check? Best tested on NTFS?

As for art:
My .tag files don't contain the art. Never did, obviously: they are like a kilobyte or two. But I don't know how the component handles (or is supposed to handle) art when set to use database.

Note that ADS support is identical to regular .tag. The ADS is accessed simply by using a different filename.
Oh. Does that mean that one can manipulate those with a copy command?

Re: External Tags

Reply #384
Sorry I was unclear. I mean the component currently doesn't report tag update dates to the core. But if it did, foobar2000 should reload info if your copied tag files had different dates.

Art support with database works too. The art is stored as binary in the database.

I don't think ADS files work for your copying purposes. Normal copy commands don't seem to allow touching them alone. But when base file is copied the ADS streams automatically follow.

Re: External Tags

Reply #385
Can this component (or any component) be used to only set *specific* tags based on a pre-determined list?
I ask because I use auto-playlists based on tags. If I wanted to retag a bunch of files when creating a new auto-playlist, the entire audio file will be edited and, when I run a backup on my music files, the file will need to be recopied. If I could just set specific tags to an external file, I'd only have to copy that small file. Trying to save bandwidth, if possible.

Re: External Tags

Reply #386
Can this component (or any component) be used to only set *specific* tags based on a pre-determined list?
Not likely, but based on the "because" part: what stops you from using external tags first, and then when you are done with them, only delete - without touching the files themselveS?

Re: External Tags

Reply #387
Porcus: not sure what you mean by "done with them." Since the auto-playlists rely on current tag values, if I removed the external tags, the auto-playlists would change contents.

Maybe an example would help understand my use case. Let's say I was compiling Billboard Top 40 playlists: one auto-playlist per week. I create a tag called AT40_1970-01-03. I add that tag to each song in my library that was on the Top 40 that week, using the rank as the value of the tag. Later, when I compile the next week's playlist using tag AT40_1970-01-10, I'd add the new tag, likely to the same file(s). And so on. Every time I add a new tag, I'm modifying the file as far as data backup goes. If I could use external tags for specific tags only, I'd only have to backup the (smaller) external tag files.


 

Re: External Tags

Reply #389
I agree setting specific tags to be external tags would be really interesting, for this use-case, overriding specif tags, backups, etc.

@MrMonkey would want to make you note your problem could be solved with a different workflow. Instead of relying on tags to create autoplaylists, you could create playlists with such files and just backup the playlists. I have in mind 2 options:

1-  My SMP manager covers that use-case. Since playlists don't have to be loaded within foobar, they don't clutter your UI. You can then have a category "Top 40 playlists", and create one playlist per week. Finally add the files to such playlists. At any time you can then load the playlists with the files, faster than using queries in fact.

You need a backup? Just backup the 40 playlists. You can even use XSPF format, to have playlists which can be shared (i.e. not pointing to specific files, but just anything that matches the title - artist).

You can also force playlists to tag your files, as soon as you add a item to it, in case you want to do so. There is also a playlist format named "Smart Playlist" (from Kodi) which would allow you to create a playlist using other playlists as source, so you could even mix those playlists easily...

2- Also, as far as I know, m-tags allow to create a "virtual" album which could contain your top 40 playlists. Just select your tracks, create album in m-tags, and name it like "AT40_1970-01-10". Then set as album artist "Various". The m-tag file would point to your physical tracks, but tags are applied only to the tag file.

Re: External Tags

Reply #390
I agree setting specific tags to be external tags would be really interesting
Me too.
It's your privilege to disagree, but that doesn't make you right and me wrong.


Re: External Tags

Reply #392
I cannot tell what is expected behaviour from foobar2000 here, i.e. whether to blame the component or fb2k itself.

%last_modified% does not always seem to capture it when a tag update is done and only .tag files get new timestamps (while the audio files do not).
@Case , is this ... solvable?

Re: External Tags

Reply #393
I spent some quality time with the sources today. It looks like I can't really report tag times since version 1.5 as the filter interface doesn't allow manipulating that data. I'll see what can be done.

In the meantime here's a slightly amended version with highly improved error reporting: https://foobar.hyv.fi/foo_external_tags_1.5.14+.fb2k-component.

Re: External Tags

Reply #394
* Also, cf. the below thing: foo_renamer sometimes fails to rename the .tag file. How I provoked the error?
- Make a change to a tag that is part of foo_renamer's pattern
- Highlight a bunch of files, rename
- Take note that the renamed files don't have external tagtype; open it and see that names don't match
- Highlight and rename again; since the old name matched the file's tags, it would rename back
- Take note that the re-renamed file that has the old name, again has an external tag.
Seems that this happens when foo_renamer renames the directory. Then the .tag file isn't renamed accordingly. Of course, changes that affect my directory names, don't always affect filename, and in that situation the filename will match afterwards.

Re: External Tags

Reply #395
Hm. foo_external_tags and foo_renamer aren't always the best of friends, at least not on the EXFAT file system:
Old name:
AbBa_Eagle.mp3
AbBa_Eagle.mp3.tag
should be renamed to nearly the same, but the first "b" capitalized. Unfortunately, Windows (11) and EXFAT don't think I need to correct case, so a file could easily be reverted back.

I didn't realize it took me this long, but I finally got back to this issue.
Thankfully Windows file system API can report when case sensitive names are not supported, seems to at least be true for FAT32 and ExFAT.

I released a new foo_renamer that uses a workaround when renaming files on such volumes (renames them temporarily to a slightly different name).
I also added the component to the repository: Renamer.

Re: External Tags

Reply #396
Hi
I've a big trouble with external tag.
After I used this component to store a tag the %samplerate% and %bitpersample% values of DSD become wrong...I tryed some workaround but I never succeed...I also tried a fresh installations, but...after usign externa tag....error rose.
If I playback the dsd file occurs tha proprerty dialog shows mewrong value, but the real time data becomes right...it's very strange...see the attachement...
Somone can solve this trouble?

Re: External Tags

Reply #397
External Tags shouldn't be able to alter the decoder information. I already asked you in the other thread to reload information from the files. In the screenshot there you see the "Tools" button at the bottom of the Properties dialog. Click it, and select "Reload info".

Re: External Tags

Reply #398
If I force a full realoding info I can see the correct value. I selected all the dsd file, asked for properties and reloaded infos for every file...it works!

Re: External Tags

Reply #399
As expected. I see now that among all the noise in the other thread you came to the conclusion that External Tags alters the display of the values. I don't see that happening here. Do you have multiple DSD decoders installed?