Album Tag Importer

[GrimReaper 4911]

@user24When you have a minute, send me in PM few mp3s that have all the tags embedded, in particular that ROONALBUMTAG (as said, I know zip about music and I'm not too keen to educate myself, as I'm perpetually lacking time for all of my own inteterests to begin with) together with screenshot/description of your library structure, I have an idea and wanna try something that might spare you few months of manual tagging within Emby, but need something to test it on. 

[user24 362]

2 hours ago, GrimReaper said:

send me in PM few mp3s that have all the tags embedded

Sure, not a problem - I'll be able to do it within next 12 hours. I only have FLAC files, but I can make up a small set of both .flac and comparable .mp3 if that will be useful? Standard tags plus RELEASETYPE, ROONTRACKTAG and ROONALBUMTAG. 

I'll also send you details of my music library set-up and and can also make a general post here about music tagging workflow, if that would be useful - I can make it a short "Executive Summary" as best as I can!

Edited Monday at 06:52 PM by user24

[GrimReaper 4911]

10 minutes ago, user24 said:

I only have FLAC files

FLAC will do as well, if it has same tags. 

10 minutes ago, user24 said:

I'll also send you details of my music library set-up and and can also make a general post here about music tagging workflow, if that would be useful - I can make it a short "Executive Summary" as best as I can!

No need to get into much specifics, I just need to see the layout/structure so I can reproduce. 

[user24 362]

The tags may be similar, but they could have technical differences, so I can send a few of each - then you can try out whatever you want to. From the table below .mp3 uses ID3v2 and .flac uses Vorbis. https://picard-docs.musicbrainz.org/en/latest/appendices/tag_mapping.html

Edited Monday at 07:07 PM by user24

[user24 362]

6 hours ago, GrimReaper said:

No need to get into much specifics

Noted. I'll aim to send you the minimum amount of info for testing purposes!

Generally, it's significantly faster to carry out bulk tag editing in Mp3tag (manual or auto) and then import into Emby, if possible.

• Emby will import most standard tags into the relevant fields (e.g. ARTIST).
• Emby will not import some standard tags into the relevant fields (e.g. ARTISTSORT).
• Emby is currently able to import unsupported tags into the Song/Track "Tags" field via ROONTRACKTAG.
• Emby is currently not able to import unsupported tags into the Album "Tags" field via ROONALBUMTAG.

As far as this topic goes there are several potential usability scenarios:

• Best case: Emby is able to import RELEASETYPE tags into an Album "Release Type" field and then Group by Release Type, as a native function!!!
• Emby is able to import actual RELEASETYPE tags directly into the Album "Tags" field (faster tag editing in Mp3tag) and these tags can then be used for custom projects!
• Emby is able to import defacto Release Type tags into the Album "Tags" field, via ROONALBUMTAG (faster tag editing in Mp3tag) and these tags can then be used for custom projects?
• Worst Case: Emby is not able to import any Album-only tags (significantly slower non-bulk tag editing in Emby only) and custom projects become less fun and more like a huge chore - then the end-result may not be worth the overall time & effort for many people???

There are likely many other combinations of options - but any method of importing Album tags into Emby would be most useful. Cheers!

[GrimReaper 4911]

9 hours ago, user24 said:

Best case: Emby is able to import RELEASETYPE tags into an Album "Release Type" field and then Group by Release Type, as a native function!!!

Emby has no dedicated "Release Type" metadata tag? Under that scenario nothing can be done for that case. There's TYPE tag ("Type": "MusicAlbum") but I don't know is that used for some other Emby's logic and I'd rather not mess with it.

Edit: What's the difference between ARTIST and ALBUMARTIST and ARTISTSORT and ALBUMARTISTSORT tags? They are same for both items in the example image - are there separate metadata fields (not exposed in the UI) in Emby for either of them or there's only Sort title? And will they ever be different or they're always same? Edit: Scratch that, upon investigation, those are only query arguments, they all lead to the sane MusicArtist and the sane SortName field. So the only question remaibs: How are conflicts - if one track from the same artist has ARTISTSORT or ALBUMARTISTSORT X and the other has ARTISTSORT or ALBUMARTISTSORT Y - resolved? Which one takes precedence? First found? Last found? Or artist is duplicated?

Edited Tuesday at 11:49 AM by GrimReaper
More queries

[user24 362]

6 hours ago, GrimReaper said:

So the only question remaibs: How are conflicts - if one track from the same artist has ARTISTSORT or ALBUMARTISTSORT X and the other has ARTISTSORT or ALBUMARTISTSORT Y - resolved?

Oh no!!! I've accidently widened the discussion instead of narrowing it, but I do have an answer (sorry, I mean opinion) for you on this...

First, lets widen this again (oops!) to ALBUMARTISTSORT, ARTISTSORT, COMPOSERSORT. What happens when one entity (e.g. Person or Group) is all three (ALBUMARTIST, ARTIST, COMPOSER) and the SORT embedded metadata tags all happen to be different and all three map to the same "Sort Title" field???

Emby needs to ultimately make the management call (e.g.):

• Our customers are more likely to be contemporary-music-focussed, rather than classical-music-focussed - therefore ARTISTSORT takes precedence over COMPOSERSORT, where conflicts arise.
• Our customers are more likely to be contemporary-music-focussed, rather than classical-music-focussed - therefore ALBUMARTISTSORT takes precedence over COMPOSERSORT, where conflicts arise.
• Our customers are more likely to be song-focussed, rather than album-focussed - therefore ARTISTSORT takes precedence over ALBUMARTISTSORT, where conflicts arise.

Of course, a different philosophy (or system architecture) will create a different set of precedences to follow. My examples are just examples, they may not even be logically correct(?) and they are not my own preferences (I am more contemporary-album-focussed myself). Whatever the "rules" are, could then possibly be documented so everyone knows what they are. "First/Last" would probably seem very inconsistent and confusing - because the "rules" would seem to be changing all the time.

So, Emby makes the consistent rules, which then define the coding logic. Of course, consistent and creative tagging gives everyone control over their own set-up, with potentially no conflicts or priority issues to complain about, unless errors are made.

Anyway, getting back to my main concern...

14 hours ago, user24 said:

any method of importing Album tags into Emby would be most useful

With no easy way to currently get Album Tags into Emby (e.g. ROONALBUMTAG) and no native bulk editing of Tags within Emby, it is going to take me about 150 hours to add RELEASETYPE Album tags for my music library - and then, what if I change my mind and want to alter this - another 150 hours??? (Emby is a part-time hobby, not a full-time job - so the initial set-up is likely 6+ months - I could likely do this in 6 weeks with Mp3tag - and ongoing changes would be relatively easy.)

The script that you created lets me set up EXACTLY the custom Discography pages I want, but I don't want to spend all my time on data entry!!!

[GrimReaper 4911]

I think I'll just ditch all the ARTISTSORT/ALBUMARTISTSORT stuff and just focus on release types, which were the subject of this topic to begin with. 

Gimme few hours and I should have something workable. 

[user24 362]

7 hours ago, GrimReaper said:

Emby has no dedicated "Release Type" metadata tag? Under that scenario nothing can be done for that case. There's TYPE tag ("Type": "MusicAlbum") but I don't know is that used for some other Emby's logic and I'd rather not mess with it.

Fair enough - probably my bad wording and I am confusing the issue???  All I really meant was the optimum solution would be RELEASETYPE built-in to Emby. I wasn't meaning that I wanted this resolved by you. Sorry if I am being misleading here. The script is great as is, but the individual data-entry is going to be painful for many thousands of albums.

[GrimReaper 4911]

4 minutes ago, user24 said:

but the individual data-entry is going to be painful for many thousands of albums.

That is what I'm working on. 

On 3/30/2026 at 6:31 PM, GrimReaper said:

I have an idea and wanna try something that might spare you few months of manual tagging

 

[GrimReaper 4911]

Based on this image, wouldn't it be better to take just ROONALBUMTAG and disregard RELEASETYPE tag, as latter contains both Album and track tag? How would software differentiate between those unless there is a set of predefined values? Or there is always just a single "ALBUMTYPE; TRACKTYPE" (comma-separated) in that tag?

Edited Tuesday at 05:51 PM by GrimReaper

[user24 362]

29 minutes ago, GrimReaper said:

wouldn't it be better to take just ROONALBUMTAG and disregard RELEASETYPE tag

Yes, I think that is the best pragmatic approach.

I just put all the tags in that I thought might be useful for testing purposes.

If ROONALBUMTAG is workable, what I would do is create the release type tags in RELEASETYPE in Mp3tag (because that is where they belong) and then copy them into ROONALBUMTAG to be able to import into Emby. It is a trivial task to do the copying. (This is what I am able to do at a track level now with ROONTRACKTAG.)

Yes, it is a ; separator. Just go with ROONALBUMTAG. Ideally it would be a multi-field, if possible, but not a showstopper, if not.

A more practical example as per previous script screenshots woud be:

ROONALBUMTAG: Studio Albums; CDs

In most cases there is only going to be one actual release type per album.

 

Edited Tuesday at 06:21 PM by user24

[GrimReaper 4911]

I'm finding it a bit hard to wrap my head around all the possible branching combinations and permutations:

If you had only this:

21 minutes ago, user24 said:

ROONALBUMTAG: Studio Albums; CDs

Then you cannot have this:

On 3/30/2026 at 7:25 AM, user24 said:

as for that kind of grouping the whole tag would have to literally be: "Studio Albums | Remasters | Remixes etc..."

Also, if you have that and import both  the tags (or multiple tags, there's no issues with that tag being multi-value field), you'll have that album showing twice:

Studio Albums group

CDs group

Also, is it safe to use semi-colon as a delimiter, it will never be a part of the type/group name?

[user24 362]

Yeah, its hard not being in the same room to figure it out.... and I forget you don't use music very much...

In ROONALBUMTAG there would mainly be the release type tags that start with ""

e.g. "Studio Albuns, etc, etc" or ".Live Albums, etc, etc". the full length names I have used

Then these can have the custom sorting order in the script.

There would likely only be one per Album, thus putting the Album into one group only, as most albums per the page screenshot.

Additionally, if i wnat to put an Album into " CDs" because I have that physical CD, then that becomes a second tag in ROONALBUMTAG.

Then that album will appear on the page twice becuase it is in two groups.

semi-colon ;  is very safe to always be the separator for me. It is also commonly used for music and widely used in MP3tag/Emby by others.

 

 

Edited Tuesday at 06:56 PM by user24

[GrimReaper 4911]

3 minutes ago, user24 said:

and I forget you don't use music very much...

I don't use it at all. This is literally the first time I'm encountering these things.

Now, we need to take a step back as there's a disconnection in our mental maps:

Can you tell me, albums in the first group, which tags they have? You can just show me Edit metadata dialog Tags section for one of them.

[user24 362]

Albums in the first group mostly have one tag, as follows:

One Album has two tags as per second screen shot. 

[GrimReaper 4911]

Yes, that's what I was talking about here:

32 minutes ago, GrimReaper said:

If you had only this:

59 minutes ago, user24 said:

ROONALBUMTAG:  Studio Albums; CDs

Then you cannot have this:

On 3/30/2026 at 7:25 AM, user24 said:

Expand  

as for that kind of grouping the whole tag would have to literally be: "Studio Albums | Remasters | Remixes etc..."

If you import ONLY  Studio Albums, it'd be its own tag (and subsequently group), it would not fall under that group (that big, long tag).

We would need to make a mapping table, i.e. ROONALBUMTAG " Studio Albums" -> Import to TAG " Studio Albums | Remasters | Remixes etc..."

[user24 362]

I don't think we need a mapping table???

All we need is to take the single or multiple tags from the ROONALBUMTAG field in the embedded metadata that are:

ROONALBUMTAG tag1; tag2; tag3

separated by semicolon ;

and import them directlly into the Emby Album Tags field:

Tags +Add

tag1

tag2

tag3

If I choose a short tag or a long tag or have been inconsistent, then that is on me to fix in Mp3tag. Emby just needs to be able to import the ROONALBUMTAG tags, as they are defined and do nothing else.

 

 

[GrimReaper 4911]

You are still not understanding me: How will an item that would have only those two tags

- Studio Albums

- CDs

be grouped in that group "Studio Albums | Remasters | Remixes etc." , where grouping is based on the tags themselves?

It needs to have that exact same tag (as your Emby example currently has) to be grouped as such.

Edited Tuesday at 07:34 PM by GrimReaper

[user24 362]

Perhaps best if I send you another set of test files by PM to use? It won't take long to create.

[GrimReaper 4911]

Sure, go ahead.

[user24 362]

On their way, both mp3 and flac...

[GrimReaper 4911]

YES, that's what I was looking for. That tag needs to be present, either mapped from some other tag or imported in full as such. 

[user24 362]

[GrimReaper 4911]

v0.1

Prerequisites:

- Python 3.10+, added to PATH (if installer used, it'll be added automatically)

- Few external libraries (GUI, audio file metadata, API requests), you'll find pip at the beginning of the script or cmd 

pip install PyQt6 mutagen requests

- Configure your server URL & API in the script, didn't want to expose that in the GUI

- Run script by double clicking or cmd 

python C:\path\to\emby_album_tag_writer.py

Needs to be run from a machine that has access both to Emby server and filesystem where music files are stored on (read-only)

Dry-run (nothing written) is ON by default .

Won't post screenshots, want it to be a surprise. 

emby_album_tag_writer.py

Edited Tuesday at 08:33 PM by GrimReaper