Does it make sense to implement audio quality tags for albums as well?

[exislow]

There are already flags for tracks, like is_Mqa

python-tidal/tidalapi/media.py

Lines 402 to 415 in 6fb5289

	def is_Mqa(self) -> bool:
	try:
	if self.media_metadata_tags:
	return (
	True
	if MediaMetadataTags.mqa in self.media_metadata_tags
	and not self.is_Sony360RA
	and not self.is_DolbyAtmos
	else False
	)
	except:
	pass
	# Fallback to old method
	return True if self.audio_quality == Quality.hi_res else False

Thus, I can determine very easily, what kind of quality this track has. But Album has also MetaDataTags. Would it also make sense, to implement such is_* properties for albums as well, wouldn't it?

[tehkillerbee]

media Metadata is not populated for every album so that was the treason I didn't add it back then.

I have not recently looked at album mediaMetadata and what we can expect to find in it and if we can expect that it is always available nowadays. I'd also be interested to see if it contains more useful information to deduce if the album is mqa, hires, lossless etc. Especially since we often have several identical albums with the same name.

But the main issue i see is that an album can contain tracks that do not necessarily have the same quality available. A good example is the latest album by Pearl Jam, where the quality changes between HIRES_LOSSLESS and HIRES.

[exislow]

media Metadata is not populated for every album so that was the treason I didn't add it back then.

I have not recently looked at album mediaMetadata and what we can expect to find in it and if we can expect that it is always available nowadays. I'd also be interested to see if it contains more useful information to deduce if the album is mqa, hires, lossless etc. Especially since we often have several identical albums with the same name.

I haven't seen an album without any metadata so far.

But the main issue i see is that an album can contain tracks that do not necessarily have the same quality available. A good example is the latest album by Pearl Jam, where the quality changes between HIRES_LOSSLESS and HIRES.

That is true. But I think having such properties as an general indicator and also stating this within the code would still be very beneficial. Shall we implement this?

[tehkillerbee]

I haven't seen an album without any metadata so far.

I noticed it a few times while testing. The real issue occurs when parsing the album object associated with a given track so it is not the album itself that is missing this field. In this case, the json_obj["album"] field does not contain all fields, hence the reason mediaMetadata is not populated in this case so you'd get in trouble if you try to use it for something.

Anyways, regarding the media metadata. In the examples I've looked at, the album media metadata matches the track metadata so they can be used to determine the general audio quality of the album that is available from tidal servers (but not necessarily from the selected album!)

But I think having such properties as an general indicator ..

Agreed, this would be a good idea to add for the albums as well but of course we'd need to handle the situation where the media metadata is not populated. And the comment would need to reflect that the actual media metadata may NOT correspond to the album media metadata.

[Araxeus]

if I want to add the highest quality version of an album to a playlist, the expected flow would be:
1.search for the album
2. filter result list and order it by quality
3. get the highest quality album version

how can I do that?

Specifically I want a tool that import playlists from other spotify into TIDAL, and I want it to import the highest quality version of each song