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
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.