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 82322 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: External Tags

Reply #350 –
manmower:  the external tag for streams is only created automatically if you actually attempt to add tags to the stream;  just opening "Properties" from the context menu, and closing it, does not automatically create an external tag for a stream.  If the stream already has an M-Tag, I don't know what happens.

Re: External Tags

Reply #351 –
Hi Case (or anyone else who can answer), quick question, is there a way to distinguish whether attached cover art is stored internally or externally? I often remove a cover, it doesn't work, then the penny drops that I need to first Commit external tags, and try again. I also prefer to store cover art in external tags; it would be nice to track down all of the files in my library that still have covers attached internally. I was thinking a %__covertype% field or similar could come in handy in both cases, if I'm not missing something. Thanks!

Re: External Tags

Reply #352 –
That isn't supported at least at the moment. If there's a simple way for me to implement that I can add it.
 

Re: External Tags

Reply #353 –
You probably have thought of this and found it not to be "a simple way", but if not, here's from some ignorant swiney snout who totally sucks at coding:

* Could be stored in a ZIP or 7z file with a different suffix (like fb2k-component does) and name each picture something like
0 Front = description.jpeg for common "front"
1 Back = description.jpeg for file 1's back that is not common to all
1 Front = otherdescription.=0 if file 1 uses the 0 Front file but a different description
etc.
* Using 7-zip (which is FOSS) you can probably duplicate files without size penalty, and accommodate "file names" as long as hell.
* One tagset per file rather than per folder? Easier.

Re: External Tags

Reply #354 –
I think the point is how to implement an exposed check to tags which should output true when it's an external tag and false when it's on file. And it should be query compatible (since that's the main aim)
Code: [Select]
$isExternalTag(artist)
BUT some entities are not a tag per se, like the cover, which has no TF variable. That would require another TF function for those specific cases (not sure if there are more than the cover).
Code: [Select]
$isExternalTagCover()

Then it further complicates its use with m-tags, since such function would only check if the tag is provided by the plugin, but it would not be 100% sure they are from the files (may be from m-tags). I suppose people use one or another plugin but its worth warning about it if such feature is aded.

Re: External Tags

Reply #355 –
A couple of observations using .tag files, none are a big deal.

* For files that have no tags at all, I can create external tags and remove external tags, but commit to file does nothing.
That is maybe OK to leave in as a warning?
* Every now and then, commit will "fail": having library search for %__tagtype% HAS xt while it is running, there will be some odd folder with a file left in the search. Yes sometimes the library is lagging and it "disappears" after a "Reload info from file(s)", but most often not.
I don't know if it actually gets as far as to writing tags to the audio files (i.e. only the removal stage fails).
No big deal: I just have to run it once again.

Tested right now on v2 64-bit, but I noted the second item for a long time.

Re: External Tags

Reply #356 –
Oh, and:
I discovered that failure to commit sometimes happens on part of a multi-track ("image") file.
Then the .tag file is gone nevertheless, so any tag updates are lost.

Re: External Tags

Reply #357 –
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.
But foo_external_tags is case sensitive, and then it doesn't recognize the .tag file.

Too bad to have to correct Microsoft's fuckups, but I guess that is part of the game when working on Windows.
(Feel free to shout back "yes, do that - avoid EXFAT!")

Re: External Tags

Reply #358 –
Need help which right now hopefully can save a couple of days' labour, if the following works - but I'm asking before firing up fb2k again.

* Hard drive crash [well maybe, I have not yet taken the chance of firing it up again] at the end of a major tag clean-up. Might have found some bad sector, or might have shut down as a safety precaution over running too hot.

foo_external_tags is installed.

Can I get these tags transferred to a backup drive (well the now-in-the-works copy of the backup drive) as follows
* Without connecting any drive, ask foo_external_tags to create (SQL) tags for everything, and then
* Connect a backup drive which has - with a couple of renamed exceptions that I will find - the same files (after making sure it identifies at the same drive letter), and
* Then have these updated tags from current database in foo_external_tags' SQL database, ready to commit
?

I probably need to disable fb2k's library rescanning at startup, and I probably need to do that before I fire it up?

Re: External Tags

Reply #359 –
I'm sorry I can't provide a perfect answer at the moment, but what you are attempting sounds doable. I'm still on the road and can't conveniently access my development machine. Remember that you can always backup your foobar2000 profile and all the cached info there remains intact. If the attempt doesn't work I can make adjustments to the component to make it possible.

Re: External Tags

Reply #360 –
Quote from: Porcus on
I discovered that failure to commit sometimes happens on part of a multi-track ("image") file.
Then the .tag file is gone nevertheless, so any tag updates are lost.
That at least is definitely a bug. I'll take a look.

Quote from: Porcus on
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.
But foo_external_tags is case sensitive, and then it doesn't recognize the .tag file.
If foo_renamer fails at file renaming I'll have to fix that. Thanks for letting me know.

Re: External Tags

Reply #361 –
Is it feasible to set up this component, or any other component, to only write specific tags to the external database, and continue writing all other tags to the audio file?  For example, to capture a tag field for a purchase receipt URL that I don't want to write to the audio file.

Re: External Tags

Reply #362 –
Thank you, Case, for this really useful plugin.
Are there plans to recompile this component to work with 64-bit Foobar 2.0?

Re: External Tags

Reply #365 –
^ That is the official release, direct from the component home page by Case.

Re: External Tags

Reply #367 –
If you check the fb2kv1.x edition of the component, that is the same version 1.5.12 on both Case's homepage and the official component page.

According to the changelog, new in 1.5.13 was "Changed the component to use SQLite bundled by the player." and that is v2.0's new library, so it does nothing to fb2k v1.x.

Re: External Tags

Reply #368 –
The following might be symptoms of something. Not saying they are more than nuissances, and especially for the first I suspect that work-arounds may even slow it down so much that the easy manual fix is a better solution:

* Committing tags to files sometimes fails. That is, I don't know if it is the commit part that fails, or deleting the .tag file.
I have taken note of it before, but now I "counted" when I did a mass commit of some 80k files (using the APE file tags, one .tag per file): and around a percent of them - eight hundred - still had external tags.
Possibly relevant: It did look like there were some one percent and a half, but fb2k hadn't discovered it: when reloading tags from files, a few disappeared from the query (I queried on %path% IS <pattern> AND %__tagtype% HAS xt). The "around a percent" is the figure after reloading - those that indeed still had the .tag file.

* 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.

Actually, the reason I did the commit in the first bullet point story, was to safeguard against the second. I had made a major update after the incident in #358 (where foo_external_tags indeed helped an awesome lot, thanks!), so I had an extra level of backup temporarily and ... long story.

A likely-too-large-wishlist-item would be a functionality to "recover tags from unmatching filenames" - by matching on some pattern that includes track number I guess, or maybe customizable. Easiest to explain would be for folder.tags: a functionality that searches for a folder.tags file in the folder, and finds the entry that has the same track number. Say if I have fixed up a typo in album title, artist name or track title; still for the folder's track 3 (or 03) it can find back track 3 in folder.tags. For single .tag files it would have to traverse the directory looking for them. More job.

Now for this:

Quote from: Case on
Quote from: Porcus on
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.
But foo_external_tags is case sensitive, and then it doesn't recognize the .tag file.
If foo_renamer fails at file renaming I'll have to fix that. Thanks for letting me know.

I don't think that is so easy. Trying to manually rename a folder this way in Windows Explorer, just changing some characters between upper and lower case, just doesn't do the job. So to implement this, I think you would have to do as in the following example:
Want: rename foldER\filEName to Folder\Filename
Do: rename to Folder~`tmp´\filename and then rename the directory afterwards. Hopefully, if it is written to a new directory, then case changes in filename will be honoured.
But this would likely be a major slowdown. More efficient (but more job for you) would be to check if it has to be done.

Re: External Tags

Reply #369 –
Thanks for the issue reporting. I'm sorry I still haven't taken the time to fix these problems.

I suspect the files somehow get locked and the operations get canceled. At least anti-viruses are known to cause that. And I don't have proper error reporting in the component. I really need to add that along with a retry loop if file access is temporarily blocked.

I haven't forgotten about the Renamer issue either. My life has had some positive changes but they have unfortunately meant less time for foobar2000.

Re: External Tags

Reply #370 –
Ah! Whether or not it is the same reason why CUETools developent suddenly took a hiatus ... good for you :-D

For commit to files:
I was worried (well not really "worried", you get my drift ...) it could be due to fb2k not allowing the tag commit, that would be "bad" in the senses that it would be a symptom of something unfortunate going on between the component and fb2k.
If it is Windows Defender (the only antimalware thing in here on this computer) that protects the .tag/.tags file and it actually commits the tags to file, then I'd say it is just a nuissance that could be relegated to "Known issues [...]Solution: run again on the remaining files".

BTW, for documentation ... just in the event you feel you have time to think over it:
 * the menu item "Commit" doesn't say outright that it will commit & then remove - but I don't know if any actual users will miss that piece of information. We can always recreate, although "Commit and then commit the rest to be sure and then recreate because I really wanted commit and not remove" is a minor nuissance.
 * I don't know if there is any sort of documentation what the wrapper does and what it is good for. No big deal for me ... uh, presuming it doesn't do anything I really want, which I don't know because I haven't used it because I don't know what it does  ;) 

Re: External Tags

Reply #371 –
Please somebody tell me whether this would work:

I would like to apply preset tempo adjustment to a few tracks, without the adjustment affecting the actual MP3 file.  If I install External Tags and make the .mp3 read-only, will writing to the TempoAdj tag then be diverted to the database file, and will fb2k continue to read the ID3 tags as well as the TempoAdj tag in the database?  I've read that all tag writes will go to the database, but I'll only be writing TempoAdj.
It's your privilege to disagree, but that doesn't make you right and me wrong.

Re: External Tags

Reply #372 –
Okay, so I tried it out and I see what it does (copy all the tags out to a database, if any tag gets updated).

So now what I want to do is nuke the changes to restore the tags as per the .mp3 file.  I tried deleting the external-tags.db file, but the changes to the tag contents persist.  Why?
It's your privilege to disagree, but that doesn't make you right and me wrong.

Re: External Tags

Reply #373 –
Because foobar2000 caches metadata on its own and nothing in the player refreshed the info.
If you use External Tags component to remove the external tags by holding shift and using context command Tagging -> Remove External Tags it will update the core with the changes.
If you want to do things manually you will need to force foobar2000 to reload the changes. You can use Properties dialog (Tools -> Reload info) or playlist context menu Tagging -> Reload info from files.

Re: External Tags

Reply #374 –
Quote from: Case on
Because foobar2000 caches metadata on its own and nothing in the player refreshed the info.
If you use External Tags component to remove the external tags by holding shift and using context command Tagging -> Remove External Tags it will update the core with the changes.
If you want to do things manually you will need to force foobar2000 to reload the changes. You can use Properties dialog (Tools -> Reload info) or playlist context menu Tagging -> Reload info from files.
OK, thanks, that's opened up a whole new world - I had no idea about shift+rightclick (hardly intuitive!).

However, these seem to be "selection only" operations – is there a way to force fb2k to refresh its entire cache in one hit?
It's your privilege to disagree, but that doesn't make you right and me wrong.