Flexible Tag Mapping

Feature requests that have been implemented will be filed here.
musoware
Site Admin
Posts: 1847
Joined: Fri Sep 14, 2012 6:50 am

Flexible Tag Mapping

Post by musoware »

MDE1
Sunday, 5:07 PM EST

Problem: Muso is an excellent manager for classical music. Unfortunately most other music software handles it pretty badly. For
example, the otherwise superb SB Touch only displays Title, Artist and Album (and direct from the file metadata, so can't even
use Custom Tags to fix it in LMS). Other players have their own peculiarities. The upshot is that the classical music fan has to
(mis)use standard tags to show useful information. The most common techniques used are (1) use Album to hold the name of the
work, rather than the whole original album source and (2) put Composer in Artist and/or Album Artist. Various approaches are
also used to put additional info in Title. Unfortunately, this results in the Muso displays being less than ideal. For example,
if albums are split into Works which are each given their own Album tag, the gallery displays duplicate album covers - one for
each work. Since Muso handles works within albums so beautifully (via Groupheader) this is a real shame. Similarly, repeating
Composer in Artist tags messes up the presentation.
Proposed solution is in the next post owing to size limit.

MDE1
1. RE: Flexible tag mapping
Sunday, 5:16 PM EST

Proposed Solution: Many classical music fans have attempted to future-proof their tags (in the hope of better software!) by
putting all the key information into Custom Tags (and using Custom Browse in LMS). This enables the standard tags to be re-
created using, say, mp3tag, from the custom tags. So the suggestion is to allow for a more flexible tag mapping function than
that that in the current "Custom Tag" tab of Options. I suggest dividing the tags into 2 sections - the standard tags used by
Muso (Title, Artist, Composer, Album Artist, Album etc) and Custom Tags. The default mapping for the standard tags would be the
obvious ones. Custom Tags would be empty (like the current version). The main difference is that the user would be able to map
custom tags onto standard tags. So, if Album had been used to tag works, but the original album had a custom tag (say, CDName)
the the user could map CDName onto Album in Muso. Work could be mapped to Groupheader (which works now). These mappings would
over-ride the defaults, so if tag "MainPerformer" were mapped to Artist, this would over-ride the Artist mapping. However, many
-to-one mappings would still be possible if explicitly specified. So if, for example, Performer and Band were mapped to Artist
(on separate lines in the table) they would both appear (separated by a specified separator such as ;) in the order in which
they appear in the table.

Ideally this functionality would be present for all import modes, but personally I would be happy with it just for LMS.
Happy to flesh out these thoughts if they are unclear, or to be corrected if I am being stupid/unreasonable.

jezbo
3. RE: Flexible tag mapping
Monday, 8:34 AM EST

I like the idea. Wouldn't the simplest solution just to be to extend the combo-box for "Muso Track Attribute" to additionally include all the standard fields like "Artist" etc? Then you can feed any column you like from custom tags - in the case of standard fields these act as an override. I'm not so convinced that the 2nd half of the equation, to be able to map Standard tags (Artist etc) elsewhere (to one of the custom fields in muso, or another standard field?) would be so useful, and it could also complicate matters.

Incidentally, the file scanner should now use the custom tag configuration too.

jdk-1
4. RE: Flexible tag mapping
Monday, 1:47 PM EST

Excellent idea -- the ability to map custom tags on to standard tags, over-riding the defaults, would make Muso very flexible -- it would also probably put a stop to a lot of other requests for changes to the tagging system.

jezbo
5. RE: Flexible tag mapping
Monday, 2:39 PM EST

"Excellent idea -- the ability to map custom tags on to standard tags, over-riding the defaults, would make Muso very flexible -- it would also probably put a stop to a lot of other requests for changes to the tagging system."

This isn't so difficult to do, if MDE1 would agree it meets the main requirement.

MDE1
6. RE: Flexible tag mapping
Monday, 3:25 PM EST

"This isn't so difficult to do, if MDE1 would agree it meets the main requirement."

I think that just extending the Muso track attribute to include all standard tags would go a long way to meeting the requirement. This would not allow the many-to-one mapping, however, as I think the existing functionality is one-to-one. I am thinking that this might be an issue with the Artist tag, if someone wants to map more than one tag to it, although since Muso supports conductor, band, performer, then I don't see that it is a big need. So, if it is not too difficult, let's try the simple step first, then we can evaluate and feedback. I didn't mean to imply that standard tags might be mapped to custom ones. One minor matter: I have "OPUS" mapped to GroupHeading and have set the "Title in Muso" as "Work". However, it displays as "Group Header".

jezbo
7. RE: Flexible tag mapping
Monday, 4:41 PM EST | Post edited: Monday, 6:26 PM EST

OK I see what you mean by many-to-one mapping, that should be achievable.
And I'll fix the overridden title of a standard muso field (EDIT: see post#9).

Feature Request Accepted In Principle!

jezbo
9. RE: Flexible tag mapping
Monday, 6:28 PM EST | Post edited: Monday, 6:42 PM EST

I think on reflection I'd prefer not to allow the heading of a standard Muso field to be overridden. It's called "Group Header" in Muso because to Muso that's it's function. It would present more coding issues than the rest of this enhancement put together (many UI references to the standard names, non-matching documentation, potential support issues due to misunderstandings, etc), so it's a case of little gain for a lot of pain. So if you pick a standard Muso field the heading will become non-editable (next version).

MDE1
10. RE: Flexible tag mapping
Tuesday, 3:46 AM EST

"I think on reflection I'd prefer not to allow the heading of a standard Muso field to be overridden. It's called "Group Header" in Muso because to Muso that's it's function. It would present more coding issues than the rest of this enhancement put together (many UI references to the standard names, non-matching documentation, potential support issues due to misunderstandings, etc), so it's a case of little gain for a lot of pain. So if you pick a standard Muso field the heading will become non-editable (next version)."

That's not such a problem if you allow many-many mapping (so that, say, OPUS could be mapped to both Groupheading and a custom tag called "Work"). Just a comment on implementing the many-one side of the many-many picture (from a UI point of view): I can see that this might cause problems if this was done on separate lines, eg if you mapped Composer to Album Artist on one line and Performer to Album Artist on another line, since the Titles in Muso might be different. A solution might be to only allow the many-one mapping on one line by separating the tags with the required separator. This neatly (?) deals with the question of ordering and separator symbols as well - eg if you map COMPOSER; PERFORMER to Album Artist, this will make the Album Artist tag a concatenation of "Composer" "; " and "Performer". The one-many side of the many-many mapping presents no such UI problems that I can see, but Muso does not currently support it (I tried mapping OPUS as described above). A subsidiary question is the mapping of blank or dummy tags. Say you wanted to make sure that there was nothing in the Album Artist tag and to let Muso use its intelligence. This could be done by using a tag which is known to be blank and mapping it to Album Artist. However, I think that if you name a non-existent tag (say DUMMY) then this has the same effect?

jezbo
13. RE: Flexible tag mapping
Tuesday, 6:39 AM EST | Post edited: Tuesday, 7:20 AM EST

"That's not such a problem if you allow many-many mapping (so that, say, OPUS could be mapped to both Groupheading and a custom tag called "Work"). Just a comment on implementing the many-one side of the many-many picture (from a UI point of view): I can see that this might cause problems if this was done on separate lines, eg if you mapped Composer to Album Artist on one line and Performer to Album Artist on another line, since the Titles in Muso might be different. A solution might be to only allow the many-one mapping on one line by separating the tags with the required separator. This neatly (?) deals with the question of ordering and separator symbols as well - eg if you map COMPOSER; PERFORMER to Album Artist, this will make the Album Artist tag a concatenation of "Composer" "; " and "Performer". The one-many side of the many-many mapping presents no such UI problems that I can see, but Muso does not currently support it (I tried mapping OPUS as described above). A subsidiary question is the mapping of blank or dummy tags. Say you wanted to make sure that there was nothing in the Album Artist tag and to let Muso use its intelligence. This could be done by using a tag which is known to be blank and mapping it to Album Artist. However, I think that if you name a non-existent tag (say DUMMY) then this has the same effect?"

Mapping both COMPOSER and PERFORMER to Album Artist will be possible - they will be combined with the ; separator (or whatever separator you have configured), in the order that you declare them in the Custom Tags configuration. The title isn't an issue since the new version will not allow you to define one when feeding a standard Muso field, as previously discussed. Blank tags are ignored currently. I'll release this version shortly for you to play with (EDIT: 1.5.14 is there NOW!).

MDE1
14. RE: Flexible tag mapping
Tuesday, 10:02 AM EST

"Mapping both COMPOSER and PERFORMER to Album Artist will be possible - they will be combined with the ; separator (or whatever separator you have configured), in the order that you declare them in the Custom Tags configuration. The title isn't an issue since the new version will not allow you to define one when feeding a standard Muso field, as previously discussed. Blank tags are ignored currently. I'll release this version shortly for you to play with (EDIT: 1.5.14 is there NOW!)."

What you say sounds OK for mapping to a standard Muso field, but I think my point is relevant for mapping more than one tag onto a custom tag. Just had a quick play with 1.5.14. It mapped CDName to Album just fine - very helpful! But I could not map multiple tags to Artist. Also (a problem I had noticed earlier, but not reported), the custom tags seem to get corrupted, even if clearing the database and re-importing. I'll send an email with the details and screenshots since I can't see how to do it in Wetpaint.

jezbo
15. RE: Flexible tag mapping
Tuesday, 11:01 AM EST

"What you say sounds OK for mapping to a standard Muso field, but I think my point is relevant for mapping more than one tag onto a custom tag. Just had a quick play with 1.5.14. It mapped CDName to Album just fine - very helpful! But I could not map multiple tags to Artist. Also (a problem I had noticed earlier, but not reported), the custom tags seem to get corrupted, even if clearing the database and re-importing. I'll send an email with the details and screenshots since I can't see how to do it in Wetpaint."

That's odd. I just mapped some newly invented tags CUSTOM1 and CUSTOM2 to Artist, set these in an album to "Custom 1" and "Custom 2" respectively, and in the import log I see:

Code: Select all

FOLDER IMPORT LOG

FileTypes: .mp3 .mp4 .m4a .flac .ogg .wav .wv .mp2 .wma
Custom Tags: [0] TAG1 [1] TAG1 [2] TAG2 [3] TAG3 [4] NEWALBUMNAME [5] NEWALBUMNAME [6] CUSTOM1 [7] CUSTOM2
Folder: C:\hudba
. Updated Neil Young & Crazy Horse!/Everybody Knows This Is Nowhere!/Everybody Knows This Is Nowhere! : artist=Custom 1;Custom 2
. Updated Neil Young & Crazy Horse/Everybody Knows This Is Nowhere/Round & Round (It Won't Be Long) : artist=Custom 1;Custom 2
. Updated Neil Young & Crazy Horse/Everybody Knows This Is Nowhere/Down By The River : artist=Custom 1;Custom 2
. Updated Neil Young & Crazy Horse/Everybody Knows This Is Nowhere/The Losing End (When You're On) : artist=Custom 1;Custom 2
. Updated Neil Young & Crazy Horse/Everybody Knows This Is Nowhere/Running Dry (Requiem For The Rockets) : artist=Custom 1;Custom 2
. Updated Neil Young & Crazy Horse/Everybody Knows This Is Nowhere/Cowgirl In The Sand : artist=Custom 1;Custom 2
930 songs parsed
0 new songs added
6 songs updated
0 errors
930 files scanned in 00:00:37.0983150
As I'd expect - it saves both tags to the Artist field OK. Are you doing it through the folder scanner or an LMS import?

MDE1
16. RE: Flexible tag mapping
Tuesday, 2:16 PM EST | Post edited: Tuesday, 6:35 PM EST

"That's odd. I just mapped some newly invented tags CUSTOM1 and CUSTOM2 to Artist, set these in an album to "Custom 1" and "Custom 2" respectively.
As I'd expect - it saves both tags to the Artist field OK. Are you doing it through the folder scanner or an LMS import?"


Ah - I think one man's custom tag is another man's standard tag. I considered CONDUCTOR and BAND to be custom tags because LMS does not appear to use them. However, on inspection I see that they are in the LMS database. If I use tag names that are in the "custom scan" but not in the LMS database then it works. So it seems the feature only works if you map tags which are not in the LMS database but are "custom scanned". This seems a little obscure and I don't know if it is necessary to avoid mapping standard tags. If it is necessary, then I think the user needs to be prevented from making mappings that aren't allowed, or maybe at least warned when the import happens; it also means that the user would be wise to create a complete set of shadow tags to use in the mapping (not hard with mp3tag). You will infer that I have only tried the LMS import. I didn't think it was working on folder scanner yet.
BTW, the "corruption" problem appears to be transitory and clears after a while, which is why I didn't report it earlier. It was definitely there (mis-named and mis-mapped custom tags) but must have disappeared when I went back to do the screenshot, which I hadn't spotted.
EDIT Now I've seen the table at http://muso.wetpaint.com/page/Attribute+Mapping, this helps to explain it, as LMS internal db names are used for "LMS standard" tags.

jezbo
17. RE: Flexible tag mapping
Wednesday, 9:25 AM EST | Post edited: Wednesday, 12:20 PM EST

Yes just to confirm : muso's Custom Tag facility only works on custom tags (hence its name) - or Extended tags as mp3tag calls them - those set in the files on a file scan, or those registered in the LMS custom tag plugin if you import from LMS. As such it's not currently possible to redirect a standard tag/LMS field to another field in Muso (unless it's copied to a custom tag), though it has been made possible now to redirect custom tags to standard Muso fields.

For vorbis flac tags, as I understand it all tags are stored the same way, so when file-scanning these it is possible to redirect the standard tag IDs to different muso fields, though I'm not sure (yet) if registering standard tags like ARTIST, COMPOSER, PERFORMER etc in the LMS custom tag plugin will feed these through to be picked up by muso's custom tag mechanism in the same way as file-scanning.

80.229.137.20
18. RE: Flexible tag mapping
Yesterday, 7:24 PM EST

"Yes just to confirm : muso's Custom Tag facility only works on custom tags (hence its name) - or Extended tags as mp3tag calls them - those set in the files on a file scan, or those registered in the LMS custom tag plugin if you import from LMS. As such it's not currently possible to redirect a standard tag/LMS field to another field in Muso (unless it's copied to a custom tag), though it has been made possible now to redirect custom tags to standard Muso fields.
For vorbis flac tags, as I understand it all tags are stored the same way, so when file-scanning these it is possible to redirect the standard tag IDs to different muso fields, though I'm not sure (yet) if registering standard tags like ARTIST, COMPOSER, PERFORMER etc in the LMS custom tag plugin will feed these through to be picked up by muso's custom tag mechanism in the same way as file-scanning. "


First impressions are that directly importing from the song files is going to be better than going via LMS as it is quicker (only one scan not 2 [or 3 if you include custom scan]) and saves setting up all the custom tags in custom scan. Will feedback more once I have had a while to play with it.
MDE
Posts: 479
Joined: Sat Feb 02, 2013 12:05 am

Re: Flexible Tag Mapping

Post by MDE »

I've had a few days to look at the flexible mapping now and it seems to work very well. Even thought I use LMS, I now find it better to import the song files directly, which gives more flexibility in using the tags and means that you don't have to do a LMS scan so much. (NB, the LMS scan in the new versions is quite fast, but the Custom Scan is still slow).
I have set out below, the ripping and tagging process I am now using for classical music (although I think it works OK for popular music too). No doubt this can be improved (and it may be better putting this in a separate thread).

I use dBpoweramp for ripping and populate the tags as follows:
Album - (Case 1) "Composer(s): Works/Album name etc" or (Case 2) "Artist: Album name" if there is one featured artist and many composers or (Case 3) just "Album Name" for compilations and pop.
Album Artist - What you will. Usually "Composer1; Composer2 etc" for Case 1. "Artist" for Case 2 or blank for Case 3.
Composer - full name of composer of each track.
Title - in format "Work: Movement" with no other colons. This is format often used by MusicBrainz. If no separate movements then just use Work.
Artist - the full name of the main performing artist (may be more than one, e.g. for duets) - may be blank for orchestral pieces.
Instrument - Instrument of the main artist (e.g. "Piano", or "Tenor" for a singer).
Band - full name.
Conductor - full name.
Performer - All other performers, not including artist, band or conductor, separated by semi-colons.

After ripping, I run an mp3tag action (I can supply if anyone is interested) to map the following tags:
Album -> CDName
Album Artist -> CDArtist
Artist -> MainPerformer, Artist Sort (sorted)
Composer -> Album Artist, ComposerSort (sorted)
Conductor -> ConductorSort
Mainperformer (Instrument), Band (Cond: Conductor), Feat. Performer -> Artist
Title -> Opus, Movement (split using "Guess values")
The sorted fields are only used by LMS, not Muso.

Then in Muso options, I map the following custom tags, using import from the files, not LMS:
MainPerformer, Instrument -> Artist (see note below)
CDName -> Album (just in case the album name is the work)
Blank -> Album Artist
Opus -> GroupHeading, Work
Performer -> Performer (not sure if this is necessary)

The result is that Muso shows the album in "CD Insert" style and the SB touch displays all the relevant information on the scrolling display (with the most useful info at the beginning of each line). Although it looks a bit complicated, the complex bits are automated.
There are a couple of snags so far:
1. Muso only has 10 custom tag mappings. As well as the above, I use Instrument and Period, so it is a bit tight.
2. The mapping of Instrument to Artist in Muso is clearly a fudge and displays "Artists: Andras Schiff, Piano" (i.e. plural) and treats the instrument as an artist (can be got around using custom field - if there are any left - in hierarchy)
Hopefully (1) is fairly easy to fix with a few more fields, but (2) needs a bit more thought; for instance it would be nice to display all performers as "Performer (Instrument)". Any ideas?
An afterthought: I see the album title now has label and year listed (in different ways). Is it possible to put a custom field such as Instrument in the display?
musoware
Site Admin
Posts: 1847
Joined: Fri Sep 14, 2012 6:50 am

Re: Flexible Tag Mapping

Post by musoware »

I haven't gone over your config in detail, but it shouldn't be too much effort to increase the custom tag configuration to 15 or 20. Won't the ability to hold Instrument separately resolve your issue? I could extend the album view to show custom fields in the header also (when consistent across all tracks), so you'd see Instrument: Piano in the header after the performer - but then there's the question of whether to do the same at track and track group level, and I don't think there's room there.
MDE
Posts: 479
Joined: Sat Feb 02, 2013 12:05 am

Re: Flexible Tag Mapping

Post by MDE »

I would say "Instrument: Piano" after Artist in the header.
Not sure about track level. In any case, I'm not sure what is the best way to tag instruments per performer, if at all - it might just be best to include in the performer tag i.e "Performer (Instrument)". In which case, it is a possibility to do the same for MainPerformer (maps to Artist), which would obviate the need for "Instrument: Piano". It would be nice to evaluate the pros & cons of each approach. "Performer (Instrument)" might mess up the sorting and other views of course, unless () is ignored.
musoware
Site Admin
Posts: 1847
Joined: Fri Sep 14, 2012 6:50 am

Re: Flexible Tag Mapping

Post by musoware »

That's what I do: eg. "Alfred Brendel (piano)", mind you having Instrument as a separate field would allow you to group all piano pieces together in the hierarchy - I'd never find the time to invest in retagging my whole library though!
musoware
Site Admin
Posts: 1847
Joined: Fri Sep 14, 2012 6:50 am

Re: Flexible Tag Mapping

Post by musoware »

MDE wrote:I've had a few days to look at the flexible mapping now and it seems to work very well. Even thought I use LMS, I now find it better to import the song files directly, which gives more flexibility in using the tags and means that you don't have to do a LMS scan so much. (NB, the LMS scan in the new versions is quite fast, but the Custom Scan is still slow).
In general I import from the filesystem rather than LMS anyway because it's faster, since I create a new folder for each month and put my new albums in the current month folder. So I only need to import from that folder (since I flag it for a "Quick Scan") rather than scanning the whole file-structure. I also ensure that the option to "check updated meta-data on import" is turned off (unledd I know I have changed something that I want to pull in), otherwise it has to read all the tags on all the files it scans.

I can push a new album to LMS without an LMS rescan being done first, this in effect adds the new album to the LMS database. I rarely do an LMS rescan.

I still import from LMS into Muso periodically to synronize ratings : there may be some in LMS but not muso if I have spent some time listening to music away from my muso PC, and I have rated tracks in LMS via the remote (as trackstat allows you to do), and there may be some rated in Muso but not LMS (and I want them to be so that I can see the rating on the device display). One impact of importing from the folders rather than LMS is that the LMS track ID is not known in Muso until you next import from LMS - as a result you don't get new ratings in Muso pushed immediately to LMS when you rate them, but they are synched on the next LMS import.

Note that when you import new tracks from folders, the path in muso is stored as the muso PC knows it (eg. \\192.168.0.99\files\music\flac\2013_01\...), whereas when a new track is registered in muso from an LMS import the path is as LMS knows it (eg. \storage\music\flac\2013_01\...), but with the mapping set up properly this doesn't matter - it can associate these different paths with the same file.
Morbeas
Posts: 246
Joined: Fri Feb 01, 2013 3:07 pm

Album release version

Post by Morbeas »

Pretty much for every track in my library, there is an entry in the COMMENT tag that describes which version of the album it belongs to (Original release, remaster, re-issue etc). What I would like to do is display this information as I'm browsing the albums. I was hoping it could be displayed in parenthesis next to the album title.

Thoughts?
Morbeas
Posts: 246
Joined: Fri Feb 01, 2013 3:07 pm

Re: Album release version

Post by Morbeas »

Something like this would be perfect.
Attachments
Clipboard01.jpg
Clipboard01.jpg (105.8 KiB) Viewed 28892 times
Morbeas
Posts: 246
Joined: Fri Feb 01, 2013 3:07 pm

Re: Album release version

Post by Morbeas »

...
Attachments
Clipboard01.jpg
Clipboard01.jpg (125.11 KiB) Viewed 28891 times
RichG
Posts: 215
Joined: Fri Feb 01, 2013 4:46 pm

Re: Album release version

Post by RichG »

The way I'm dealing with this is to give all the versions the same basic album name, number the disk separately (original will be disk 1, remaster disk 2, etc ..) and then use the group name for the release version.

This way you get a single album appearing in the main browser but when you go into that album page you can see and select to play the different versions easily.

This may not be what your after exactly but it suits me well.

[BTW this is one of the reasons I'd like to see the RMB menu extended to groups and disks]
Post Reply