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: foo_musicbrainz (Read 278806 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: foo_musicbrainz

Reply #500
we always had our phone books in lastname, firstname

What a terrible example. I'm giving away my first name on this forum and you really think you'd look for and find me under the letter M in other countries?? :/

FWIW, I'm English but the thought of implementing any kind of SORT ORDER has never crossed my mind. I expect to find bands beginning with The to appear under T. Looking for The Beatles under B is just as alien to me as US style dates.

I'm not totally against implementing this for other people but the inconsistency in what fb2k does is an issue. Most people want ARTISTSORT for Vorbis/APEv2 but fb2k automagically transforms this to ARTISTSORTORDER to write TSOP frames in mp3 files. This happens when using the Properties dialog or writing tags via the fb2k SDK in code. The interface is just as simplistic - I don't have to know or care about the destination file internals. I just use the same names as you'd use to access the tags.

If anyone uses Picard they will be aware of this already and would already have to use title formatting gymnastics with $if2/$if3 to utilise both. It's not really something I want to copy.

A filthy hack could be writing MUSICBRAINZ_ARTISTSORT which would be guaranteed to be written as TXXX in mp3 files and consistent across all other file types but then you'd have to forget about other players/devices.


Re: foo_musicbrainz

Reply #502
we always had our phone books in lastname, firstname

What a terrible example. I'm giving away my first name on this forum and you really think you'd look for and find me under the letter M in other countries?? :/

FWIW, I'm English but the thought of implementing any kind of SORT ORDER has never crossed my mind. I expect to find bands beginning with The to appear under T. Looking for The Beatles under B is just as alien to me as US style dates.
My point was simply that when you're used to searching for people using a given convention (using the telephone directory before the internet) it becomes engrained, and using a different approach is really quite jarring. You obviously had exactly the opposite experience :-)
I had a quick look at the track artists in my music collection, and grouping by the first letter of ArtistSort (typically how I'll browse the artist index) provides a more even distribution, whereas using Artist the T category is twice the size of the next largest.

Support for writing ARTISTSORT has been added, off by default. The changelog re-iterates what was said above.
https://marc2k3.github.io/component/musicbrainz64/
That works beautifully.

The only other thing you might want to consider is %_releasecomment% which adds disambiguation to album names e.g. Deluxe Edition, Fully Loaded Edition.

Much appreciated. I don't think I need Picard anymore!


Re: foo_musicbrainz

Reply #504
Quote
%_releasecomment%

If I add this, it won't have the _ prefix. We already have RELEASESTATUS, RELEASECOUNTRY and RELEASETYPE so I'll stick to that convention.
%_releasecomment% is just how MusicBrainz Picard exposes it. Whether you add it or what you name it is obviously your call.

Re: foo_musicbrainz

Reply #505
Wow, realize I'm pretty late to the party here, but is @SimBun referring to the "DISAMBIGUATION" field from Musicbrainz? Seems in that case RELEASEDISAMBIGUATION might be better?

I finally got around to installing 2.0 tonight, realized that it had an x64 version, realized I needed to update this component, and then saw that Marc was already doing it on his old repo. I do still have plans to update my copy, and then see about migrating marc's recent updates over to it.

Re: foo_musicbrainz

Reply #506
Hi @MordredKLB,

Looking up _releasecomment in the Picard docs shows:
Quote
_releasecomment
    Release disambiguation comment. (since Picard 0.15)
so I'd say that you're assumption is correct.

@MordredKLB/@marc2k3,

One thing I've just noticed from the documentation is that in addition to ARTISTS (a multi-value version of ARTIST) there're also ARTISTS_SORT. Currently @marc2k3 is currently pulling through ARTIST_SORT which I have to then split by " feat. , ft. , with , x , & " and then sanitize to make sure the & shouldn't actually be there, so if that could be changed that would be amazing.

Thanks to you both.

Re: foo_musicbrainz

Reply #507
In my own personal musicbrainz tagger, I map the release disambiguation field just to an EDITION TXXX frame, because that's essentially what it is (you could get pedantic and claim that some of the values here like "Yellow Vinyl" aren't true editions, but whatever). Apparently there's also a Release Group Disambiguation field, but I honestly don't know when that would even be used... maybe just the first four Peter Gabriel albums? 😀

I think one problem with going crazy trying to implement everything Picard does is that there's just TOO MUCH stuff, and it gets confusing and isn't all that useful... especially when you need to add a ton of options to enable change values. I use ARTISTSORT/ARTISTSORTORDER religiously, but an ARTISTS_SORT somehow seems like overkill to me? I dunno.

Edit: I guess I do use my own ARTISTSFILTER field which I'm realizing is exactly the same thing, so maybe another settable field value makes sense here as well.

Re: foo_musicbrainz

Reply #508
In my own personal musicbrainz tagger, I map the release disambiguation field just to an EDITION TXXX frame, because that's essentially what it is (you could get pedantic and claim that some of the values here like "Yellow Vinyl" aren't true editions, but whatever).
I store this in a RELEASE tag, but I made that decision before I'd really started digging into MusicBrainz otherwise I may have named it differently. Either way as long as it's available it's trivial to rename after the metadata retrieval.

I think one problem with going crazy trying to implement everything Picard does is that there's just TOO MUCH stuff, and it gets confusing and isn't all that useful... especially when you need to add a ton of options to enable change values.
I do absolutely agree with that, and that's certainly not my intention.

I use ARTISTSORT/ARTISTSORTORDER religiously, but an ARTISTS_SORT somehow seems like overkill to me? I dunno.
I wasn't thinking of necessarily having it in addition to others. Just like ARTISTS gives you one artist per field as opposed to ARTIST which concatenates them all together with a join phrase, ARTISTS_SORT is the equivalent.
Maybe I'm wrong, but I thought having multi-value ARTIST and ARTISTSORT fields was the right way to store these attributes, so if it were for my purposes only I'd have simply mapped ARTISTS to ARTIST and ARTISTS_SORT to ARTISTSORT and be done with it, but I have no idea if people actually want the names concatenated together (nor do I understand the implications of supporting formats other then FLAC), so a reasonable compromise would be to include ARTIST and ARTISTSORT and then ARTISTS and ARTISTSSORT - or other more meaningful names that identify the S variants as being one artist per field.

Re: foo_musicbrainz

Reply #509
I personally DO want the concatenated names in the ARTIST field so that I know it's "Camila Cabello & Shawn Mendes" compared to "Camila Cabello feat. Shawn Mendes" even though the ARTISTS/ARTISTS_SORT fields would have the exact same "Cabello, Camila; Mendes, Shawn" data.

Re: foo_musicbrainz

Reply #510
I assumed you did, but then you also said you use ARTISTSORT, so I'm assuming you must be manually splitting the artist/artistsort into multi field tags as well as keeping the concatenated version. If I could get a multi-value tag containing the JOIN_PHRASE for each artist that would be quite cool, although I think that's a bridge too far now, although I will have a look in Picard.

Re: foo_musicbrainz

Reply #511
Sorry for the huge delays in getting this out. I suck.

0.5.0b1
 - Rebuilt with new foobar SDK 2.0
 - Supports dark mode and x64

https://www.dropbox.com/s/s8vqgubbfukuz7u/foo_musicbrainz-v0.5.0b1.fb2k-component?dl=0

Please report any bugs/issues. Hopefully you all haven't completely abandoned this component (but if you have less maintenance for me!  ;) )

Re: foo_musicbrainz

Reply #512
@MordredKLB
Thanks a lot for the updated component. Grabbed and tested it on v1.6.16 & v2 Beta 24 and it works fine. No issues found while testing it.

Re: foo_musicbrainz

Reply #513
Why should I abandon this great plugin, it is an often urgently needed aid.

Michelist

Re: foo_musicbrainz

Reply #514
Why should I abandon this great plugin, it is an often urgently needed aid.
:D Thanks, just be aware you have other options!

Re: foo_musicbrainz

Reply #515
Thanks for the update mate, one less component for full fb2k x64 compatibility 8)
So it is appreciated!

Btw, can you also compile your foo_enhanced_playcount to x64, that would be great!

-TT

Re: foo_musicbrainz

Reply #516
Btw, can you also compile your foo_enhanced_playcount to x64, that would be great!
It's next on the docket. Might take a few days since it's more complicated with the change in how index-data stuff seems to work now.

Re: foo_musicbrainz

Reply #517
Hi @MordredKLB

I would like to ask you something.

I'm using foobar through wine on Linux. I noticed that the fonts in the MusicBrainz tagger doesn't follow the changes in foobar font configuration or winecfg.



Did you know where this font takes its value from, or how can I change it to mimic the rest of foobar fonts?

Re: foo_musicbrainz

Reply #518
Sorry I've never used wine and have no idea what could be wrong there or how to fix it. I welcome any PRs from those who might know though.

Re: foo_musicbrainz

Reply #519
Sorry I've never used wine and have no idea what could be wrong there or how to fix it. I welcome any PRs from those who might know though.

In windows, this font responds to changes in foobar preferences default ui fonts and colors?


Re: foo_musicbrainz

Reply #520
Since when do ANY popup dialogs respect UI fonts (things like album list which are embeddable UI elements don't count). You might find the odd exception but it generally is not the rule. Even the main properties dialog for editing tags has its own font dialog available via the Tools button. It certainly does not respect UI fonts. Does the Preferences dialog itself respect UI fonts? Er no.

Anyway, the current font is dictated via the .rc file. So right now, it's a compile time constant. Most dialogs are hardcoded to use MS Shell Dlg 2 but I think I updated it to Segoe UI during my time as maintainer when I made windows 7 the minimum requirement.

I guess you can use SetFont on a per-window basis from OnInitDialog if you wanted to override it dynamically.

Re: foo_musicbrainz

Reply #521
Since when do ANY popup dialogs respect UI fonts (things like album list which are embeddable UI elements don't count). You might find the odd exception but it generally is not the rule. Even the main properties dialog for editing tags has its own font dialog available via the Tools button. It certainly does not respect UI fonts. Does the Preferences dialog itself respect UI fonts? Er no.

Anyway, the current font is dictated via the .rc file. So right now, it's a compile time constant. Most dialogs are hardcoded to use MS Shell Dlg 2 but I think I updated it to Segoe UI during my time as maintainer when I made windows 7 the minimum requirement.

I guess you can use SetFont on a per-window basis from OnInitDialog if you wanted to override it dynamically.

That is what I need to know.

In case any linux-wine user have the same problem;

Removing Segoe UI font. Leaving the symbol one.
Making a substitution in the registry for Segoe UI with Arial Unicode MS.
In HKEY_CURRENT_USER/Software/Wine/Fonts/Replacements add "Segoe UI"  REG_SZ "Arial Unicode MS"
I also add MS Shell Dlg 2, just in case.
Arial Unicode MS must be downloaded and put in /home/<user>/.local/share/fonts and do "fc-cache -f -v" to rebuild font cache



Thanks.


Re: foo_musicbrainz

Reply #522
Replaying to myself.

A more elegant method that allow to use the original Segoe UI font and fallback to Noto CJK font, both of them prettier than Arial Unicode MS.

If you follow previous method, you can install Segoe UI again and remove the edit in the registry.

Now add this one:

In  HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\FontLink\SystemLink

New REG_MULTI_SZ with name "Segoe UI" and value

Code: [Select]
TAHOMA.TTF,Tahoma
MEIRYO.TTC,Meiryo UI,128,96
MEIRYO.TTC,Meiryo UI
MSGOTHIC.TTC,MS UI Gothic
MSJH.TTC,Microsoft JhengHei UI,128,96
MSJH.TTC,Microsoft JhengHei UI
MSYH.TTC,Microsoft YaHei UI,128,96
MSYH.TTC,Microsoft YaHei UI
MALGUN.TTF,Malgun Gothic,128,96
MALGUN.TTF,Malgun Gothic
MINGLIU.TTC,PMingLiU
SIMSUN.TTC,SimSun
GULIM.TTC,Gulim
YUGOTHM.TTC,Yu Gothic UI,128,96
YUGOTHM.TTC,Yu Gothic UI
SEGUISYM.TTF,Segoe UI Symbol
NOTOSANS-REGULAR.TTF,Noto Sans
NOTOSANSCJK-REGULAR.TTC,Noto Sans CJK JP
NOTOSANSSYMBOLS-REGULAR.TTF,Noto Sans Symbols
ARIAL-UNICODE-MS.TTF,Arial Unicode MS

Noto fonts are installed by default or available in almost all distributions. Arial Unicode MS is now a last resource (It is a bit ugly)

You can add your favorite fonts or any language that you miss.

Windows fonts
https://github.com/taveevut/Windows-10-Fonts-Default

Re: foo_musicbrainz

Reply #523
Thanks for the great component! I'm thiiiis close to no longer needing to use Picard anymore (or at least for adding MBIDs quickly). Picard's great, but having to open it up every time and search for the album is a pain.

I opened a Git issue, but I'll repost it here for discussion, etc. Searching for album via catalog number, and "Preserve this field", would be really useful for me. Often times I don't want to change the album name or the track titles because I have JP albums with EN names instead.

I also add recording/work comments with the disambiguation in Picard. Here are the scripts if anyone wants to use them.

$if(%_workcomment%,$set(work,%work% [%_workcomment%])))
$if(%_recording_comment%,$set(recording, %_recordingtitle%)))

It's useful (to me anyway) because it lets me know at a glance what a song might be a cover of, etc.


Re: foo_musicbrainz

Reply #524
Thanks for the great component! I'm thiiiis close to no longer needing to use Picard anymore (or at least for adding MBIDs quickly). Picard's great, but having to open it up every time and search for the album is a pain.

I opened a Git issue, but I'll repost it here for discussion, etc. Searching for album via catalog number, and "Preserve this field", would be really useful for me. Often times I don't want to change the album name or the track titles because I have JP albums with EN names instead.
Why is it that album/artist doesn't work but catalog number would? Is it because you're translating names?

In my own personal tagger I have a method for getting the original artist for songs so I can determine if it's a cover or not. Isn't perfect but works pretty well. I might look at implementing that for this component. Would that be beneficial?

I'm not sure I want to add workcomment/recording comment though. I'll consider it, but I need to do some more investigation.

Your "preserve this field" idea is actually a huge shortcoming of this component as is, and again something I did in my own personal tagger. The big hurdle is how to convey that to the user in the limited dialog space we've got. It's particularly difficult for any of the fields in the grid below. Maybe some kind of right click menu, that's great for a single field, but the UX for that kinda sucks if you want to preserve 5 fields or whatever.