Use track-level (MusicBrainz "work") language

[Hawke]

Tracks which are set to a language of 'no linguistic content' or 'multiple languages' in Musicbrainz have their language field set to 'eng' by beets.

I’m not sure if it matters, but I have my import languages set to: en_US en

Obviously these should be left at their correct 'zxx' or 'mul' values in the beets database.

[sampsyo]

Here's the example you mentioned: http://musicbrainz.org/work/8e3da5ef-aae4-4356-b7e7-0d5fa2c345d4

Investigating now.

[sampsyo]

Here's the issue: we only get languages from releases, not from works. That track appear on an English-language album: http://musicbrainz.org/release/0f2bab6d-5498-441c-a2a7-4d8f3d821418

I assume there's a MusicBrainz recommendation here (i.e., a Picard example to follow). Should we have separate fields for the album (release) language and the track (work lyrics) language?

[Hawke]

The ID3 spec says: “TLAN: The 'Language' frame should contain the languages of the text or
lyrics spoken or sung in the audio. The MP4 and Vorbis and WMA specs seem to be less well-defined, but all the mapping descriptions I see (Musicbrainz Picard, MP3Tag, hydrogenaudio wiki) map their respective language tags to the ID3 TLAN frame.

That means that it should use the work language and the 'instrumental' attribute to the 'performance of' relationship to set the language for the track.

[sampsyo]

Thanks for looking into it. Here's a little to-do list:

• Gather information about other tag formats for their definition of "language" and existence of alternative tags for lyrics and release language.
• Look at other tools (Picard, etc.) to see what they do with the release language vs. the work language.
• Decide on internal tag names for the two languages.
• Request the work-rels include from the MusicBrainz API and parse the language value from each track's associated work.

[Hawke]

I can say that Picard uses the release language in lieu of the lyrics language (meaning that it’s misusing the TLAN frame). Correction: Picard used to do the above, but now it uses the works language instead. It does not do anything especially intelligent with instrumental recordings.

Isn’t work-rels already requested in order to get the composer?

[sampsyo]

We actually don't yet get the composer (see #506).

[Freso]

Works are being pulled in by beets now, so it should already be getting the data from MB to implement this.