[Question] BitDepth and SampleRate at the album level

[GioF71]

Hello, would it be possible to have the bitdepth and samplerate available for the album? Even as lists if albums have tracks in different formats (a think that sometimes happens although quite rarely).
Thank you

[tehkillerbee]

I was thinking about adding this by passing on the info from the first track in the album. Assuming that all tracks in an album has the same depth/sample rate.

I'd also like to be able to present this info when listing albums with mopidy-tidal. Otherwise it's impossible to know if it's an album in HiRes or not.

Do you have an album where this is not the case?

[GioF71]

I remember one in qobuz but I did not take note of it. I would assume that these situations simply don't occur.
Maybe we can report the metadata from the first track as relevant for the album. Other situations might be considered as rare exceptions.
What do you thnk?

[GioF71]

This one!
First track is hires, the following tracks are redbook

[tehkillerbee]

@GioF71 Good find. A list of qualities could be an option if more than one quality type exists.

[GioF71]

@GioF71 Good find. A list of qualities could be an option if more than one quality type exists.

Ok, that would be even better.

So in the case of these properties of an album, would you provide a list of tuples (or classes) each one representing a combination of bitdepth and sampling rate?

I mean for that album, this would be returned:

qualities -> [(24,192000), (16,44100)]

I would not instead return a list for individual methods like bitdepth and samplingrate like:

bit_depth -> [24, 16]
sample_rate -> [192000, 44100]

because that would suggest combinations like [24,44100] and [16,192000] that don't exist in the album. The latter does not make a lot of sense anyway.

What do you think?

[GioF71]

Hello, I am observing an issue: when my plugin tries to display an album with lots of tracks, like this one which has 75 tracks, I start to get errors collecting bit_depth and sampling rate information.
In particular the root cause seems to be a "HTTP error on 429" which I believe means that I have hit a rate limit.
These metadata are not strictly required for basic functionality, but if these metadata are set in the upnp entries, the control point can display e.g. the "HD" badge.
Right now I have mitigated the issue by catching the error and simply going on with the list.
As a workaround, if this cannot be solved in the library because there is a limitation imposed by Tidal, and considering that I already have a local database available, I could quite easily "cache" these metadata and avoid getting them from api if I already "know" them.

Thank you for any feedback.

[tehkillerbee]

@GioF71 Yes, requesting stream metadata including the bit_depth and sample rate will most likely result in you getting 429 errors if done too frequently so you'd need to throttle those kind of requests. It'll also be quite slow for many albums.

For whole albums, I suggest using the first track to determine the album audio resolution as this should be good enough in most cases.. I have added this functionality on track, album level. You can decide whether to get audio quality for the first track or all tracks (list). For the latter, many requests are needed so it should be used with caution.

[GioF71]

Ok thank you very much for your feedback.

For albums, yes, using the first track is what I am doing. I am also keeping a table of played tracks on a sqlite db, with these metadata stored, so when available I also use those rows as the source for stream information. So if an album has mixed resolutions, chances are that if it has been previously played, the information will be eventually correct. Assuming that a track never gets "updated" on the Tidal servers.

The problem remain for playlists and mixes. In this case my only source is the played tracks table, otherwise the http 429 error is excepted to happen as soon as I try to show just a few tens of tracks.

When nothing is available I simply don't set sample rate, but I am setting bitdepth to 24 if max audio quality is configured as HI_RES or HI_RES_LOSSLESS, because otherwise, I would get weird information on control point, saying the track is 16bit/192kHz which is wrong.
The underlying MPD (Music Player Daemon) shows the correct depth (24/192) but the information does not go back to the control point.
The downside of doing this is that sometimes a track is reported to be 24bit while it is 16 bit, but I believe it's better than the other way around.

Thank you again

[GioF71]

For playlist and mixes, I might try to set a configurable limit defining how many tracks can be inspected for stream information. Something like 5 might be a decent compromise to avoid slowdowns and errors. I will try this as soon as I can

[tehkillerbee]

Added in #242

python-tidal/tidalapi/album.py

Line 292 in 4a0462d

def get_audio_resolution(self, individual_tracks: bool = False) -> [[int, int]]:

Currently, you can either get the audio resolution for the first track or all tracks in the album. We can perhaps use a range instead to make this a bit more flexible, in case it is necessary to check specific tracks in the album.

[GioF71]

Thank you very much, that is excellent.
One question: say I have a hires plan today, and I collect those values in the local db.
Tomorrow, I switch to the standard plan. Are the hires album presented to me still as hires, but played in standard quality, or are they presented as standard quality because my plan is now limited to standard quality?
My concern is: should I purge those data if the plan changes?