A few bespoke issues have risen in other feature requests that could be resolved by an additional enhancement that for want of a better term I am calling "Post-Import Actions". These might be:
Move field X to field Y - if field Y is already populated could overwrite or append (with a separator)
Copy field X to field Y - if field Y is already populated could overwrite or append (with a separator)
Clear Field X
Format Field X - can include other fields combined with fixed text, eg. "(%comment%)"
Having these actions defined in terms of Muso's track database fields avoids the complication of trying to tie them to LMS input fields or standard/extended tags. This would make it possible to feed standard tags into Muso fields that wouldn't naturally receive them - for example Morbeus wanted the standard comment tag to feed a new "Album SubHeading" field (which I want to add, as well as "Disk Sub-Heading"). Or it would allow a field that is normally populated not to be, without having to change the source tags - for example MDE wanted the Album Artist field blanked out.
These post-import actions would kick in on first importing a track into Muso, this is no problem. Updates are more of a problem though, both an LMS and a file scan currently only updates a track if it detects that it needs to, but if post-import actions have already been applied then direct comparison of the input fields with the database fields is no longer good enough - it would have to simulate the actions to determine the end result and so decide whether an update is required. If this proves to be a problem it may have to be a strict post-insert action only. I hope I've explained that well enough.
These post-import actions seem to be akin to mp3tag's actions. I'd want to have a limited number of them though to encourage simplicity, perhaps 5 maximum.
musoware wrote:I have heard of mp3tag actions but not had a chance to investigate their capability - can they copy a standard comment tag to a custom ALBUMRELEASE tag for instance?
musoware wrote:I have heard of mp3tag actions but not had a chance to investigate their capability - can they copy a standard comment tag to a custom ALBUMRELEASE tag for instance?
Action type: Format value
Field: ALBUMRELEASE
Format string: %comment%
I still think the Post-Import Actions in Muso which I raised in a new topic might be a good idea - not everyone uses mp3tag and some still prefer to import from LMS.
Just having a think about this now, but it is far from straightforward. As you say it is pointless replicating mp3tag. Also I think the proper approach is to get the tags right and then use those in Muso. The bit of the tag mapping which has been giving me problems is that a custom tag does not overwrite the standard field if it is blank. Now there are some circumstances when this is the right behaviour, but others when it is not. I am still developing my approach to tagging, along the lines I have posted elsewhere in this forum. This approach is partly driven by the inflexibility of the SB Touch display. I am also trying to make it so that as little manual intervention as possible is required to get the tags right. To add to the complexity, I also convert my FLAC files to mp3 for iTunes to put on my iPod touch (for the car etc.). Tag manipulation can therefore occur in six different places:
1. On ripping, in dBpoweramp
2. After ripping, in dBpoweramp
3. After ripping, in mp3tag
4. On importing to Muso
5. In custom tags in LMS
6. On converting to mp3 files for iTunes
The general approach is to try and get tagging right as early in the process as possible and to make sure that all the key data is stored in custom tags which can then be combined to form the standard tags in a fashion which is optimal for display purposes. This "display" requirement depends on the player and the nature of the album. Where this has taken me so far is to identify three main "profiles" (which will correspond to ripping profiles in dBpoweramp): "Song" (one track works - most popular music and some classical), "Opus" (multi-track works - most classical CDs) and "Book" (large classical ouvres such as operas, Bach's WTC, which have works or other sub-parts of a larger whole). It has also led me to eschew placing composer in artist tags (a practice which I never liked and which thankfully Muso does not need). Composer then gets placed in-line with the title or album depending on the profile ("Opus" profile sets "Album" at the Opus level). This allows Artist to be built (automatically by mp3tag) from the various performer/band/conductor tags and thus display what I want (e.g. "New College Choir, Oxford; The Orchestra of the King's Consort (Cond: Edward Higginbottom); Feat. Rachel Elliott (soprano); Anna Crookes (soprano); Robin Blaze (countertenor); Mark Padmore (tenor); Roderick Williams (bass)").
Why am I saying all this, aside from any general interest? The point is that Muso displays things properly without all these contortions; however, I do not want the built-up Artist tag to be displayed in Muso as well, and just want it to take the "MainPerformer"(s) (a custom tag which originates from the original ripped Artist tag). But sometimes "MainPerformer" is blank (e.g. a Symphony just has Band and Conductor) and if it is mapped on import to Muso to the Artist then it won't replace it. My (current) work-round is to have a "ArtistForMuso" tag which always has something in it, even if it leads to Orchestras being treated as Artists: hopefully I can ditch this if there is a better solution.
To sum up (and to try and answer the question), I think you should keep any internal customised processing to a minimum, but to allow Muso to display the tags that the user wishes to see. The specific problems I have come across would all be addressed by allowing the user to specify "Blank tags to over-write standard field?" or not, for each tag mapping line. It may be that I have missed something and if so I will post it.
Sorry about the long post, but I thought the background would be helpful.
A checkbox next to each custom tag which is headed "Use blank value" might be useful for you then - it would then use a blank value if specified and even assume a blank value if the custom tag doesn't exist, thus clearing the muso field it is mapped to. That's an easy enough mod I think.
I'm still considering the import actions as a separate requirement though, so please anyone else chirp up if they think this would enhance Muso.
Correct. And I will comment if I see the need for the "post-import" action.
EDIT The check box is only needed for tags mapped onto standard fields
EDIT2 If I map Movement to Title then I would leave the box unchecked, to avoid blank titles.
The need for a checkbox next to each custom tag headed something like "Use blank value" has been identified on another thread, it's better recorded here with this requirement for completeness - if set this would use a blank value if specified and even assume a blank value if the custom tag doesn't exist, thus clearing the muso field it is mapped to.
EDIT: Actually I think it should always use a blank value if the custom tag exists and it's set to blank, the extra option though should allow the target field to be cleared even if the custom tag does NOT exist.
MDE wrote:Correct. And I will comment if I see the need for the "post-import" action.
EDIT The check box is only needed for tags mapped onto standard fields
EDIT2 If I map Movement to Title then I would leave the box unchecked, to avoid blank titles.
Agreed though I'm actually implementing the checkbox the other way around, so it reads "Tag Must Exist" so for your EDIT2 above you'd check the box.