I'm actually now thinking of simplifying all this, custom tags included, to be Action based. So for any target field in Muso you could define a special override which can include placeholders for other fields and custom tags. So:
{Album} = [CDName] - read Album from custom tag
{Artist} = {Composer} - copy the standard Composer field to the Artist field (overwrite if necessary)
{Performer} += {Composer} - append Composer to Performer (will add ; separator if both exist).
{AlbumArtist} = [BLANK] - base albumartist on custom tag
{AlbumSubHeading} = ({comment}) - copy comment field to AlbumSubHeading (will be new field) and surround it with round brackets
{Comment} = "" - and then clear the comment field
It would apply them in the order you specify them (important if you consider the last two). {Composer}, {Performer} etc are standard field placeholders (predefined), whereas [CDName], [BLANK] are directives to look up and use any custom tag the user chooses to use.
I think this is simpler than combining Custom Tags with Actions. Just thinking out loud at present, need to think it through.
Flexible Tag Mapping
Re: Post-Import Actions
MDE - thanks for the interesting posts, you've obviously given this a fair amount of thought.
For myself, I also believe in getting the tags in the files right to begin with, and for the majority of my music I have no problem as they use very standard / basic tagging. However, with classical music, which is about 15 - 20% of my music, and a few others it starts to get more complicated. Up to now I've managed without making use of the custom tag import functions (I don't use custom tags in LMS either), although I do have to spend much more time getting the tags in place to begin with (I mostly use Tag&Rename and Foobar for this) and I have found that the standard tags serve my purposes (I probably don't have the same demands as others might) and don't really care too much what is shown on my SB screen (it sits across the room and rarely gets touched since getting Muso).
What I do care is that the tags work in other software too - partly because of concerns that LMS may well not last for too much longer - and I don't want to have to re-tag a lot my music again in the future. For this reason I would rather that Muso worked well with the standard tags (which it does) and didn't require me to faff around to get things to work.
For these reasons I don't think the Post-Import Actions will be of much value to me, but can see its potential for others.
For myself, I also believe in getting the tags in the files right to begin with, and for the majority of my music I have no problem as they use very standard / basic tagging. However, with classical music, which is about 15 - 20% of my music, and a few others it starts to get more complicated. Up to now I've managed without making use of the custom tag import functions (I don't use custom tags in LMS either), although I do have to spend much more time getting the tags in place to begin with (I mostly use Tag&Rename and Foobar for this) and I have found that the standard tags serve my purposes (I probably don't have the same demands as others might) and don't really care too much what is shown on my SB screen (it sits across the room and rarely gets touched since getting Muso).
What I do care is that the tags work in other software too - partly because of concerns that LMS may well not last for too much longer - and I don't want to have to re-tag a lot my music again in the future. For this reason I would rather that Muso worked well with the standard tags (which it does) and didn't require me to faff around to get things to work.
For these reasons I don't think the Post-Import Actions will be of much value to me, but can see its potential for others.
Re: Post-Import Actions
I think I get that, although I think it would be worthwhile try to make the syntax a bit more intuitive and consistent with other programming/macro styles (e.g. not confusing an assignment operator with an equality condition which could cause problems if conditional statements are later included). I also see how you are trying to cover some slightly different requirements in a common way. However, I can't see how the optionality to overwrite or not if the custom tag is blank is achieved with this (unless of course, you do add an "if then" syntax, which I imagine makes the parsing a tad more complex).musoware wrote:I'm actually now thinking of simplifying all this, custom tags included, to be Action based. So for any target field in Muso you could define a special override which can include placeholders for other fields and custom tags....
I'm going off custom tags in LMS partly because the interface is so clunky compared with Muso and also because Custom Scan takes ages - direct import seems so much cleanerRichG wrote:...Up to now I've managed without making use of the custom tag import functions (I don't use custom tags in LMS either),...
My laptop is in my study, not my lap, so I find it useful, but otherwise I agree. In fact of greater importance for me than the SB touch is my iPod touch. It would be nice to have an app that was as well thought out as Muso. I find iPeng frustrating and the SB app a bit limiting. BTW, when I'm working on the computer I find Kinsky desktop quite a useful "now playing" strip.and don't really care too much what is shown on my SB screen ...
Agreed. But it is these concerns that have caused me to place the key metadata components in custom tags so that the standard ones can be reconstructed by a macro to suit whatever the player of the future is. (Maybe a forlorn attempt at future-proofing)What I do care is that the tags work in other software too - partly because of concerns that LMS may well not last for too much longer - and I don't want to have to re-tag a lot my music again in the future.
Agreed again, but it is the other software that makes me faff around. Maybe I am trying too hard After all with Muso I can now find the music I want and tee up an evening's listening, so I should just sit back and relax.For this reason I would rather that Muso worked well with the standard tags (which it does) and didn't require me to faff around to get things to work.
Re: Post-Import Actions
Yes the syntax could be simplified probably. I wouldn't want to get into IF conditions I don't think.MDE wrote:I think I get that, although I think it would be worthwhile try to make the syntax a bit more intuitive and consistent with other programming/macro styles (e.g. not confusing an assignment operator with an equality condition which could cause problems if conditional statements are later included). I also see how you are trying to cover some slightly different requirements in a common way. However, I can't see how the optionality to overwrite or not if the custom tag is blank is achieved with this (unless of course, you do add an "if then" syntax, which I imagine makes the parsing a tad more complex).
I'm trying to think of an example where you might want a whole action conditional on the existence on an input tag. If a custom tag is specified in an action and it didn't exist in the source track, it could either substitute the empty string or fail the action - that could be a tickbox option on each action if it's needed.
Re: Flexible Tag Mapping
Just been checking out v 1.22
The check boxes don't operate for custom tags which are mapped to standard fields. So in my example where MOVEMENT is mapped to TITLE, if Movement does not exist, I can't make it revert to Title. Interestingly, though, in this case it does not put a blank there, but uses the filename. Mapping MainPerformer to Artist will put blanks in, which is what I want.
I don't see the point of having the check box for the "pure" custom tags as there is nothing to default to if the imported tag is empty.
Am I missing something?
The check boxes don't operate for custom tags which are mapped to standard fields. So in my example where MOVEMENT is mapped to TITLE, if Movement does not exist, I can't make it revert to Title. Interestingly, though, in this case it does not put a blank there, but uses the filename. Mapping MainPerformer to Artist will put blanks in, which is what I want.
I don't see the point of having the check box for the "pure" custom tags as there is nothing to default to if the imported tag is empty.
Am I missing something?
Re: Flexible Tag Mapping
OK One thing is that I got the enabling of the checkbox round the wrong way - it should be enabled if you map to a standard field. And I'll stop it deducing title from filename if its otherwise blank.
Re: Flexible Tag Mapping
Just put a new build of 1.5.22 there now with these fixes.
Re: Flexible Tag Mapping
I can see that you really don't want blank titles, so there's nothing wrong with it deducing it from filename, so long as it defaults to Title first if the custom tag is blank.
Will check out the new build.
Will check out the new build.
Re: Flexible Tag Mapping
New build seems to work OK, thanks
Re: Album release version
Thank you so much! But can I have the release info in parenthesis please? (I know, the nerve!).