GNOME Bugzilla – Bug 487281
Support for multiple tags
Last modified: 2020-03-17 09:02:27 UTC
Please describe the problem: Banshee should support multiple tags in a song, for example a song could have the following tags : - artist: artist1 - artist: artist2 - title: title - genre: genre1 - genre: genre2 - album: album If I open this song with ExFalso or Quod Libet, they display each tag correctly (for exemple in the "artist" column, they display: "artist1, artist2"). But Banshee doesn't. I think it would be nice to correct this. Thanks for everything. Steps to reproduce: Actual results: Expected results: Does this happen every time? Other information:
Created attachment 97304 [details] An example song The metadata of this song are: - artist: artist1 - artist: artist2 - title: title - genre: genre1 - genre: genre2 - album: album
Thanks for your report. This is related to bug #365560 which requests composer support.
I would also like to request this feature. I was a long-time user of Quod Libet just for that feature alone. I would be willing to test any SVN if this can be patched into a branch at any time. I can compare against songs tagged in Quod Libet, also.
*** Bug 546712 has been marked as a duplicate of this bug. ***
*** Bug 583764 has been marked as a duplicate of this bug. ***
*** Bug 584601 has been marked as a duplicate of this bug. ***
+1 That'd be soo great!
*** Bug 640511 has been marked as a duplicate of this bug. ***
There is different possibility to solve this issues: 1) Create a new table wich do the link between track and artist ==> relation become n,n (same thing for genre) 2) store a group of artist as an artist, I mean ArtistName = "artist1, artist2" 3) Add a parentId in Artist table and build a hierarchy : GroupArtist id = 1 parentid = NULL artist1 id = 2 parentId = 1 artist2 id = 3parentId = 1 I like the 3rd way because : - do not have to create new table - most of track have one artist so keep simple for 90% - can search on a group of artist or single - solve issue with compilation/opera/musicals - do not have to parse and cut separator like with the second solution. - good for performance, I guess because 1st solution lead to performance descrease.
I think you might need to explain that 3rd point a bit more. I also think that maybe the simplest option is to implement number 2, but to have Banshee parse that author element and identify artist1 and artist2 separately. That way - I think - all the benefits of having number 3 are kept.
3rd option: Add a field parentId in the table artistInfo. So we can record which act as a a group of underlying record. son record will have on parentid field the value DBId of the parent record. So "Son record" and "parent record" will be in same table. example record 1 Queen with parentId = 0 because it is parent record 2 freddie Mercury parentId = 1 record 3 roger taylor parentId = 1 record 4 Brian may parentId = 1
I think this topic is quite some work to plan, organize and implement (well). What about making it a GSoC project?
The other day while fixing my Radiohead songs metadata, I encountered a situation that may be common to many. There are some songs which appear in various albums, but one can only select one album, so a new problem appears. Therefore, I think that there should be a possibility for various albums too. It would be great if all that has been talked here could be implemented into an existing and popular sound format, such as OGG. But I guess I don't know these grounds very well so if its nonsense just ignore it.
It's implemented in much sound formats : Quodlibet and Mutagen use it (http://code.google.com/p/quodlibet/wiki/Mutagen).
Wow, thats great. I did not know that, and its the most perfect system I have ever seen (editing tags in Quodlibet). Can banshee implement the same system Quodlibet is using?
Hello all there: I'm new to Banshee, but experienced C# programmer. I want to contribute to the project and this is the first enhancement in which I'm planning to work. First of all, this is my functional point of view: the main focus is with multiple artist field, that appears in the artist panel, because other multiple value tags only appear in search (it's enough with the compound field with semicolon) or in the tag editor (also the same approach, but can be problematic if semicolon is included in the value). Quod Libet, that some people said, is a good and complete reference, but we can start with something less complex. Technically, I have been analysing the code and this is what I have seen: - In DatabaseTrackInfo, we might add properties with collection arrays for multiple value fields. - In StreamTagger.TrackInfoMerge, we might load these properties with proper values from TagLib. - The serialization of the DB can be made handling a new Attribute MultipleValueDatabaseColumn that serializes the array within reflection method. - The artist panel will be filled iterating with the new property, splitting multiple artist one by one (I still don't see where this is done, but I think that is not a big deal). So, if main developers are agreed, I can start with this, or guide me in any other direction. Best regards. Pedro M. Baeza.
I mostly stick to musicbrainz tagging, so that all artist names are in teh artist field anyway. What I had in mind primarily when subsribung to the bug was multiple genre support. IMO, the classical genre field is way too limited. I always dreamed of using multiple genre tags or labels and fill them with values from last.fm or similar source (well, since I started using lastfm, that is *g) so that people can start create even more awesome playlists automatically! A way to do this was available for some time with amarok 1.4 which used "labels". Unfortunately, the labels weren't portable, and the feature was dropped with the switch to 2.0. So if you ask me, start with implementing multiple tags for the genre field. Since it's less used (and in some sense less important that the artist field), changes there maybe won't break things for users as easily.
Sebastian, you should probably subscribe to bug #525690
I am already, but thanks ;)
Created attachment 188118 [details] [review] Patch for reading joined genres in file tag
Sebastian, a fast patch to multiple genres in files is to change the line of Banshee.Core.Streaming.StreamTagger: public static void TrackInfoMerge (TrackInfo track, TagLib.File file, bool preferTrackInfo, bool import_rating_and_play_count) { ... track.Genre = Choose (file.Tag.FirstGenre, track.Genre, preferTrackInfo); with: track.Genre = Choose (file.Tag.JoinedGenres, track.Genre, preferTrackInfo); as I include in the attached patch, but for more advanced functionalities, it is required to change data structures. Although no one has contacted me for this question as I request for advice, I continue working on this issue, and if I get it, it will be very easy to adopt for multiple genres. Regards.
Is there any news on this feature ? Now that we have a genre filter in the browser (in the daily build at least, and soon in 2.4) I think this feature would be even more usefull than before. In my (large) collection, all genre tags have multiple values, with a ',' separator. Up to now, I've been using smart playlists with a "genre contains <genre name>" criteria as a poor's man genre filter, which works nice but have some problems on it's own. But now the new genre filter is way better, except is does not work with multiple genre :( I've not tried (yet) the patch above but it is mentionned that it does not provide "advanced functionnalities" : what would that be ? Please tell me if any help is needed ?
No activity in almost a year? That's a shame. This would be such a useful feature. +1 and following.
(In reply to comment #16) > I'm new to Banshee, but experienced C# programmer. I want to contribute to the > project and this is the first enhancement in which I'm planning to work. So Pedro, I was just revisiting this bug and saw your comment, are you still working on this? I think if Banshee had this feature implemented it would be eternally my media player of choice.
Dear Wolter: I asked for help from main developers in this bug and proposed a simple patch to see if I was in good direction, but nobody answered me, so I quit. Now, I'm using another music manager and I'm not planning to resume the work, sorry. Regards.
Banshee is not under active development anymore and had its last code changes more than three years ago. Its codebase has been archived. Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect reality. Please feel free to reopen this ticket (or rather transfer the project to GNOME Gitlab, as GNOME Bugzilla is being shut down) if anyone takes the responsibility for active development again. See https://gitlab.gnome.org/Infrastructure/Infrastructure/issues/264 for more info.