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

Re: External Tags

Reply #25
I could enable the context menu command for external tag adding for all formats and not just streams, but I don't really see the point.

Yes this. I see a point. Add a menu command like Force dump existing tags to external file for any format.
Eventually moving flac under external tags writter could also work but I don't want to move the flac too low as there's ffmpeg decoder which would take precedence.  Thanks.
m-Tags is too complicated for that purpose (save/remove/open)

Re: External Tags

Reply #26
I want to add a logo (.png from onlineradiobox thanks to @anamorphic) for stream radio item at playlist.
Case, could you tell, how can i do that with External Tags ?

Hi Sergey77:  as Case said in Reply#19 the new version adds album art support only for "local files", I assume what you ask cannot be done, due to the problem he mentioned with the art extractor hardcoded not to work for streams.  Of course, I would be glad to be proved wrong!!

Re: External Tags

Reply #27
This is interesting! Could this potentially replace m-TAGS as a simpler solution to the problem of "never edit internal tags unless (rarely) specifically requested"?
- If external tags aren't present and tags for a file are changed, new tags should be written to external tags and not to internal tags.
- If external tags are present, context menu option to write external tags to internal tags.
 
Or is m-TAGS better because it's explicit whether you're working with the files themselves or the external tags? Perhaps that is better, but m-TAGS has other disadvantages when working with external tags that this solution (I think) would not (file operations don't work well).

Re: External Tags

Reply #28
I want to add a logo (.png from onlineradiobox thanks to @anamorphic) for stream radio item at playlist.
Case, could you tell, how can i do that with External Tags ?
Hi Sergey77:  as Case said in Reply#19 the new version adds album art support only for "local files"...
Hi sveakul!
Exactly, but I see that picture code is added to the .tag file (in external-tags folder) when I click Tagging/Attach picture/Artist for stream item. Also creates .tag file in external-tags folder for HLS item, but changes aren't displayed during playback.
We will hope...


Re: External Tags

Reply #29
The cover art reading code is present and active for everything, but it doesn't get called with streams. I currently have no solution for this.

@zoomorph I know there are people using the component for exactly that purpose. If you alter the decoder priorities and place the writer component above other decoders it will steal tag writes for everything. You can actually disable the tag reader part and just use the writer on top. It can perform all the operations on its own.

I'll see about improving the usage with taggable formats.

Re: External Tags

Reply #30
The following is not expected behaviour?

Selecting a track and looking at "General", it gives me "Tag type": "External APEv2" although there are none.
Converting FLAC to FLAC writes .tags files.
Furthermore, the FLAC files appear untagged, until I delete the .tags.

Version 0.6, with the Writer at the bottom of priorities, yes. fb2k 1.4beta17.

Re: External Tags

Reply #31
I'm experiencing also writings dozen  of .tags files when embedding artwork into FLAC tracks (External tags writer at last slot also)

Re: External Tags

Reply #32
Sorry about that, fixed version of the component is up.

Tag reader was accidentally active even for tracks without external tag files and that caused the tagtype field to be erroneously reported. Forcing re-read of tags for affected tracks will correct the display mistake.

Album art editor isn't tied to any decoder and thus their priority order was probably random. The new version will only be active for files that have .tags files present for them.

This was baked from my work-in-progress version and its context menu also allows force-writing external tag for every file even when tag writer decoder is at the bottom. Though I realized it may be confusing, tag type shows External APEv2 in properties but if you edit it, it will get written to format's native tags.

 

Re: External Tags

Reply #33
New bug. Converted FLAC to FLAC and got
An error occurred while transferring attached pictures (Unsupported file format) : "g:\¤¤¤\tmp\Ifwhen - Null Set - 01 Linked.flac"
Disappeared when I uninstalled the component.

Re: External Tags

Reply #34
Nice, the Edit External Tags is step the right direction, but it still suffers some flaws in consistency and writting logic:

- after creating .tag files and consequently using converter, the external metadata take precedence, but on opening foobar2000's properties, the old content is there, ie. not reflecting fresh external metadata
- on files removal and re-reading the folder content, the .tag content is already shown in properties, but on making any change to metadata via standard properties dialogue, the updated metadata are written to physical files instead to .tag files (intuitively they should be written to .tag files if they exist). My idea is to write ANY change to metadata to .tag files if they exist
- when doing RG scan, the RG info is still written to original files regardless if related .tag file exist or not, and this will probably apply to any other scanning task (BPM scanner, Lyrics grabber etc.)
- when enforcing external tags on multitrack file (CUEsheet), and reopening the cuesheet, the tags show up as total mess
- I have suggestion to write all external tags within one folder to single .tag file with predefined name instead of bunch of single .tag files for each track

Re: External Tags

Reply #35
New bug.
An error occurred while transferring attached pictures (Unsupported file format) : "g:\¤¤¤\tmp\Ifwhen - Null Set - 01 Linked.flac"

Yeah editing embedded artwork causes error now on all formats. Indeed a bug

"Picture editing failed: Unsupported file format"

Re: External Tags

Reply #36
Component reverted to v0.5 before all the mess.

Re: External Tags

Reply #37
Case is it still "safe" to keep using the latest July 4th release if all we are doing is text-tagging radio stream entries?  Or will that technique be changing somehow with your next version so that waiting is recommended?

Re: External Tags

Reply #38
It's safe. If I change some format I'll maintain backwards compatibility.

Re: External Tags

Reply #39
Thanks Case!  This valuable plugin is needed and I know you'll work out the bugs, thanks for keeping us radio stream aficionados in mind.

Re: External Tags

Reply #40
New version up. Hopefully all the bugs are gone now.

Re: External Tags

Reply #41
Thanks!
I still have bugs with reading external tags

Album > context menu > Tags > Edit external tags > make changes > Apply
Album > context menu > Replay Gain > Scan as a single album
RG is now stored only in tag files (right)
But Album > context menu > Properties shows no tags and that even on removing/readding folder to playlist
After tags files are created, the tracks metadata can only be shown by Tagging > Edit external tags
If that's by design, can also context menu > Properties command be redirected to Edit external tags, so that built in Properties command will always show actual metadata, and the same for Masstager and other 3rd party plugins

Re: External Tags

Reply #42
Currently the metadata you add with the context command won't be refreshed to the player automatically. Hacks require hacky workarounds to solve, I had a callback to reload info after tags were saved but it did not work. I can try other methods but for now you need to manually reload info for changes to be visible. And with streams you need to actually play them for the info to kick in.

I'm pretty sure Properties dialog can't be redirected.

Re: External Tags

Reply #43
Case, just wanted to say how much I enjoy using this plugin for my radio streams playlist.  I'm able to provide actual station names that stick (and genres), when previously having to deal with entries like "/" or "opus".  This thing is a beast, and so EASY to use right from context menu.  I also appreciate the fact that the tags are logically stored in their own folder right in Foobar instead of hidden in some "temp files" or other directory, and deleting a tag is equally as simple right from the context menu.  There's just no way to mess things up!  And easier to use than M-Tags.

Just as a FYI to other users, I noticed that an external tag is created (if none had existed) as soon as "Edit External Tags" is selected from the Tagging context menu.  If you choose it by "accident", or just decide you don't want to create the tag after all, hitting the "Cancel" button when the properties dialog appears does not stop a tag from being created.  Perhaps a better label for "Edit External Tags" would be "Create/Edit External Tags."

Thanks again and here's hoping the FB core will someday allow you to add artwork for radio stream external tags (a nod to Sergey77!).

Re: External Tags

Reply #44
I was in desperate need of this. Thank you so much.
Now I can manage my sheet music library inside foobar.

Re: External Tags

Reply #45
I've had a (probably crazy) idea for a tag storing solution for some time. Currently, with both m-TAGS and External Tags, we are unable to rename files without losing the associated tags, because the audio data and tag data are stored in separate files. One solution that I think might remedy this is to use NTFS alternate data streams (ADS). Aside from people potentially being unaware of its existence, is there any reason this has not or can not be done with a foobar2000 component? According to this site there isn't any known size limit.

Quote from: SEP
There is no official limit to the size of the content that can be stored in the streams or to the number of streams, therefore the files with ADS can get quite big.

Re: External Tags

Reply #46
I actually thought about using NTFS streams at first but decided against it. The streams are hidden from regular users and they are easy to lose. They don't survive copying or archiving and can't be used for example on linux based NAS devices. I think a simple more transparent method is better. External tag is immediately visible and rather easy to rename or copy or move together with the media file in file managers.

Re: External Tags

Reply #47
They don't survive copying or archiving and can't be used for example on linux based NAS devices.

Hmm, under what circumstances doesn't ADS survive copying? I use Windows 7 SP1 (Ultimate, if that matters), and all streams are copied via Explorer, both if I use Copy and Cut. Also, WinRAR will store alternate streams if specified. I wouldn't be surprised if 7-Zip has an option too. I don't use a NAS personally, and I'd tend to agree with you on the points of transparency and portability, but in my personal opinion, tagging is such a difficult problem to solve. And I think ADS would solve more than a couple of problems. For example:
- renaming, as mentioned
- clutter (every single audio file has a corresponding .tag file with External Tags)
- file info propagation (m-TAGS shows Location info on the .tags file rather than the actual audio file)

Would it be difficult to add a second interface to External Tags that would allow you to make use of alternate streams instead? I understand if it's not easy to maintain and everything, so please don't do any more than you're willing to.

Re: External Tags

Reply #48
I actually thought about using NTFS streams at first but decided against it. The streams are hidden from regular users and they are easy to lose. They don't survive copying or archiving and can't be used for example on linux based NAS devices. I think a simple more transparent method is better. External tag is immediately visible and rather easy to rename or copy or move together with the media file in file managers.

Considered using both? Those who could think of editing the tag file "by hand", would probably understand a help file.

Re: External Tags

Reply #49
I actually thought about using NTFS streams at first but decided against it. The streams are hidden from regular users and they are easy to lose. They don't survive copying or archiving and can't be used for example on linux based NAS devices. I think a simple more transparent method is better. External tag is immediately visible and rather easy to rename or copy or move together with the media file in file managers.

My vote will always be for "easy" and "visible" over "complex" and "hidden."  That is what makes External Tags such a relief to use.  Just my opinion.