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 81215 times) previous topic - next topic
0 Members and 2 Guests are viewing this topic.

Re: External Tags

Reply #75
Thanks for informing. Fixed. I also made tag edits refresh instantly (doesn't work with streams).
Yes, now that works fine!
@Case, Is it time to attach a picture for a stream link? :)


 

Re: External Tags

Reply #77
@Case, Is it time to attach a picture for a stream link? :)
What would be cool is to add a property like "link to specified image" in External Tags  where user could enter just the path to a specified image file for a radio stream which would then be displayed in the Album Art Viewer box as if it were an embedded cover image.  Case, is that a possibility?


Re: External Tags

Reply #78
New version posted. The component now listens for file deletion and moving callbacks and automatically moves and deletes external tags as needed.

And I added a wrapper method that allows forcing streams to go through the component so you can add album art. You can manually add url wrapped inside "exttag://(url here)" string or turn existing playlist entries to the wrapped format from the right click context menu.

Next plan for the component is to add an optional sqlite database for holding the tags.

Re: External Tags

Reply #79
@Case,
first of all I'm very happy that you managed to do the clever way ...exttag: // () wrapper...
I got identical view of the stream items at the playlist for External Tags and m-TAGS.
But during playback, the behavior of these items is different at playlist. For items of External Tags the contents $meta(genre), $info(tagtype), $meta(url) are missing (see pic. ETG).
For items of m-TAGS all the contents is visible during playback (see pic. MTG), that looks better. Also has the different look for %title%.
Is it possible to get for the elements of External Tags of the same view at playlist as for the elements of m-TAGS during playback?
One more question: m-TAGS can not attach the picture for the same link when the External Tags has already attached the picture?
(I get an error: "Attached picture editing failure on "D:\RadioPlaylist\Intense Radio.tags": Access denied"

p/s
Thanks for your persistence, diligence and work!


Re: External Tags

Reply #81
But during playback, the behavior of these items is different at playlist. For items of External Tags the contents $meta(genre), $info(tagtype), $meta(url) are missing

External Tags returns what the decoder returns. That's the same output you'd get from unwrapped stream. But I changed that for the next version.

One more question: m-TAGS can not attach the picture for the same link when the External Tags has already attached the picture?
(I get an error: "Attached picture editing failure on "D:\RadioPlaylist\Intense Radio.tags": Access denied"
You're sure you aren't attempting to use m-TAGS to work on a link wrapped behind the exttag:// protocol? My component shouldn't affect .tags files in any way.

Re: External Tags

Reply #82
I checked again, you were right. That m-TAGS does not allow to attach a picture to the link with the end .flac, but your component allows.
Everything works great!
@Case, please also consider the possibility to use the feature "Linked meta (field for inline editing)" in CUI for editing TAG fields directly from the playlist for External Tags.

Thanks!

Re: External Tags

Reply #83
Sergey77:  have you tried using the new wrapper to attach an image to a stream that isn't on a web url path, but on an internal path to an image file on your computer?  Is that working for you?  If so, what are you entering?  Thanks for any help!

Re: External Tags

Reply #84
sveakul: I attach local images to links that are on my computer.
When using External Tags, the steps is follows:
1. add a stream link to the playlist
2. right click on the link/Tagging/Wrap for External Tags (set in Context Menu)
3. right click on the link/Tagging/Edit External Tags
4. right click on the link/Tagging/Attach pictures/Front cover (when the warning window appears - click ok)
and choose a picture for the link. The picture will be displayed at field Artwork view.

Re: External Tags

Reply #85
Thanks Sergey77, this works!  I noticed that the new tag created in the "external-tags" folder after doing so grows in size to about the same as the picture attached, so I assume the picture itself is actually put inside the new "wrapped" tag, like embedding into an audio file.  I was hoping that instead it would just contain the LINK to the picture's location and Foobar could use that path to display it in the view box, but hey I'm good with this too  ;D

Case:  Possible bug noticed:  After a new wrapped tag has been created from an existing stream that had a "regular" external tag, using the context command "Remove External Tags" deletes the tag from the external-tags folder, but the stream's "properties" still show "Tag Type" as "External Apev2", and the filepath/folder name still have the prefix "exttag://" after refreshing the entry.  Can these be removed also from wherever  that info is being stored?

Re: External Tags

Reply #86
Good idea to remove the wrapping when external tag gets deleted. I'll add that.

About your album art link question, there are already multiple ways to achieve that. You could for example add a tag COVER where you write the name of the image you want to use. Then configure foobar2000 to look for images from that tag field under Preferences -> Display -> Album art. For example if you store cover images in C:\Covers you could add C:\Covers\%COVER% to the list.

Re: External Tags

Reply #87
Case:  first, thank you for planning on deleting the wrapper when the external tag is deleted, that will make it much easier to visually see what actually still has an External Tag from the properties window.

Second, WOW, your instructions on how to do a stream image display from a link instead of embedding in a wrapper works great!!  It even works fine without having to add a wrapper first.  Much appreciated!  For others who would like to see the steps I did:

1.  In Foobar's Prefs/Display/Album Art/Front cover, type the path to the folder you have images in (can be ANY folder path) into the Search patterns box followed by %COVER%, for example "E:\Media\%COVER%" (no quotes), and save.

2.  Select a stream from your playlist and, if it doesn't already have one, add an External Tag via right-click-->Edit External Tags;  you do NOT have to add a wrapper first.

3.  In the resulting Properties window, hit the "Tools" button on the lower left, and choose "add new field"

4.  Make a new field named COVER in "Field name", and in the "Field value" box, type in the file name of the image you want to display for that link that exists in the folder you specified in step #1 (E:\Media), like "blue ocean.jpg" (minus the quotes), and hit OK.

5.  Now refresh the link by double-clicking on another link, then double-clicking the modified link;  VOLIA, the picture you chose is displayed!  Sometimes it seems to need a second refresh to "take."

The above is tested for radio streams.  The think I like about this method vs. the wrapper embed is that it's fast and easy to change the image and you don't need to add that file size to the external tag itself.  Thanks again, Case, for your instructions!

Re: External Tags

Reply #88
I posted a quick update for the component a moment ago that includes the streaming changes. There's still apparently some potential weirdness possible with local subsong-enabled formats so other updates are on hold until I get those sorted.

Re: External Tags

Reply #89
Case: the component merge static metadata to dynamic metadata works great! Thank you!
sveakul, :)
I used your instruction and I also managed to attach a picture to the link. I liked this way too. Thanks!
Although the wrapping method is also good!
Now I'm "converting" my collection of Internet radio and HLS streams by use External Tags component. :)

Re: External Tags

Reply #90
Can you please make a choice to store external tags in one file per folder, e.g. folder.tags. The bunch of small files makes me nervous and makes the folder messy.

Also how does work Store tags in Alternate Data Streams instead of .tag files? Not working for me.

Re: External Tags

Reply #91
Alternate data streams are not guaranteed to work on network shares unless you specially configure your Samba share server to support alternate data streams, otherwise there won't be any way to store them. On local file systems, they're only guaranteed to work on NTFS and ReFS, or maybe whatever you're running Wine on, assuming it supports that crap.

Re: External Tags

Reply #92
That's NTFS drive directly connected, alternate data streams doesn't store anything.

Re: External Tags

Reply #93
Also note that Alternate data streams are not really visible in most file managers, but if it's not working at all, then it does sound like it's broken.

Re: External Tags

Reply #94
The component won't convert existing .tag files into streams. Remove existing .tag files and try creating external tags again. It will revert to .tag on unsupported file systems or other error situations.

Re: External Tags

Reply #95
@Case
So, the Alternate data streams in principle do work on NTFS filesystem.
Please add the detection if ADS can't be used and use consolidated folder.tags instead.
The external tags are now recognized quite steadily by foobar, except the conversion. For target naming scheme external tags are always used (if present). But, for transfer of tags from source → output, external tags are not always used. It's random mixture of original and external tags. Maybe bad timing?

A minor extra wish: please add a menu entry "Create external tags" which will (re)create extern tags from original metadata content, without opening the properties dialogue.

Re: External Tags

Reply #96
Is there some reason you hope for additional command that won't open properties dialog? Note that opening the dialog won't slow the process down at all, copying existing tags and forcing foobar2000 to reload info is what eats all the time. If you don't wish to alter the tags you can just close the dialog immediately. But if you wish to do some changes you can do them immediately.

Here's an experimental version of External Tags component which uses only SQLite databases and doesn't otherwise touch the filesystem. I also simplified the subsong handling to hopefully solve all the weirdnesses @Porcus had to deal with.
Currently it uses different file name and names for commands so it can co-exist with the original External Tags component. This allows copying tags from the old external tag files into the new database.

This database approach should be quite a bit faster when dealing with large amount of handled files. But let me know if you hate it so I'll know to discontinue.

Edit: experimental component removed. Official version now has SQLite support.

Re: External Tags

Reply #97
* It is a very good point that you actually do not need to do any editing in the Properties window - the external tags are created already and I can just hit Esc.
But the DB version opens "Properties" (with "Partial info shown") early on while still "Processing files", and I don't know whether it is safe to hit Esc then?!?

* Speaking for myself, I want to use external tags - your component or foo_tags, whatever I settle on - to reduce "write risk" not only for everyday tag updates, but also for updating a backup. (Whether I am comfortable with overwriting a .tag or whether I want versioning.) So writing .tag files from a DB is a more wanted feature than importing .tag tags to DB.


* Initial testing, first uninstallin foo_external_tags uninstalled and then reinstalling both:

- I can no longer reproduce the issues I had!

- After removing external tags (no-db), I - often - need to "Reload info from file(s) if changed" for those FLACs that have embedded cue and subsongs - except, the first subsong gets fixed automatically.  (So it says that it has external apes for e.g. 78 % of the tracks in a single file.) But "if changed" was sufficient in all cases but one (in which it was an ordinary multi-file folder too) - unlike the next:

- After removing external tags (DB), I need to "Reload info from file(s)" from precisely those files which have subsongs. The differences are (I): "Reload info from file(s) if changed" is insufficient on these files, and (II): the first subsong also "has" External Tag until reloaded.

- Both components leave fb2k "Not responding" while running "Edit", until the properties dialogue is open (which, as said, happens "quite early" for the DB component). fb2k still plays music, but does not accept any other user input.
The DB component leaves fb2k "Not responding" on Remove as well, the non-DB does not.

Re: External Tags

Reply #98
But the DB version opens "Properties" (with "Partial info shown") early on while still "Processing files", and I don't know whether it is safe to hit Esc then?!?
The "processing files" dialog is from info reload. It is performed after last external tag is done and properties dialog is given the open call.

The reloading wouldn't be 100% necessary but without it if tags aren't edited no components will see the new tagtype info field. And tagtype info field is actually used currently for deciding whether to show the Commit and Remove commands in the context menu. Though with DB version this could be changed to use the DB directly. It was originally this way to not slow context menu opening down from needless filesystem accesses.

writing .tag files from a DB is a more wanted feature than importing .tag tags to DB.
So that's a vote against the SQLite direction. I was hoping to simplify the component but it sounds like that can't be done. Filling Anakunda's wish of combined per-dir tag files will further complicate things.

- Both components leave fb2k "Not responding" while running "Edit", until the properties dialogue is open (which, as said, happens "quite early" for the DB component). fb2k still plays music, but does not accept any other user input.
The DB component leaves fb2k "Not responding" on Remove as well, the non-DB does not.
These operations run in the main thread. The file-using version apparently benefits from disk caches. The OS removes files on the background when it can, database keeps operations in sync. The operations can be moved to a thread to not lock the UI though.

Re: External Tags

Reply #99
I don't know if it was mentioned before, but when I tried to convert a track to Wave 64, an external tag was created automatically. Is it possible to have it always try to create an external track when doing convert without tagging?