Compatibility with additional/custom tags on Smart Views

[araxhiel]

As the title says, it could be a great feature to have more flexibility while creating/configuring a Smart View, based on other tags besides the ones that the application already uses.

To give more context, I'll provide my particular scenario:

Currently, in order to keep my collection organized I rely a lot on the use of Smart Views, where I can filter the albums/artists by music genre, release type (LP, EP, Single, Split), "album type" (Studio, Live Album, Demo, Compilation, etc.), Country/Region (Germany, Norway, U.S.A., etc.), among other "categories".

So far, I've managed to do this using some of the default tags, such as genre, length, filename, and comment, being this one where I set most of the values that I want to use to filter the songs/albums on the Smart Views (ie. Comment = "Germany, Single" or "Spain, Live Album") using the "contains" operator in order to achieve my goal.

But, at least with some of the filters that I use there are already available tags for that information, like "Media type" that can be used instead "comment". Also, there are private frames that can be designated for other type of data that hasn't a proper tag field (like "country", or the ones that iTunes uses, or MP3Tag uses when downloading information from discogs).

So, it could be possible/feasible to add some compatibility with additional tags that aren't available on the default Smart View configuration? (both existing, and user defined)

Thanks in advance.

[dro]

Some of the things you're mentioning could probably be supported without too much issue when the local library plug-in gets replaced though having it fully dynamic in the data it can get isn't the simplest of tasks (most databases generally need to know what will be stored prior to being used) especially as it also depends upon the input plug-ins to provide that metadata (which they also aren't flexible in their design to provide other fields that aren't already known about).

Will definitely give this some thought to this as I've seen it pop up every now and then over the years and a more flexible library makes sense (despite the tecnhical hurdles).

-dro

[dro]

Thinking about this a bit more, can you (and anyone else) post the fields you're actually wanting in-addition to what is already supported please.

-dro

[Juanus]

Since you are adding Musicbrainz support, let's start with all of the musicbrainz tags
see attached image.

[dro]

I should have expected an "all of the tagz" reply With what's shown, a large number are already present albeit under a different name within the library though the musicbrainz_* values and a few others seem viable to add.

My main reason for asking for anything specific is that tracking all of that data will have a realistic impact on memory usage (especially across a large media library) if it's all to be collected & I know memory is there to be used (since it's not that comparatively cheap to buy currently) but just storing & having to load that data when it's often not going to be used is a bit of a waste.

-dro

[Juanus]

at this time, and for this specific request, I would think that the musicbrainz_* values are the least important since you cannot categorize by them and not meant for manual searching. (I wish that there was a way to make those tags read only since they are so specific for a very specific purpose.)
All of the rest of the tags are much more important. I think the OP is looking more for
Language
Media
Release Country
Release Status
Release Type

But I would be happy with ALL THE TAGZ!

[EDIT] Obviously the musicbrainz_* values can't be read-only. Then the program couldn't write to them. I meant to say non user editable.

[Benco]

Hi,

I would be very interested in this feature, it's something that I've been thinking of for a while. Here's another use case: add a "featuring" field. For example, in the Queen's album Hot Space, most tracks have only Queen as Interpret, except for Under Pressure, which features David Bowie. If the Interpret field is Queen feat. David Bowie, it messes with the album grouping, which means the Album Interpret has to be used. Using a Featuring field for storing David Bowie would make more sense.
And does this feature implies that title formatting would also need to be redone? Would make sense.

About the feasibility, could this be a way to go: Let the user specify which fields he needs, which defines the library metadata, and if there's a change in this metadata, have the library rebuild itself. I guess this rebuild would be quite difficult to implement, and very CPU consuming, but maybe it's feasible...

Benco

[Juanus]

Benco,

This is already implemented in Winamp/WACUP.
The field you are looking for is Album Artist. Instead of sorting by Artist, you should sort by Album Artist and that will give you the results you are looking for.

In your case
Album Artist = Queen
Artist = Queen feat. David Bowie

This is the standard way to tag and sort. Having a "featured" tag would not comply with the accepted standard.

[Benco]

Hi

as I have told in my previous post, I'm aware of this tag (which I miscalled Album Interpet). Using a Featured Artist, though, seems to me a better way to go. If I'm looking for all the songs from Queen, I won't have to use a request like "?artist=Queen or album_artis=Queen". And using "?artist has queen" doesn't work because it would also find Queen Latifah (big fan of Chicago here).

[dro]

With the 'featuring' suggestion, the only issue I can see (though I might have missed something) is that there's not a common tag field present for storing that information within the file without just having a local library specific field which cannot be easily pushed back to a file.

You might also be able to use a different matching pattern in the query but I appreciate that that won't necessarily work correctly for all cases either. Thanks for the convo & ideas made so far

-dro

[araxhiel]

I think the OP is looking more for
Language
Media
Release Country
Release Status
Release Type

Hi! Yes, those are the tags that I had in mind as they could be more standard rather using the ones from MusicBrainz or Discogs.

Sorry for the very late response, btw.

[Der_Rio]

I make use of the folowing ID3V2 tags:

ALBUM   TALB   Standard
ALBUMARTIST   TPE2   Standard
ARTIST   TPE1   Standard
COMMENT   COMM   Standard
COMPILATION   TCMP   0/1
COMPOSER   TCOM   I used this manly as AUTHOR for audiobooks/audioplays
CONDUCTOR   TPE3   
CONTENTGROUP   TIT1   "Audiobook", "Audioplay", "Music", …
COPYRIGHT   TCOP   
DISCNUMBER   TPOS   Standard; should be used as string to keep values like "02/04"
GENRE   TCON   Standard
INVOLVEDPEOPLE   TIPL   
LANGUAGE   TLAN   important for filtering audiobooks/audioplays in different languages
LYRICIST   TEXT   
MEDIATYPE   TMED   "LP", "CD", "MC", "Web", …
ORIGALBUM   TOAL   for tracks on compilations
ORIGARTIST   TOPE   for remixes or remakes
ORIGYEAR   TDOR   interesting for remastered albums.
PODCAST   PCST   0/1
PODCASTID   TGID   
PODCASTURL   WFED   
PUBLISHER   TPUB   interesting for same audiobook/audioplay storys from different publishers => different interpretation of story
RATING WINAMP      
RELEASETIME   TDRL   I use this field for date of live recordings and date of podcast release
SETSUBTITLE   TSST   "Remastered", "Special Edition", …
SUBTITLE   TIT3   "Edit", "Remix", "Live", "Demo", …
TITLE   TIT2   Standard
TRACK   TRCK   Standard; should be used as string to keep values like "03/12"
UNSYNCEDLYRICS   USLT   
WWWRADIOPAGE   WORS   
YEAR   TDRC   Standard

ALBUMARTISTSORT   TSO2   should be used (optional) for sorting tracks in Library and Playlist
ALBUMSORT   TSOA   should be used (optional) for sorting tracks in Library and Playlist
ARTISTSORT   TSOP   should be used (optional) for sorting tracks in Library and Playlist
TITLESORT   TSOT   should be used (optional) for sorting tracks in Library and Playlist

HasAlbumArt      could be useful for filtering files with missing albumart
Path      could be useful for filtering by path


I use Mp3Tag for tagging all my files. Would be nice if WACUP would support some more of these fields. Therefore I gave some hints why these fields are important (to me).

Rio

[dro]

It fundamentally comes down to the input plug-in that provides the support for the tag / file as things currently stand. So until there's something in place to deal with that side of things (ideally isolating tag support from the playback handling), we're stuck with hard-coding tag support as far as the library works. Also I need to work out a way that can make some of the proposed additions work nicely against the main tag formats & not going for an ID3v2.x focus which might be fine for some but from my side I need to think about other users needs

-dro

[Der_Rio]

So maybe you should cosider copying the mapping concept of Mp3Tag:
http://help.mp3tag.de/main_mapping.html

That way you would be fully felxible with all types of tags (MP3 (ID3), WMA, OGG, ...) and all tag fields - standard or not. You can have the standard tag mappings by default, so it will not need so much memory. Anyone who needs more tags supported can add all the mappings he needs.
I know such a DB is a lot of work - but in the end i guess it could be worth it.

[dro]

Alas the mappings don't mean much if we're not able to access any value of data within winamp/wacup as is the current situation with the big file types (i.e. MP3, MP4/M4A).

I have put some thought into the new ml_ll plug-in with how we might be able to define & use custom tags but it's then how to store those values that's the problem otherwise we'll have a big performance hit. Though we need to get the base plug-in to be a bit more usable before adding some of the bells & whistles on to it

We'll get there, is just a big puzzle that needs to be put together to get everything to be able to do what is ultimately wanted to move things forward

-dro