(And I still have the duplicated album issue to resolve, but hopefully that is not too difficult).
Thanks for all your help.
Lost the plot?
Re: Lost the plot? - album name
The third concurrent issue is that the breaking of the album name at the semi-colon is still happening (just for the m4a file). See below and compare with the FLAC version above.
Maybe I should have split these into 3 separate bugs, but they all occurred simultaneously with the re-import and it was not initially clear what was what (and probably still isn't!).
(And I still have the duplicated album issue to resolve, but hopefully that is not too difficult).
Thanks for all your help.
(And I still have the duplicated album issue to resolve, but hopefully that is not too difficult).
Thanks for all your help.
Re: Lost the plot? - performer
BTW - as far as I can tell, Muso won't write to the Performer tag on the m4a file either. Will investigate further.
Re: Lost the plot?
I would prefer a separate thread for each issue as it's easy to lose track in threads like this.
OK so I have just issued a patch which should fix your issue with group header appearing in the track name. Strictly speaking this was not a bug because you actually have it in your track name field data - is there no way you can strip this before you import it to Muso? I think I did this for you as a special case before but may have reverted it at some point as it's a non-standard way of dealing with track titles, looking ahead it's not sensible to build in workarounds to specific users' custom requirements as it may adversely affect other users.
The issue with the album name truncating at the semi-colon I cannot reproduce - is it stripping it off on import or only in the album display? It's not always easy to tell which screenshot in this thread applies to m4a or flac so please post details for this specific issue.
And still I cannot reproduce the Performer tag reading issue (from m4a). Are you talking about reading a MAINPERFORMERINST or PERFORMER extended tag or some standard Performer tag? As per Muso's Attribute Mapping tag matrix it expects the performer in a PERFORMER extended tag (there's no column for mpeg4 tags as yet but I'm trying to adhere to the same tag IDs as for flac).
The m4a (mpeg4) tag reading is new to Muso so I think you may find all extended tags are only readable and not writable currently - it's on my TODO list.
OK so I have just issued a patch which should fix your issue with group header appearing in the track name. Strictly speaking this was not a bug because you actually have it in your track name field data - is there no way you can strip this before you import it to Muso? I think I did this for you as a special case before but may have reverted it at some point as it's a non-standard way of dealing with track titles, looking ahead it's not sensible to build in workarounds to specific users' custom requirements as it may adversely affect other users.
The issue with the album name truncating at the semi-colon I cannot reproduce - is it stripping it off on import or only in the album display? It's not always easy to tell which screenshot in this thread applies to m4a or flac so please post details for this specific issue.
And still I cannot reproduce the Performer tag reading issue (from m4a). Are you talking about reading a MAINPERFORMERINST or PERFORMER extended tag or some standard Performer tag? As per Muso's Attribute Mapping tag matrix it expects the performer in a PERFORMER extended tag (there's no column for mpeg4 tags as yet but I'm trying to adhere to the same tag IDs as for flac).
The m4a (mpeg4) tag reading is new to Muso so I think you may find all extended tags are only readable and not writable currently - it's on my TODO list.
Re: Lost the plot?
Thanks for the comprehensive response. I'm sorry about mixing the issues, but when I started the thread I hadn't realised that there were multiple issues.
Regarding titles and groupheadings:
Pleased to say that your patch works in the display, although the Group Header box in Edit Tracks still duplicates the name.
You may recall that my enthusiasm for Muso derived from its ability to deal extremely well with classical music tagging, so I developed a scheme and published it to build on this. Originally, the scheme imported MOVEMENT into TITLE and WORK into GROUPHEADING. So there was no need for any "special processing" of titles by Muso. Then you introduced the ability to write tags, so I thought it would be helpful for the classical music tagging scheme to continue to work if users use Muso for tag amendment, rather than, say Mp3tag (which is what I generally use). Now, if MOVEMENT is stored in the title, Muso writes it out as TITLE. This is no longer consistent with other software, or generally used tagging schemes, where "Work: Movement" is generally the title. In order to provide this consistency, you changed Muso to deal with "Work: Movement" as the TITLE tag but only display MOVEMENT if there was a GROUPHEADING tag. This worked very well and cut out much of the need for extensive import actions. I accept that it may have been a less-than-elegant solution, but it worked. The difficulty is, of course, that conflicting schemes are used by different technologies - I thought I was being helpful in suggesting how Muso could operate successfully in a fairly agnostic way.
Now the iTunes development suggests a different approach, with a flag ("Show Work Movement") to determine whether Movement Name or Title should be displayed (and if the former, grouped under Work). This would be an equally acceptable approach for Muso, I think, if you wished to adopt it, provided the import and write actions are "symmetrical". However I do not think it is consistent to substitute only the movement into the title tag when writing it. An alternative would be to write out title tags as "Groupheading: Movement".
In any case, the last thing I am seeking is "workarounds to specific users' custom requirements". On the contrary I have been trying to make the system useful for all - hence the desire for a consistent approach. I am and will continue to be a big fan of and advocate for Muso.
Regarding the album name:
It is stripping everything after the semicolon on import. "Edit Tracks" only shows the truncated name. This is only on the m4a file.
Regarding the performer tag
As I suspected, this is something to do with dBpoweramp and native/custom tags. Edit ID-tag shows "Performer" as being present in the m4a file. However, Mp3tag does not show it. If I then add it in Mp3tag, then Muso will import it OK. But if I convert a FLAC file with a PERFORMER tag to m4a using dBpoweramp, the resulting Performer tag does not get imported. Messy stuff!
Regarding writing to m4a
I just reported this for your info. I do not need it myself as I only use m4a for iTunes and I keep the FLAC files as the master. If I want to change tags, I change the FLAC files and then re-convert to m4a if I wish.
Regarding titles and groupheadings:
Pleased to say that your patch works in the display, although the Group Header box in Edit Tracks still duplicates the name.
You may recall that my enthusiasm for Muso derived from its ability to deal extremely well with classical music tagging, so I developed a scheme and published it to build on this. Originally, the scheme imported MOVEMENT into TITLE and WORK into GROUPHEADING. So there was no need for any "special processing" of titles by Muso. Then you introduced the ability to write tags, so I thought it would be helpful for the classical music tagging scheme to continue to work if users use Muso for tag amendment, rather than, say Mp3tag (which is what I generally use). Now, if MOVEMENT is stored in the title, Muso writes it out as TITLE. This is no longer consistent with other software, or generally used tagging schemes, where "Work: Movement" is generally the title. In order to provide this consistency, you changed Muso to deal with "Work: Movement" as the TITLE tag but only display MOVEMENT if there was a GROUPHEADING tag. This worked very well and cut out much of the need for extensive import actions. I accept that it may have been a less-than-elegant solution, but it worked. The difficulty is, of course, that conflicting schemes are used by different technologies - I thought I was being helpful in suggesting how Muso could operate successfully in a fairly agnostic way.
Now the iTunes development suggests a different approach, with a flag ("Show Work Movement") to determine whether Movement Name or Title should be displayed (and if the former, grouped under Work). This would be an equally acceptable approach for Muso, I think, if you wished to adopt it, provided the import and write actions are "symmetrical". However I do not think it is consistent to substitute only the movement into the title tag when writing it. An alternative would be to write out title tags as "Groupheading: Movement".
In any case, the last thing I am seeking is "workarounds to specific users' custom requirements". On the contrary I have been trying to make the system useful for all - hence the desire for a consistent approach. I am and will continue to be a big fan of and advocate for Muso.
Regarding the album name:
It is stripping everything after the semicolon on import. "Edit Tracks" only shows the truncated name. This is only on the m4a file.
Regarding the performer tag
As I suspected, this is something to do with dBpoweramp and native/custom tags. Edit ID-tag shows "Performer" as being present in the m4a file. However, Mp3tag does not show it. If I then add it in Mp3tag, then Muso will import it OK. But if I convert a FLAC file with a PERFORMER tag to m4a using dBpoweramp, the resulting Performer tag does not get imported. Messy stuff!
Regarding writing to m4a
I just reported this for your info. I do not need it myself as I only use m4a for iTunes and I keep the FLAC files as the master. If I want to change tags, I change the FLAC files and then re-convert to m4a if I wish.
Re: Lost the plot?
Thanks Mark I know you've been a big help in bringing Muso forward. I'll have a look at the remaining issues later today hopefully.
I've just picked up a trial of dbpoweramp so can look into the specific tagging issues there, if the Performer tag from dbpoweramp is proprietary though I may not be able to access it.
I've just picked up a trial of dbpoweramp so can look into the specific tagging issues there, if the Performer tag from dbpoweramp is proprietary though I may not be able to access it.
Re: Lost the plot?
I assume you mean in the edit fields at the bottom of the grid on multiple row selection ratherthan the edit tracks window?MDE wrote:the Group Header box in Edit Tracks still duplicates the name.
This duplication is useful I think as you can edit out the duplication that exists in the group header and track name:
Before:
Re: Lost the plot?
I assume you mean that you can then make a choice if you wish to retain the work name in the title or not and that removing the duplication will remove the work name from the title. I agree that makes sense, if not entirely intuitive - I'll try and find a suitable way of documenting that on my website.musoware wrote: This duplication is useful I think as you can edit out the duplication that exists in the group header and track name
While the patch works, I do think it is worthwhile considering whether or not there is a better solution. As I mentioned, my goal was to try and eliminate unnecessary import actions, while keeping a symmetry between import and tag writing and a consistency with the "eco-system" in which Muso lives. A major component of this eco-system is LMS, which does not use work and movement on its "now playing" display - hence the need to keep the title in the format "Work: Movement". I suggested some alternative approaches. There may be others.
[Off-topic, so I'll raise elsewhere: the last remaining "unnecessary" import is around artist, performer and instrument. I'll give this a bit more thought and put something under "feature requests" if I have any ideas. I note that MusicBrainz refers to a performer:instrument tag]
Re: Lost the plot?
Note the existing comment on my website (under "sundry jottings"):musoware wrote: I've just picked up a trial of dbpoweramp so can look into the specific tagging issues there, if the Performer tag from dbpoweramp is proprietary though I may not be able to access it.
'MP3Tag does not show the same tags as "Edit ID-tag" in some cases. Sometimes they can show different Albums, Titles and Track Numbers. I have yet to track down the reason for this. The only solution I have found is to use both tools to fix the tags if problems are suspected.'
Foobar does not see the mp4 Performer tag that dbPoweramp creates either, so it does look like a problem with dbPoweramp on the face of it.
Re: Lost the plot?
Latest patch should address the issue with truncating the album name at the ; character for .m4a files.
I'm going to consider dbpoweramp's "Performer" tag outside scope for now.
Was there anything else outstanding apart from writing .m4a extended tags back to the files?
I'm going to consider dbpoweramp's "Performer" tag outside scope for now.
Was there anything else outstanding apart from writing .m4a extended tags back to the files?
Re: Lost the plot?
I think so. The album is fixed. However, the method of dealing with "Work: Movement" is less than ideal, as you have said. I have posted something under "general discussion" on that. As well as being a bit of a "hack", there are some side-effects - the duplication of work name in Group Header is one, which while logical is slightly confusing. Another is that if the Movement genuinely has the same name as the Work, then it gets stripped from the display. I have just ripped John Tavener's "The Protecting Veil". The first and last movements of this are "I. The Protecting Veil" and "VIII. The Protecting Veil". Muso displays these as just "I. " and "VIII. ". Not a surprise, but obviously not quite right. I'd call this a "feature" issue rather than a bug.
My last remaining problem (not sure how it happened) is that the m4a files are all in my shared database as well as the personal one. I assume the way to get rid of these is to only show m4a files and remove them all. Or I could simply hide them.
Many thanks for all your help.
My last remaining problem (not sure how it happened) is that the m4a files are all in my shared database as well as the personal one. I assume the way to get rid of these is to only show m4a files and remove them all. Or I could simply hide them.
Many thanks for all your help.