-
-
Notifications
You must be signed in to change notification settings - Fork 320
Advanced Functionality
This page goes into detail about Auxio's more advanced functionality, especially regarding metadata.
After extracting your library's tags, Auxio's music loader uses a graph-based system to associate your songs into albums, artists, and genres. "Graphs" are just webs of information and their relationships. For example, this is the graph if we were working with the song Flume by Bon Iver.

Your music library in Auxio is in the end stored like this, a simple web of information.
Of course, things are nowhere near as simple as this. Music libraries are snowflakes, and there is no guarantee that we will have consistent information to assemble a graph from. So, Auxio does a multi-stage approach to assemble a good-enough music graph.
First, Auxio just plots out all of your tags across the music library. Using a more complicated version of the Bon Iver library, except there are some inconsistency in tag casing (which is quite common). Naively grouping will wind up with an unusable music graph:

To fix this, Auxio starts clustering the myriad of albums/artists/genres by their case-insensitive name, which is basically the broadest possible clustering you can make that won't turn the graph into unusable mush.

From here, Auxio will do additional work attempting to split clusters into more fine-grained groupings using the tags it has. For the sake of simplicity, this isn't done in our graph example. However, if we had maybe a different artist also called "Bon Iver", and both artists were fully tagged with information that indicated their distinction (such as a MusicBrainz ID), Auxio would break apart it's initial cluster into two clusters for each Bon Iver.
Finally, Auxio will take the clusters it's created and collapse them into simple Genres/Artists/Albums, using whatever metadata it saw the most in the library. In the case of our example, the weirdly-cased tags are the minority in the library, so the simplified graph becomes this:

Yay! We have a correct music library even when the tags are weird! Even if there are more advanced tags, such as multi-value tags, MusicBrainz IDs, and so on, this is still the core flow used.
Below are the attributes that albums/artists/genres are progressively split on. The lower down in the list, the lesser priority it has.
| Album | Artist | Genre |
|---|---|---|
| Lowercase Name | Lowercase Name | Lowercase Name |
| MusicBrainz Release Group ID* | MusicBrainz Artist ID* | N/A |
| Album Artists* | N/A | N/A |
* These are only used if the cluster is fully tagged with them. They will be ignored otherwise.
Auxio's artist system differs from other music players. Vaguely inspired by Spotify, it attempts to unify album artist and artist information into a single list, instead of two disjoint lists for artists and album artists. The following is a simplified explanation of how Auxio attempts to achieve such. If you want more technical information, you can read the original multi-artist thread where the system was formulated.
The music loader actually gives different priority to artist and album artist tags depending on the context:
- In Songs, the artist tag is used first, falling back to album artist. This allows specific song collaborators to be linked to a particular song and remain shown in the user interface, even if an album artist tag is used elsewhere.
- In Albums, the album artist tag is used first, falling back to artist. This allows albums with a large variety of collaborators to be linked to only specific collaborators that contributed to the majority of the work.
Note that in ID3v2, Auxio will prioritizes non-standard tags like ARTISTS over standard frames like TPE1, as the former is most likely to contain parsable collaborators (ex. Parannoul;Asian Glow) rather than separated collaborators (ex. Parannoul & Asian Glow).
In the grouping process, Songs and Albums are simultaneously grouped into artist instances, without any differentiation on where the artist information was retrieved from. For example, one Album might have gotten artist information from the artist tag, while another Album might have gotten it's artist information from the album artist tag.
There are a few notable edge cases with the artist system:
- Artist entries are free to link themselves to an album if one of their songs come from it, but that doesn't mean the album will be linked to the artist.
- "Collaborator" artists may be created from individual-song artist credits that may be linked to just a single song and album. If these are not desired, enabling "Hide Collaborators" in settings will hide them from the library, albeit not elsewhere in the app.
- "Wildcard" artists can be created if they were solely linked to album instances, such as "Various Artists". These artists contain no songs, and thus functionality in these artists will be reduced.
- The song Saku by Bicep and Clara La San is part of an album primarily created by Bicep, but has vocals from Clara La San. The artists of this song can be properly represented by setting the artist tag to Bicep and Clara La San, and then setting the album artist tag to just Bicep. This will result in a song called Saku that will be displayed with the artists "Bicep, Clara La San", that is part of an album whose artist is solely "Bicep".
- The album Orchestra of Bubbles by Apparat and Ellen Alien is an album primarily created through the collaboration of both artists, and with individual songs that are also collaborations. Here, both the artist and album artist tags can be set to Apparat and Ellen Allien, which will result in individual songs that are linked to both artists, part of an album that is also linked to both artists.
- The compilation XL Recordings: Pay Close Attention has works from a variety of artists in them, without any one artist that has contributed to the whole compilation. Here, each song can set their artist tags to the artists that are specifically credited to it while setting the album artist to "Various Artists". This will result in individual songs credited to their respective artists, part of an album that is not credited to every artist, but rather a single "Various Artists" entry.
Auxio has direct support for tags with multiple values in certain contexts, such as artist names. These can be split into two categories.
Multi-value tags whose format has a standardized means of denoting multiple values. Examples incluide ID3v2.4 and Vorbis Comments. This is the recommended way to set up multi-value tags, but does not work on all formats.
Multi-value tags that delimit several values with a special character like "&" or ",". Auxio does not parse these by default, as it risks mangling certain names, such as "Black Country, New Road" becoming two artists named "Black Country" and "New Road". To enable them, select the "Multi-value separators" option in the settings menu and then select the characters you desire to be parsed. Undesired separator characters can also be escaped with a blackslash (ex. \+) in order to prevent some tags from being mis-interpreted as having multiple values.
Some groups of multi-value tags are combined into single pieces of information to be used in more complex library data. For example, the values for the Artist, Sort artist, and Artist MusicBrainz ID tags are combined into artist entries based on each triplet of values. If the values of these tag groups are not in the same order, unexpected behavior may occur.
Warning: The beets tool by default not follow this rule when creating artist information, as it will write a single MBID field even alongside multiple artist fields. Use the multi-artist fork to resolve this issue.
Auxio has support for extended data information, allowing more accurate date information about Songs and Albums. When possible, the app will try to sort by these more accurate dates. Most dates are shown in the UI was a plain year value, but if the date is more precise, a month value will also be shown (ex. Dec 2022). Date information can largely be separated into the following categories.
These are dates that are not based on a standardized timestamp. This encompasses primarily "year" tags formatted as yyyy. ID3v2.3 allow additional date precision through TDAT, which is formatted as mmdd for months and days respectively, and TIME, formatted as hhmm for hours and minutes.
These are dates that contain a precise timestamp instead of just a year value. Auxio uses the ID3v2.4 subset of ISO-8601 for these tags. These timestamps are usually formatted as yyyy-mm-dd*hh-mm-ss, with variable precision being allowed (for example, yyyy-mm).
These are non-standard dates where the year value is deliberately overloaded to a value formatted like YYYYMMDD. Support for these is limited due to the small amount of files with such formatting.
These are dates that signify when the original work was created in the context of a remix or cover. These are always preferred over other types of dates, as they tend to provide more accurate information. The structure of these tags are either Basic Dates or Timestamp Dates spending on the metadata format.
Numeric genres are converted in accordance with the ID3v2.3 specification, which accepts numeric values like 93 but also more complicated values, such as Blues(1)RX. The current numeric genre mapping can be seen here.
Auxio accepts standalone track/disc numbers, numbers with totals, and disc numbers with subtitles. Note that Auxio will ignore track & disc numbers that are zero unless there is a non-zero total value. This allows intentional tagging of zero values, if desired.
A common issue with large music libraries is an inability to separate different items that have the same name. MusicBrainz Identifiers are used by Auxio in order to accomplish this task. For example, one can set different MusicBrainz Artist IDs for two artists with the same name in order to have the artists grouped as separate entries.
Another benefit of MBIDs is that it increases the reliability of song information persisted by the app. Normally, Auxio attempts to make it's own identifier for items based on it's metadata, which will become invalid as soon as the metadata changes. This can cause Auxio to "forget" songs, making them disappear from important user data like playlists. If a MusicBrainz ID is provided instead, Auxio will use that as the identifier for an item instead, allowing for much more stable persistence.
In addition to other tag information, Auxio also has support for Sort Name tags. These tags can be used to provide a name to the app that should not be displayed, but still used in sorting. For example, "The Smile" would have a sort name of "Smile", as it's convention to not sort by articles like "The". If this is not provided, Auxio attempts to automatically create a sort name by cutting out words like "The" or "A" from the beginning of the name, alongside directly comparing digits "65" by their numeric rather than string value. If this is not desired, it can be turned if in Settings -> Content -> Intelligent Sort Names.
While Auxio still considers any grouping of songs with the same album name an "Album", it has support for a special "Release Type" field that denotes what kind of release a given album actually is, such as an EP or Single. This is useful for being able to differentiate different types of albums.
The way a Release Type field should be formatted is somewhat complicated and specified in further detail here, but it consists of a list of multiple keyword values representing a "primary" and "secondary" type. Here is a list of common release type identifiers:
-
album- Album -
ep- EP -
single- Single -
album, compilation- Compilation -
album, mixtape/street- Mixtape -
album, soundtrack- Soundtrack -
album, dj-mix- Mix -
album, live- Live album -
single, remix- Remix single
Auxio's search functionality is designed to be somewhat "fuzzier" than other implementations, matching multiple types of information with the given query. Currently, the information Auxio checks is as follows:
- The normalized name of an item. This changes any international characters into a latinized counterpart. This allows one to search for an item without having to specifically type in a particular character (ex. "Sigur Ros" matching with "Sigur Rós")
- The sort name of an item. This information may be latinized, giving it a similar purpose to the normalized name, albeit more powerful since information in different scripts (ex. Japanese) can now be matched to a latinized query.
- The file name of an item. This is an exception carved out for libraries that are not very well-tagged and are still primarily based around file names.