label support

[wolftune]

For anything to be the ultimate music player (and this looking good to me as a candidate), it's gotta be able to have multiple tags. I don't want to tag "acoustic rock" and "blues improvisation" or "acoustic blues improvisation" as genres. However the single-tag idea was created, it stinks to high heaven. Tags are not boxes, they allow more sophisticated things.

We need to be able to recognize multiple tags for any track or album or whatever. "Blues" and "Acoustic" and "improvisation" etc. all at once, and really filter by AND, OR, and NOT… so I want to tag "educational" and when I'm listening to music at a party I want to filter to NOT educational for example…

[andrewrk]

I believe that @thejoshwolfe is interested in tags as well.

What do you think about playlists instead of tags? What does tags offer that playlists does not?

I like your example with "educational" btw. Ha!

[wolftune]

Playlists are a different organizational structure entirely. Because of the absolute awfulness of id3, people don't even have a sense of what they are missing.

I don't mean this in a dismissive way at all (and I think your project is supremely exciting), but think like this: your photo album manager… whichever you use, it has tags, you can indicate all sorts of things that way. What do you think about slideshow playlists for photos instead of tags?

See? What if Flickr or YouTube (or SoundCloud even) decided that keywords (i.e. tags) weren't needed since they have playlists? This is a totally different thing. Tags are used to find things when you make playlists. If a track is "techno" and "French" and "odd-time-signature", I don't want to necessarily have a playlist for each of those. I might like to have an auto-generated playlist in some cases (like a smart folder feature maybe), but it would be silly to have a giant list of playlists when I can just tag things and search by tag.

The "educational" example is actually a big deal personally. I teach music lessons and I have all sorts of example tracks that demonstrate things for students. I also play normal music for students at the same time. Sometimes, I'm looking for all the Flamenco stuff, and I might want the educational tracks included (but not to be limited to those), but if I want to just play some flamenco stuff one day, I might want to exclude the educational tracks. I don't want to have had to think in advance about whether one day I'll care to do that and thus to have anticipated the need to carefully create a Flamenco playlist that doesn't include the educational tracks.

[Necior]

What do you think about playlists instead of tags? What does tags offer that playlists does not?

It seems easier to type "EDM or uptempo or dance not dubstep not trap not metal" (or equivalent advanced search syntax) than creating temporary playlist based on several others. Like @wolftune mentioned, it would work like tags of photographs.

[james-gibson]

When I think of playlists, mentally they are digital version of a CD. They contain tracks and an order (though order can be shuffled). Tags to me are like walking down aisles at a music store, the EDM aisle has nothing but EDM tracks/CDs.

I think the concept of tags also lends easily into automatically generated playlists based on simple/advance tag searching.

[wolftune]

James, you are right partly, but the physical example of the record store is problematic. They would rarely put multiple copies of a CD in many different areas. So Zappa is just gonna be in the rock section because the CD is limited and has to go in this one place. Whereas Zappa's music should be present in the Jazz section and the big band section within that in some cases, and the guitar-solo section and the doowop section and the blues section or even the avante-garde section…

I actually wrote a blog post about this years ago: http://blog.wolftune.com/2008/09/genre-style-i-love-tagging.html

Cheers

[thejoshwolfe]

This discussion is about Tags, Playlists, and Searching. In order to see the tags idea really work, groovebasin will also need a more sophisticated searching mechanism, as opposed to the simple word-split, text-matching search it does now. I think the searching usecase is a really good argument for having tags; searching for inclusion in a playlist might accomplish the same thing, but it doesn't seem like the right tool for the job.

That said, there's a good usecase for playlists too. Specifying the order of songs is useful if you're organizing a dance mix and you want to control when fast songs and slow songs will play in the sequence of songs.

Tags and playlists both seem important, but they're also very similar. Should we do both independently? Could there be a single solution that satisfies all usecases?

[andrewrk]

Seems like tags could be a useful concept in many ways.

Here's another thing to think about: If you do a lot of work tagging tracks it makes it hard to switch music players. Conversely users might feel like they're wasting their time doing tagging at all if the data they're carefully organizing only exists in the arbitrary db of a single music player. I wonder if there is any way to mitigate that.

[wolftune]

I think playlists are absolutely needed, and I still go with the photo analogy. Tags for photos are more important to me than setting up specific slideshows. "Events" in a photo program are like "albums" in this case. Sometimes I want to put a series of photos in a set, perhaps with a set order, selecting from many different events, for the purpose of a slideshow. But it is not my primary use of the program.

[wolftune]

As hard as it is to make new standards, the fact is that the id3 tag standard is the bane of all of this. Today, no website with music that I know of is lacking in having tags, but almost all the music players for local collections lack this. There is at least one that has really attempted to do this justice though: https://code.google.com/p/quodlibet/

It would be good to investigate how quod libet does it and perhaps work to be compatible. EDIT: I'm not really sure if this is what I'm talking about or not, it's unclear to me right now

Ideally, we really want a new standard for music-file metadata that uses multiple tags.

At any rate, tags don't have to be used to the extent that is possible, just a couple simple tags like "rock" and "blues" being able to be used at the same time, basically the standard set of id3 tags even, just not limited to one-per-file would already be a major improvement that almost every user would appreciate.

[james-gibson]

@wolftune You are exactly correct! I incorrectly assumed that my physical example would be assumed to be generic. Tags boil down to metadata about the track/album and that metadata becomes the searchable attributes.

@thejoshwolfe I think that search results are simply un-ordered playlists, simply because you can play tracks that were returned from the results. In this case I would suggest that tracklist would describe this case better then tags vs playlists. A search of tags would produce a tracklist while a playlist would be an ordered tracklist either hand crafted or generated based on saved search criteria (allowing the user to add new music that auto-magically appears in existing playlists)

[Necior]

If you do a lot of work tagging tracks it makes it hard to switch music players.

Providing simple export function to, for example, JSON allows developers creating tools for transition from one player to another (if both support multiple tags).

[wolftune]

Ok, upon further investigation, it appears to me that quodlibet's Ex Falso system (basedon Mutagen maybe?) is not already what we need, but provides a standard and widely accepted backend that could be just slightly extended.

It already has multiple tags for metadata and is used for lots of things, it just doesn't seem to have flexible tagging by the user or otherwise have a UI for that. It does already allow advanced syntax for searching…

I'm not really an experienced programmer though, so I'm going with vague impressions.

[wolftune]

Interesting, MusicBrainz http://musicbrainz.org already has multiple tags on things in a standard reference collection.

Unfortunately, (but not sure how it affects this project), most of the data they store is under CC-BY-NC-SA and the NC part makes this non-free, but maybe still usable.

It seems to have been infected by holdovers from the limited one-tag approach because the site has "rock" and "indie" but there's also pollution from tags like "indie rock" and the worst: "rock and indie".

But at any rate, this is certainly another example of cross-program use of multiple tags out in the wild… So, there are examples of how to do this without it being just an internal DB for the one program.

EDIT: Beets also looks like it is worth investigating: http://beets.radbox.org/

[yoasif]

See flexible attributes in beets:

http://beets.radbox.org/blog/flexattr.html

beets can write these flexible attributes into the files.

[fsateler]

It appears id3v2.4 allows multiple values for each tag. See section 4.2. So perhaps the same TCON field can be used for data interchange with other players, and groovebasin can import it into its database.

[whmountains]

@fsateler Wikipedia says something somewhat similar.

The version 2.3 of the standard prescribes that some fields can contain multiple values separated by the "/" character[citation needed]. The fields that can contain multiple values are:
TPE1 TCOM TEXT TOLY TOPE

It's strange that Wikipedia says you need a / character, but the spec says you need the "termination code for the character encoding".

@yoasif Maybe I'm reading wrong, but doesn't beets put the flexattrs in it's sqlite database and not in the actual files?

Maybe you could save the additional info as a JSON object into the TXXX field? It should be feasible to stay under the 16MB limit.

I'd personally just bite the bullet and save everything to a MongoDB database and allowing a JSON dump or something similar to export to other media players. I know it might make you feel like you're wasting your time organizing your music only to lose it with another media player, but I think with the proper UI (I have one in mind.) It could be something that so easy that you would hardly think about it.

Finally, someone who wants their music to work in as many players as possible could just not use the special features: groovebasin would only not store data as ID3 if it had to.

[andrewrk]

I agree with @wolftune about labels (we're going to call this feature "labels" to disambiguate with metadata tags) being a more important feature than playlists.

Here are the current plans for labels:

• When you make a selection of tracks, the right click context menu has "Add Label" and a submenu that includes all existing labels, and a text box at the top so you can create a new label.
• This submenu has checkboxes so you can quickly add multiple labels.
• The library search filter supports "label:foo" queries and has an advanced arrow dropdown so you can construct queries with the UI (which teaches you how to construct queries without the UI by populating the filter text box)
  • So if you wanted to queue up everything with the label "party" in random order, you could do this keyboard sequence: "/label:party" followed by alt+enter
• Dynamic Mode supports labels, so you could turn on Dynamic Mode and have it select from only some labels and exclude other labels.
• Try to figure out a good place to serialize this information in the metadata tags of tracks, but really the canonical place to store the label information will be groovebasin's db.

[wolftune]

sounds great, but I would really like full AND, OR, NOT support for label filtering as mentioned in the top post.

[thejoshwolfe]

AND, OR, NOT support for label filtering

I plan to support AND by simply typing space-separated terms, aka the juxtaposition operator (this is how searching works currently).

I plan to support NOT with the prefix not: and then any search term, such as not:label:christmas or not:"Justin Bieber".

I'm not sure about OR support. The leading candidate for syntax is gmail's search syntax with parentheses and OR. This seems much more complicated (and less elegant) than everything else proposed so far, so perhaps it could be postponed as separate issue when this issue is done.

[wolftune]

That sounds good mostly — including the examples of when to use NOT ;)

first of all, technically that use of NOT is actually "AND NOT". So full implementation of OR means also offering "OR NOT"

OR is indeed an independent sort of thing. I thought about it a bit and agree first that it could be a separate issue. But here's my suggestion for implementation: Make it additional rows for searching. Basically one search with whatever labels and not: whatever labels gives certain combination of recordings. The user could effectively say "add another search collection to this for a larger overall collection". They do that by just clicking a + or something to see another search row and can add whatever searches they want to that. The result just sums all the searches.

[thejoshwolfe]

Make it additional rows for searching.

That proposal is not as elegant as gmail's syntax. Using parentheses and infix operators leads to arbitrarily complex nested expressions (like algebra or a programming language). For example, label:electronic not:(label:house OR label:trap) is more elegant than label:electronic not:label:house OR label:electronic not:label:trap.

Fwiw, I've used expression builders that use rows (specifically, Lotus Notes email filters), and I find them more confusing than a complete textual expression. Consider that the UI needs to have buttons like "add row" and "remove row', and then should it also have controls for reordering the rows? What about keyboard shortcuts for navigating and manipulating these controls? I don't think this is a good direction for the UI to go, compared with a single all-powerful textbox.

However, supporting nested expressions requires not only a tokenizer (which we have now) but also a parser, complete with operator precedence, parenthesis balancing, etc, which is why I think it should be put off for now.

[wolftune]

Ok, I agree that putting it off makes sense. To be clear though: as I see it, row order would be irrelevant. Anyway, I never had any strong feelings about the implementation, just that support for OR would be desirable in some fashion.

I have a follow-up thought though: what if users could save searches? (maybe they can already… I didn't explore that). Then there could be something where someone selects multiple saved searches and says "play from any of these selected saved searches" essentially. Like saved-searches are shown on the side and this is just activating multiple ones at a time. Just a thought to consider, not fully sure about it…

[thejoshwolfe]

what if users could save searches?

This is a big idea. I like it. One way to do it is #389 (just created).

[andrewrk]

Label support progress (happening in the labels branch):

• - Server side support and protocol documentation for labels
• - Client: ability to add label to tracks
• - Client: ability to delete labels
• - Client: ability to filter library for labels
• - Client: label dialog have check boxes for label and support adding and removing
• - Client: filter search keyboard shortcut and gui button for popping label dialog to help complete filter search text
• - Client: display labels in the queue
• - Label colors
• - Client: ability to change a label's color
• - Client: ability to rename a label

[alphapapa]

I subscribed to this issue a while back because I'm interested in GrooveBasin and in tagging/labeling my music. I don't know if this feedback will be of any use, but I just thought I'd share what I've done with my library.

Since each player may or may not support tags/labels, and since I want to be able to switch between different players and use different software to organize my music, I have settled (so far, at least) on embedding custom tags within audio files. I use Python and mutagen to write a tag with a custom name (my initials + _Tags) that contains a comma-separated list of labels. I currently have it working with MP3s, Oggs, and M4A/AAC files, but it can be made to work with anything mutagen supports.

Then I have another Python script that goes through ~/Music and makes an M3U playlist for each label in my custom tag. I have this in a cron job, but it can also be run on-demand for all or certain labels.

Then I have another Python script (plamix) that can merge M3U playlists together.

Then I have a few small utility scripts that make it easy to quickly tag whatever track is currently playing with shell tab-completion of labels. This works really well with Fish, because I can do something like this:

$ tagcurrenttrack guicla<tab>
$ tagcurrenttrack guitar/classical tal<tab>
$ tagcurrenttrack guitar/classical instrumental

Fish's fuzzy completion matching is really great for this.

So the end result is that my music collection is player- and organizer-independent. All of my personal metadata is embedded in the tracks, so I don't have to transfer it from one player's database to another, etc. And I can quickly mix playlists and pipe them directly to MPD or any other player like:

$ plamix classical instrumental relaxing --exclude christmas | mpd

I guess my conclusion is, while I'm happy to see support for tagging and labeling in GrooveBasin and other players, I don't know if I will ever use that support. The system I have now lets me label tracks with a few keystrokes no matter what program is currently on the screen, and I can use any player. I just can't see myself putting time and effort into building a collection of metadata that's stuck in a certain player's database. (Of course it can be extracted or exported, but then it must also be imported elsewhere, and all of that has to be done every time one changes to a different player.)

And it also means that I can copy ~/Music or parts of it to other systems or devices, and I can copy the M3U playlists at the same time, and use the generated playlists anywhere, even on something like an Android phone. If I were using a player database for my labels, I'd have to install that player on whatever system I want to use in order to make use of my labels, or I'd have to manually generate and export playlists for each label using that player.

Anyway, I'm always open to new ideas and improvements, so I'm happy to hear any thoughts. And if I can help somehow, just let me know. :)

[andrewrk]

@alphapapa I'm envisioning a scenario where we come up with a reasonable convention for storing labels in tags (perhaps one very similar to yours but does not use your personal initials). If the convention is reasonable enough that you feel comfortable adjusting your scripts to use it, then you could continue to be free from music player lock in with your labels, while still enjoying Groove Basin's built in support for it.

[alphapapa]

That sounds great. I would love to have player support for it.

What would be just about perfect would be if the tag name GB used for labels could be configured. I actually prefer to use a custom tag with my initials, because that way, if I ever add any tracks to my library, I won't have to worry about cluttering my personal labels with ones other parties have added.

For example, I have run into this problem using Digikam and IPTC tags. I set Digikam to read and write them from/to image files (same principle we're talking about). And whenever I add a new image to the library, if anyone who's ever had that file before has added any tags using whatever software they use, my personal list of tags gets cluttered with theirs. And believe me, it can become a really ugly mess (I am not exaggerating. ;).

[andrewrk]

Label support is merged into master.

@alphapapa The idea we discussed is a separate issue and will be solved when Groove Basin gains ability to write tags to disk.

Saved searches, fancy metalabel stuff, and more gui for searching labels can be discussed in separate issues.

[andrewrk]

Just a little screenshot of it in action:

[alphapapa]

Nice, I like the color support.