2015-07-06, 17:10
The ARTISTS tag PR recently got merged which will help a lot I think.
2015-07-15, 17:38
(2015-07-06, 17:06)bigbig6 Wrote: I'm not a classical music's aficionados, but this resquest sound great for me.
I can't help you in anyway, but will love it. Classical music can't be handled just like other kind of music...
A+
+1 here
Just ripping and carefully tagging my classical mucic CD collection to FLAC having already ripped the "pop". The lack of Kodi support for managing this kind of music is really disappointing, especially when it does so much else so well. The workaround of having composer as ALBUMARTIST and the resulting mixed library of pop artists and composers is horrible IMHO.
Was thinking of doing my own thing (another with 30 years of software dev experience - the skills if only I had the time etc.), then I came across this thread. Anyone progressed with this?
Quote:Just out of interest what tags would you like to be read in Kodi for classical music?
From that list of extended tags COMPOSER is a must (COMPOSERSORT along with ARTISTSORT would be nice, first name order or having to reverse the name is less user friendly than Kodi is for video etc.), CONDUCTOR too. I have been including BAND and PERFORMER in my FLAC files for orchestra and soloists, in vain hope that I will use that info one day, but FLAC can have any tags.
2015-07-15, 18:50
If you take a look at "evilhamster" recent PR on the XBMC repository you can see its actually quite easy to add new tags to the software. All we require is a pull request to add features. It will need a database bump as well to store the new tags.
Another developer also recently added the "mood" tag so you can see his changes in the Kodi software for that also.
Any developer with a few hours could add these new tags, that at least could be a starting point.
Another developer also recently added the "mood" tag so you can see his changes in the Kodi software for that also.
Any developer with a few hours could add these new tags, that at least could be a starting point.
(2015-07-15, 18:50)zag Wrote: If you take a look at "evilhamster" recent PR on the XBMC repository you can see its actually quite easy to add new tags to the software. All we require is a pull request to add features. It will need a database bump as well to store the new tags.OK Zag, I'll bite, the tags would be a good start.
Another developer also recently added the "mood" tag so you can see his changes in the Kodi software for that also.
Any developer with a few hours could add these new tags, that at least could be a starting point.
Just need to get a dev environment set up at home, a test build of Kodi etc..... and discover how a Kodi nubie gets to contribute code and be taken seriously. Got any links to help me get started as a Kodi contributer? Been a while since I got my hands dirty with C++
Regarding tags am I limited to choosing from the list you gave? Before I just do what I think, anyone else have an opinion on useful tags for managing classical music? Is there better forum to ask this question?
My thoughts on tags....
As ID3 tags as well as Vorbis, adding COMPOSER (TCOM) and CONDUCTOR (TPE3) are obvious.
Staying within ID3 I would add TIT1 (content group) and TIT3 (Subtitle). In mp3 files TIT1 could be used for the work (e.g. Symphony no. 5), although due to the players many people may currently have that at the start of TIT2 (title) along with the movement etc. Non-Kodi users may have used TIT1 for album rather than TALB (ALBUM), but that is their problem! Allowing TIT3 to refine the title while we are at it makes sense for classical music.
I have seen the equivalent Vorbis tags listed as either GROUPING or CONTENTGROUP and SUBTITLE. Given the variations and Vorbis flexibity, it is temping to suggest using WORK as a custom tag in place of GROUPING or CONTENTGROUP, or maybe load all variants the same.
Without proliferating useless fields, I believe that ARTIST (or ALBUMARTIST) is not a substitute for separate ENSEMBLE and PERFORMER tags. In music data terms Rolling Stones or Katy Perry are not the same kind of thing as Liza don Getti (soprano soloist) or Berliner Philharmoniker. As someone with a large collection that spans both classical and non-classical music this differentiation is important, I really don't want all the classical soloists (and other individual performers singled out for mention), orchestras, quartets etc. listed along with my pop groups and solo artists. But I would like to be able to access this information - display it, search for it etc. - and for that it needs to be in the music database.
Hence for FLAC files I propose adding handling for ENSEMBLE and PERFORMER(s) tags. Ensemble appears as a known but unprocessed tag in Kodi code, not sure what the history is.
All my files are FLAC, but what about mp3? ID3v2 has a slew of frames for various kinds of artists:
TPE1 Lead performer(s)/Soloist(s)
TPE2 Band/orchestra/accompaniment
TPE3 Conductor/performer refinement
Players, inc Kodi, use TPE1 as Artist and TPE2 as AlbumArtist which works fine for non-classcial, but mix classical in there and it gets messy. Plenty of people complain how ID3 not best approach for classical, but no real solutions proposed. So do I use custom TXXX tags, co-op the TPE4, TOPE and TMCL tags, or leave mp3 classical music users to sort their own patch?
2015-07-16, 15:16
Well I'd start slow with a single standard tag that is important with classical music.
Kodi development is done in very small chunks so one step at a time.
If you manage to get some working code, you will need to use GitHub to create a Pull Request. Full guide here http://goo.gl/Z6vQWz
I can't help much on the C++ side though, still need to learn it myself!
Kodi development is done in very small chunks so one step at a time.
If you manage to get some working code, you will need to use GitHub to create a Pull Request. Full guide here http://goo.gl/Z6vQWz
I can't help much on the C++ side though, still need to learn it myself!
2015-07-17, 11:16
(2015-07-16, 14:40)DaveBlake Wrote:(2015-07-15, 18:50)zag Wrote: If you take a look at "evilhamster" recent PR on the XBMC repository you can see its actually quite easy to add new tags to the software. All we require is a pull request to add features. It will need a database bump as well to store the new tags.OK Zag, I'll bite, the tags would be a good start.
Another developer also recently added the "mood" tag so you can see his changes in the Kodi software for that also.
Any developer with a few hours could add these new tags, that at least could be a starting point.
Just need to get a dev environment set up at home, a test build of Kodi etc..... and discover how a Kodi nubie gets to contribute code and be taken seriously. Got any links to help me get started as a Kodi contributer? Been a while since I got my hands dirty with C++
Regarding tags am I limited to choosing from the list you gave? Before I just do what I think, anyone else have an opinion on useful tags for managing classical music? Is there better forum to ask this question?
My thoughts on tags....
As ID3 tags as well as Vorbis, adding COMPOSER (TCOM) and CONDUCTOR (TPE3) are obvious.
Staying within ID3 I would add TIT1 (content group) and TIT3 (Subtitle). In mp3 files TIT1 could be used for the work (e.g. Symphony no. 5), although due to the players many people may currently have that at the start of TIT2 (title) along with the movement etc. Non-Kodi users may have used TIT1 for album rather than TALB (ALBUM), but that is their problem! Allowing TIT3 to refine the title while we are at it makes sense for classical music.
I have seen the equivalent Vorbis tags listed as either GROUPING or CONTENTGROUP and SUBTITLE. Given the variations and Vorbis flexibity, it is temping to suggest using WORK as a custom tag in place of GROUPING or CONTENTGROUP, or maybe load all variants the same.
Without proliferating useless fields, I believe that ARTIST (or ALBUMARTIST) is not a substitute for separate ENSEMBLE and PERFORMER tags. In music data terms Rolling Stones or Katy Perry are not the same kind of thing as Liza don Getti (soprano soloist) or Berliner Philharmoniker. As someone with a large collection that spans both classical and non-classical music this differentiation is important, I really don't want all the classical soloists (and other individual performers singled out for mention), orchestras, quartets etc. listed along with my pop groups and solo artists. But I would like to be able to access this information - display it, search for it etc. - and for that it needs to be in the music database.
Hence for FLAC files I propose adding handling for ENSEMBLE and PERFORMER(s) tags. Ensemble appears as a known but unprocessed tag in Kodi code, not sure what the history is.
All my files are FLAC, but what about mp3? ID3v2 has a slew of frames for various kinds of artists:
TPE1 Lead performer(s)/Soloist(s)
TPE2 Band/orchestra/accompaniment
TPE3 Conductor/performer refinement
Players, inc Kodi, use TPE1 as Artist and TPE2 as AlbumArtist which works fine for non-classcial, but mix classical in there and it gets messy. Plenty of people complain how ID3 not best approach for classical, but no real solutions proposed. So do I use custom TXXX tags, co-op the TPE4, TOPE and TMCL tags, or leave mp3 classical music users to sort their own patch?
Have a read here https://github.com/xbmc/xbmc#quick-kodi-...ment-links
2015-07-24, 13:29
Thanks for the Github link Zag, and the others generally Razze. Programming language is not a problem, the initial mountain to climb is building a dev environment with all the tools etc. and getting the original code to build. I am also dallying for a new home PC, at 13 years it is finaly ready to be replaced!! Let the downloads and installations commence.....
Also wondering if the OP (or anyone else) has done any work on this yet?
I am having second thoughts on whether just adding tags as new data fields is the best way to proceed. Musicbrainz treats composer as just another artist, conductor, orchestra and soloist are definitely artists. One of the ways that Kodi is unfriendly to classical music is although you can get all the above into the library as "artists" they are then presented all together making music selection cumbersome.
Another approach would be to store how each artist is releated to a song. Currently we have a "featured" flag for artists that are not an album artist, how about having a list of categories instead - main artist, featured artist, conductor, orchestra, composer. It could even be extended to indicate what kind of instrument a soloist is using. A screen that shows only those artists that are composers would be easy from there, or say just the conductors, or main artists (the current display).
But again I probably should not be talking implementation in this forum, just not sure where else to discuss it.
Also wondering if the OP (or anyone else) has done any work on this yet?
(2015-07-16, 15:16)zag Wrote: Well I'd start slow with a single standard tag that is important with classical music.I can see the wisdom in that, don't run before I can walk. But it may not be easy to take small steps and actually improve things for classical music, otherwise someone would have done it already.
Kodi development is done in very small chunks so one step at a time.
I am having second thoughts on whether just adding tags as new data fields is the best way to proceed. Musicbrainz treats composer as just another artist, conductor, orchestra and soloist are definitely artists. One of the ways that Kodi is unfriendly to classical music is although you can get all the above into the library as "artists" they are then presented all together making music selection cumbersome.
Another approach would be to store how each artist is releated to a song. Currently we have a "featured" flag for artists that are not an album artist, how about having a list of categories instead - main artist, featured artist, conductor, orchestra, composer. It could even be extended to indicate what kind of instrument a soloist is using. A screen that shows only those artists that are composers would be easy from there, or say just the conductors, or main artists (the current display).
But again I probably should not be talking implementation in this forum, just not sure where else to discuss it.
2015-07-24, 20:41
Same as zag, I have a very limited knowledge about classical music but the topic about tagging kind of interest me
Getting a dev environment up and running is not that hard, a good starting point is http://kodi.wiki/view/Compiling
I don't think adding new tags that only kodi supports or some special solution that only kodi understands is a good idea, better to build upon something that already exists out there. Musicbrainz is probably a good starting point, because as the kind of hard dependency kodi has on musicbrainzid's.
There is a good document on https://musicbrainz.org/doc/Style/Classical that describes the style guide that musicbrainz uses for classical music.
The good news is that they contain a work description and work id, so if support for that is implemented it should be possible to browse on work's the same way as artist or similar in kodi.
Some bad news is that they seem to use the track artist field for the composers, https://musicbrainz.org/doc/Style/Classi...ack/Artist, but from what I can tell there is no flag that says if a track is classical or not which would make it hard to separate composers from pop/rock artists.
They store the information about performers in a track in a field called musiciancredits that contains an entry like piano:András Schiff, but they dont seem to save the mbrainzid for anywhere (except for the artist that are prominent enough to be included in the albumartist field), so it would be hard to avoid mixups between artists with the same name. Would be solvable if you use the scrapper to fetch this information but would be nice if it could work even for those that have their kodi offline.
To my knowledge there is only a artist <-> album and artist <-> song relationships and there is no difference in those if an artist is featured or not (but I could be wrong, don't have that much experiance with the kodi code). Could probably update the artist <-> song relationship to keep track of all the information that musicbrainz store about a recording (both for pop/rock and classical). Not sure if the best way forward is to extend the existing one or create a new relationship just for these cases.
Not sure I helped, but hopefully
Getting a dev environment up and running is not that hard, a good starting point is http://kodi.wiki/view/Compiling
I don't think adding new tags that only kodi supports or some special solution that only kodi understands is a good idea, better to build upon something that already exists out there. Musicbrainz is probably a good starting point, because as the kind of hard dependency kodi has on musicbrainzid's.
There is a good document on https://musicbrainz.org/doc/Style/Classical that describes the style guide that musicbrainz uses for classical music.
The good news is that they contain a work description and work id, so if support for that is implemented it should be possible to browse on work's the same way as artist or similar in kodi.
Some bad news is that they seem to use the track artist field for the composers, https://musicbrainz.org/doc/Style/Classi...ack/Artist, but from what I can tell there is no flag that says if a track is classical or not which would make it hard to separate composers from pop/rock artists.
They store the information about performers in a track in a field called musiciancredits that contains an entry like piano:András Schiff, but they dont seem to save the mbrainzid for anywhere (except for the artist that are prominent enough to be included in the albumartist field), so it would be hard to avoid mixups between artists with the same name. Would be solvable if you use the scrapper to fetch this information but would be nice if it could work even for those that have their kodi offline.
To my knowledge there is only a artist <-> album and artist <-> song relationships and there is no difference in those if an artist is featured or not (but I could be wrong, don't have that much experiance with the kodi code). Could probably update the artist <-> song relationship to keep track of all the information that musicbrainz store about a recording (both for pop/rock and classical). Not sure if the best way forward is to extend the existing one or create a new relationship just for these cases.
Not sure I helped, but hopefully
2015-08-14, 19:31
I am moving slowly forward with this, well I have got a dev environment going and I'm twiddling with a clone out of Github. Need a machine with more grunt though, Visual Studio is killing it.
My start point is to get Kodi to capture composer, conductor, orchestra information from tags (all standard just Kodi does not currently handle them). Adding this role infomation to the artist credits so that we can differentiate beween composers, conductors, orchestras, and general (pop) performers, rather than the current big mixed bucket of artists that I find so user unfriendly. And then extend the user interface so that users can easily view artists by role. The ability to categorise artists by role may have uses beyond classical music, so DJs or Engineers etc. can be included in artist credits without making the artist list unwieldy.
Thanks for input EvilHamster. Musicbrainz does know the difference between a composer and a peformer, although it doesn't seen to make that information available as a tag. Allocating role(s) to the artist credits does seem to fit their approach.
Rather than here under feature requests is there somewhere I can usefullly discuss implementation details, hopefully attracting more dev input? Or is here the place?
My start point is to get Kodi to capture composer, conductor, orchestra information from tags (all standard just Kodi does not currently handle them). Adding this role infomation to the artist credits so that we can differentiate beween composers, conductors, orchestras, and general (pop) performers, rather than the current big mixed bucket of artists that I find so user unfriendly. And then extend the user interface so that users can easily view artists by role. The ability to categorise artists by role may have uses beyond classical music, so DJs or Engineers etc. can be included in artist credits without making the artist list unwieldy.
Thanks for input EvilHamster. Musicbrainz does know the difference between a composer and a peformer, although it doesn't seen to make that information available as a tag. Allocating role(s) to the artist credits does seem to fit their approach.
Rather than here under feature requests is there somewhere I can usefullly discuss implementation details, hopefully attracting more dev input? Or is here the place?
2015-08-14, 19:52
The Development forum is the best place if your still thinking about the code and how it should be done.
If you have already written some code then submit it as a Pull Request against the Kodi repository and devs will jump in to discuss there. Make sure each PR is a small feature though such as a single new tag. Large PR's rarely get approved so its best to split them up.
If you have already written some code then submit it as a Pull Request against the Kodi repository and devs will jump in to discuss there. Make sure each PR is a small feature though such as a single new tag. Large PR's rarely get approved so its best to split them up.
2015-09-11, 11:20
(2015-08-14, 19:52)zag Wrote: The Development forum is the best place if your still thinking about the code and how it should be done.
If you have already written some code then submit it as a Pull Request against the Kodi repository and devs will jump in to discuss there. Make sure each PR is a small feature though such as a single new tag. Large PR's rarely get approved so its best to split them up.
Discussion of development ideas here, although not much response so far.
Have gone for it with a PR #8015, perhaps you will have a look Zag.
Made as small an initial step as I could, but it requires more than just a single tag change. Very hard to catch the development merry-go-round of change, made harder by lack of experienced dev team members that even use the music side let alone have time to consider design work. Not hopeful this well ever get approveal, but trying to improve things.
2015-09-11, 12:49
Great work, thanks for the contribution
One thing about the development in general is that PR's are usually easier to merge if they are broken down into smaller commits. It also makes for easier reviewing by others.
Don't give up if there is lots of discussion, this is normal on new user PR's and usually improves the code
One thing about the development in general is that PR's are usually easier to merge if they are broken down into smaller commits. It also makes for easier reviewing by others.
Don't give up if there is lots of discussion, this is normal on new user PR's and usually improves the code
2015-09-11, 13:17
Thanks for the support Zag. That was as small a commit as I could manage and still create code that did something!! But I appreciate it is not easy to review, so will do what I can to be responsive and keep positive.
2015-09-11, 15:21
Yeah keep up the good work, unfortunately most of the established dev's have little interest in music which together with all the complexity of handling tags and Musicbrainz id's tends to mean they avoid working on it. Those of us on the Team who do have a keen interest in music side of things mostly have no coding skills to change things for ourselves, so if there lots of discussion it's only because we're glad to see someone taking an interest and want to see the user experience improved.
2016-05-21, 16:13
