Feature/Add ability to set audio/video quality for session + bugfixes #174

tehkillerbee · 2023-08-05T16:35:11Z

This PR adds the following features:

Add helper functions to set audio/video quality for current session
Added missing WELCOME_MIX MixType
Removed obsolete artist URL. Set sensible default dimensions for all image getter functions.
Updated readme.

2e0byo

Mostly looks good. I've rebased against master. Personally I'd use properties for the audio/video quality: more pythonic, saves digging into the config object (which I think we're going to refactor pretty heavily at some point), and more discoverable.

tidalapi/session.py

… functions returning image URL..

jozefKruszynski · 2023-08-09T10:39:10Z

I think that as part of this PR you should also update the Quality Enum in media to properly reflect the new quality possibilities

https://github.com/tamland/python-tidal/blob/master/tidalapi/media.py#L39

tehkillerbee · 2023-08-09T10:50:25Z

@jozefKruszynski As far as I know, there are only these four quality options available from tidal, with master (hi_res) providing the highest quality possible in lossless FLAC. Are there more options available?

I have noticed that tidal does not always refer to the highest quality as 'master'. Is that what you mean?

jozefKruszynski · 2023-08-09T11:05:25Z

@jozefKruszynski As far as I know, there are only these four quality options available from tidal, with master (hi_res) providing the highest quality possible in lossless FLAC. Are there more options available?

I have noticed that tidal does not always refer to the highest quality as 'master'. Is that what you mean?

Well what I meant was that previously master was essentially the highest possible quality setting and this actually refers to lossless.
Before the recent changes HIGH was just hifi quality iirc. Now there are only 3 possibilities in any tidal app and it would seem that they are essentially,
LOW,
LOSSLESS
HIGH (HI_RES)

So actually high now has a different meaning than before.
I hope what I'm trying to say is making some sense

EDIT:
Perhaps I'm missing something here though, as actually I still need to select master to get HI_RES, and selecting HIGH still gives regular HIFI versions.

tehkillerbee · 2023-08-09T11:39:05Z

Ok, now I know what you mean. Yes, I noticed that Tidal changed their naming slightly in the web client. Now we have Low (96kbps, 320kbps), High and Max). The the actual name of the quality used by tidalapi corresponds to low, high, lossless and hi_res. In the android app, we have normal, high, hifi and master.

For consistency (with the web/PC client), we could use two "low" settings (eg low_96k, low_320k) and then "high" and "max".

self._active_session.audio_quality = Quality.low
self._active_session.audio_quality = Quality.high
self._active_session.audio_quality = Quality.lossless
self._active_session.audio_quality = Quality.master

ffprobe output with low (mp4), high (mp4), lossless (flac) and master (flac)

ffprobe -hide_banner low.mp4 && ffprobe -hide_banner high.mp4 && ffprobe -hide_banner lossless.flac && ffprobe -hide_banner master.flac
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'low.mp4':
  Metadata:
    major_brand     : isom
    minor_version   : 512
    compatible_brands: isomiso2mp41
    encoder         : Lavf58.20.100
  Duration: 00:04:07.27, start: 0.000000, bitrate: 96 kb/s
  Stream #0:0(und): Audio: aac (HE-AAC) (mp4a / 0x6134706D), 44100 Hz, stereo, fltp, 96 kb/s (default)
    Metadata:
      handler_name    : SoundHandler
      vendor_id       : [0][0][0][0]
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'high.mp4':
  Metadata:
    major_brand     : isom
    minor_version   : 512
    compatible_brands: isomiso2mp41
    encoder         : Lavf58.20.100
  Duration: 00:04:07.21, start: 0.000000, bitrate: 321 kb/s
  Stream #0:0(und): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, stereo, fltp, 320 kb/s (default)
    Metadata:
      handler_name    : SoundHandler
      vendor_id       : [0][0][0][0]
Input #0, flac, from 'lossless.flac':
  Duration: 00:04:07.16, start: 0.000000, bitrate: 910 kb/s
  Stream #0:0: Audio: flac, 44100 Hz, stereo, s16
Input #0, flac, from 'master.flac':
  Duration: 00:04:07.16, start: 0.000000, bitrate: 1743 kb/s
  Stream #0:0: Audio: flac, 48000 Hz, stereo, s32 (24 bit)

tehkillerbee · 2023-08-09T11:42:19Z

Perhaps I'm missing something here though, as actually I still need to select master to get HI_RES, and selecting HIGH still gives regular HIFI versions.

Selecting HIGH shouldn't give you HIFI version, that should instead give you 320k mp4.

Yes, currently you need to select master to get the best possible quality.

jozefKruszynski · 2023-08-10T06:09:09Z

Now it all makes sense, sorry for the confusion. These changes are really cool. I think combined with mediaMetadata array that was merged last week it should be much easier to ensure that I'm only streaming flac files and never try to grab mqa stuff.

jozefKruszynski · 2023-08-10T13:08:55Z

Having played around with trying to get the HI_RES_LOSSLESS versions of tracks locally I have discovered a rather strange quirk of the api.

When a track is parsed from Tidal, the audioQuality of a HI_RES track is HI_RES, now one would hope that this same audio quality attribute can be used to get the HI_RES stream, however, this is absolutely not the case as far as I can see.

According the web player the audioQuality when requesting the HI_RES version is actually HI_RES_LOSSLESS

Perhaps this is a quirk of the web player api as opposed to the api that we use for getting the track stream URL

README.rst

2e0byo · 2023-08-13T08:26:36Z

@tehkillerbee pushed a few fixups: apologies for pushing to your branch.

Should we default to high (master) or lossless? Added a test to assert the current behaviour.

tehkillerbee · 2023-08-13T10:06:38Z

Perhaps this is a quirk of the web player api as opposed to the api that we use for getting the track stream URL

@jozefKruszynski I just tested this. It appears that HI_RES and HI_RES_LOSSLESS returns the same FLAC file. Perhaps for backwards compatibility? Only TIDAL would know... :)

ffprobe -hide_banner lossless2.flac && ffprobe -hide_banner hi_res_lossless.flac 
Input #0, flac, from 'lossless2.flac':
  Duration: 00:03:43.83, start: 0.000000, bitrate: 474 kb/s
  Stream #0:0: Audio: flac, 48000 Hz, stereo, s32 (24 bit)
Input #0, flac, from 'hi_res_lossless.flac':
  Duration: 00:03:43.83, start: 0.000000, bitrate: 474 kb/s
  Stream #0:0: Audio: flac, 48000 Hz, stereo, s32 (24 bit)

Should we change to HI_RES_LOSSLESS for consistency? What about renaming the quality presets as I suggested earlier?

For consistency (with the web/PC client), we could use two "low" settings (eg low_96k, low_320k) and then "high" and "max".

Thoughts @2e0byo ?

tehkillerbee · 2023-08-13T10:08:56Z

@tehkillerbee pushed a few fixups: apologies for pushing to your branch.

Should we default to high (master) or lossless? Added a test to assert the current behaviour.

Great, thanks for adding tests. I still need to get into the habit of writing tests for everything I add :)

I think we should default to the quality type that is most likely used by the end user, if a standard subscription is available. So I would say we should use high quality.

2e0byo · 2023-08-13T16:53:03Z

Re. the type: why not use Enum aliasing and support both?

jozefKruszynski · 2023-08-14T09:38:24Z

Perhaps this is a quirk of the web player api as opposed to the api that we use for getting the track stream URL

@jozefKruszynski I just tested this. It appears that HI_RES and HI_RES_LOSSLESS returns the same FLAC file. Perhaps for backwards compatibility? Only TIDAL would know... :)
ffprobe -hide_banner lossless2.flac && ffprobe -hide_banner hi_res_lossless.flac 
Input #0, flac, from 'lossless2.flac':
  Duration: 00:03:43.83, start: 0.000000, bitrate: 474 kb/s
  Stream #0:0: Audio: flac, 48000 Hz, stereo, s32 (24 bit)
Input #0, flac, from 'hi_res_lossless.flac':
  Duration: 00:03:43.83, start: 0.000000, bitrate: 474 kb/s
  Stream #0:0: Audio: flac, 48000 Hz, stereo, s32 (24 bit)
Should we change to HI_RES_LOSSLESS for consistency? What about renaming the quality presets as I suggested earlier?

For consistency (with the web/PC client), we could use two "low" settings (eg low_96k, low_320k) and then "high" and "max".

Thoughts @2e0byo ?

Have you been able to get real HI_RES audio so far, rather than the 24bit 48000Hz MQA files?
From what I have read, the idea is that the "full fat" Flac files are supposed to take precedence, if they are available, however, when I check the mediaMetadata and ensure that a HIRES_LOSSLESS version is available, I still only get the MQA version, and if there is only HIRES_LOSSLESS and LOSSLESS, I receive the LOSSLESS version.

Are you seeing the same behaviour?

tehkillerbee · 2023-08-14T09:48:30Z

Perhaps this is a quirk of the web player api as opposed to the api that we use for getting the track stream URL

@jozefKruszynski I just tested this. It appears that HI_RES and HI_RES_LOSSLESS returns the same FLAC file. Perhaps for backwards compatibility? Only TIDAL would know... :)
ffprobe -hide_banner lossless2.flac && ffprobe -hide_banner hi_res_lossless.flac 
Input #0, flac, from 'lossless2.flac':
  Duration: 00:03:43.83, start: 0.000000, bitrate: 474 kb/s
  Stream #0:0: Audio: flac, 48000 Hz, stereo, s32 (24 bit)
Input #0, flac, from 'hi_res_lossless.flac':
  Duration: 00:03:43.83, start: 0.000000, bitrate: 474 kb/s
  Stream #0:0: Audio: flac, 48000 Hz, stereo, s32 (24 bit)
Should we change to HI_RES_LOSSLESS for consistency? What about renaming the quality presets as I suggested earlier?

For consistency (with the web/PC client), we could use two "low" settings (eg low_96k, low_320k) and then "high" and "max".

Thoughts @2e0byo ?
Have you been able to get real HI_RES audio so far, rather than the 24bit 48000Hz MQA files? From what I have read, the idea is that the "full fat" Flac files are supposed to take precedence, if they are available, however, when I check the mediaMetadata and ensure that a HIRES_LOSSLESS version is available, I still only get the MQA version, and if there is only HIRES_LOSSLESS and LOSSLESS, I receive the LOSSLESS version.

Are you seeing the same behaviour?

The above HI_RES files are all 24bit 48kHz FLAC (i.e. not MQA). Of course these files are not 192kHz as TIDAL has previously advertised. Maybe this is dependent on the availability.

What albums have you tested with? I can try testing with the same albums.

tehkillerbee · 2023-08-14T09:52:57Z

Re. the type: why not use Enum aliasing and support both?

I think I would prefer that we do not have too many quality options to avoid confusion and to mimic the options provided in the web players.

So I propose something like.

low_96k
low_320k
high (lossless)
max (lossless)

jozefKruszynski · 2023-08-14T10:04:29Z

Perhaps this is a quirk of the web player api as opposed to the api that we use for getting the track stream URL

@jozefKruszynski I just tested this. It appears that HI_RES and HI_RES_LOSSLESS returns the same FLAC file. Perhaps for backwards compatibility? Only TIDAL would know... :)
ffprobe -hide_banner lossless2.flac && ffprobe -hide_banner hi_res_lossless.flac 
Input #0, flac, from 'lossless2.flac':
  Duration: 00:03:43.83, start: 0.000000, bitrate: 474 kb/s
  Stream #0:0: Audio: flac, 48000 Hz, stereo, s32 (24 bit)
Input #0, flac, from 'hi_res_lossless.flac':
  Duration: 00:03:43.83, start: 0.000000, bitrate: 474 kb/s
  Stream #0:0: Audio: flac, 48000 Hz, stereo, s32 (24 bit)
Should we change to HI_RES_LOSSLESS for consistency? What about renaming the quality presets as I suggested earlier?

For consistency (with the web/PC client), we could use two "low" settings (eg low_96k, low_320k) and then "high" and "max".

Thoughts @2e0byo ?
Have you been able to get real HI_RES audio so far, rather than the 24bit 48000Hz MQA files? From what I have read, the idea is that the "full fat" Flac files are supposed to take precedence, if they are available, however, when I check the mediaMetadata and ensure that a HIRES_LOSSLESS version is available, I still only get the MQA version, and if there is only HIRES_LOSSLESS and LOSSLESS, I receive the LOSSLESS version.
Are you seeing the same behaviour?
The above HI_RES files are all 24bit 48kHz FLAC (i.e. not MQA). Of course these files are not 192kHz as TIDAL has previously advertised. Maybe this is dependent on the availability.

What albums have you tested with? I can try testing with the same albums.

Hmm, that makes sense actually, I was somehow assuming that ffmpeg is not able to display if something is actually encoded with MQA as from what I understand this would still show as a flac file, albeit an mqa encoded flac file.
I actually just tested with this album https://listen.tidal.com/album/1753674 which is Alice Cooper's Greatest hits, and it should have both LOSSLESS and MQA, and I actually get the LOSSLESS stream rather than the MQA one, at least that is what it seems to return

EDIT:
I also just tested this album which definitely has only LOSSLESS and HI_RES_LOSSLESS and I only get the 16bit 41000Hz version returned.
https://listen.tidal.com/album/121124384

2e0byo · 2023-08-14T10:51:39Z

Re. the type: why not use Enum aliasing and support both?

I think I would prefer that we do not have too many quality options to avoid confusion and to mimic the options provided in the web players.

So I propose something like.
* low_96k

* low_320k

* high (lossless)

* max (lossless)

Now I'm more awake aliasing is the other way round: one value (string) mapping onto multiple entries.

These look good to me.

tehkillerbee · 2023-08-16T17:46:09Z

I also just tested this album which definitely has only LOSSLESS and HI_RES_LOSSLESS and I only get the 16bit 41000Hz version returned.
https://listen.tidal.com/album/121124384

Odd, same thing happens to me with that specific album. Maybe it doesn't actually have the 24bit quality? Try this album, it definitely works for me: https://listen.tidal.com/album/110827651

jozefKruszynski · 2023-08-16T21:45:32Z

I also just tested this album which definitely has only LOSSLESS and HI_RES_LOSSLESS and I only get the 16bit 41000Hz version returned.
https://listen.tidal.com/album/121124384

Odd, same thing happens to me with that specific album. Maybe it doesn't actually have the 24bit quality? Try this album, it definitely works for me: https://listen.tidal.com/album/110827651

I definitely get the 24bit version with this album too, although limited to 48000Hz, which may of course be the only thing that is available.
Would love to find an album that is 100% known to be 24bit 192KHz and test with that. Of course regions could also be affecting things here, my account was created in Austria, and obviously streaming rights will differ per territory.

EDIT:
As a side note, much as I hate to be that guy.... When might we see a new release of the library?
Sorry, I'll accept the chastising that comes with such a question...

tehkillerbee · 2023-08-17T07:15:51Z

24bit 192KHz

Yes, I have yet to find one. Please let me know if you find one as I would like to have one to test with

When might we see a new release of the library?

No problem at all. It took a bit longer to get this PR processed and right now I am working on a small feature related to the "explore" and "for you" pages, then I will make a new release this weekend. 👍

jozefKruszynski · 2023-08-17T12:24:19Z

The tests that rely on contest.py line 118 no longer work after this merge unfortunately.

tehkillerbee · 2023-08-17T13:11:15Z

The tests that rely on contest.py line 118 no longer work after this merge unfortunately.

Thanks for letting me know. Yes, I must've overlooked it when doing a search through the sources. I will fix it later today.

jozefKruszynski · 2023-08-17T13:13:19Z

The tests that rely on contest.py line 118 no longer work after this merge unfortunately.

Thanks for letting me know. Yes, I must've overlooked it when doing a search through the sources. I will fix it later today.

I've fixed it in a PR that I just pushed. If you would like me to split that PR into a fix for that, and the new feature that I am proposing I can do this also.

tehkillerbee · 2023-08-17T13:14:04Z

Thanks I see you have already made a PR for it. That's fine, no need to split it into a separate PR :)

alexandru0-dev · 2023-08-24T15:00:57Z

@jozefKruszynski This album is 24bit 192kHz: https://tidal.com/browse/album/539203
I checked that with an external audio usb DAC.
The lib even when setting HI_RES_LOSSLESS as quality downloads at 48kHz.
@tehkillerbee any idea of why?

tehkillerbee · 2023-08-24T15:14:11Z

@alexandru0-dev

Not sure either , so far I have not been able to get any tracks with a higher bitrate than 48kHz/24bit, so I thought it was dependent on the album.

Can you make a new issue for this so we do not use the PR for further discussions?

alexandru0-dev · 2023-08-24T15:35:13Z

Can you make a new issue for this so we do not use the PR for further discussions?

Done

tehkillerbee linked an issue Aug 5, 2023 that may be closed by this pull request

Quality "HIGH" for HiRes-FLAC from August 2023? #172

Closed

This was referenced Aug 5, 2023

Unsupported MIX types #173

Closed

Getting image of artist fails #167

Closed

tehkillerbee requested a review from 2e0byo August 5, 2023 16:47

2e0byo force-pushed the 172-quality-high-for-hires-flac-from-august-2023 branch from a52fc66 to 8a08c97 Compare August 6, 2023 17:10

2e0byo requested changes Aug 6, 2023

View reviewed changes

tidalapi/session.py Outdated Show resolved Hide resolved

tehkillerbee added 7 commits August 7, 2023 22:01

Added helper functions to set audio, video quality.

44a710e

Version bump

3f68491

Added missing WELCOME_MIX MixType

026efdc

Removed obsolete image URL. Set a sensible default resolution for all…

0cbcf97

… functions returning image URL..

Lint fixes

786b36f

Use python decorators for getter, setter. Use enum validation

29b942c

Set default dimensions for artist picture

e2c121f

tehkillerbee force-pushed the 172-quality-high-for-hires-flac-from-august-2023 branch from 42618fe to e2c121f Compare August 7, 2023 20:06

Use enum value when setting quality. Remove default quality

6c503c7

2e0byo reviewed Aug 13, 2023

View reviewed changes

README.rst Outdated Show resolved Hide resolved

2e0byo added 3 commits August 13, 2023 10:26

fix: return types.

bf5b105

fix: video quality.

06917ce

tests: quality.

8f6339e

docs: quality.

adc1d9f

2e0byo approved these changes Aug 13, 2023

View reviewed changes

tehkillerbee added 5 commits August 16, 2023 19:50

Version bump

63bd407

Renamed Quality options to correspond with Tidal Web player

ef7c0a8

Updated quality tests

89b716a

Updated readme

bafb642

Format fix

1e8d75b

tehkillerbee merged commit 1389107 into master Aug 16, 2023

tehkillerbee deleted the 172-quality-high-for-hires-flac-from-august-2023 branch October 14, 2024 20:09

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Feature/Add ability to set audio/video quality for session + bugfixes #174

Feature/Add ability to set audio/video quality for session + bugfixes #174

tehkillerbee commented Aug 5, 2023

2e0byo left a comment

jozefKruszynski commented Aug 9, 2023

tehkillerbee commented Aug 9, 2023

jozefKruszynski commented Aug 9, 2023 •

edited

Loading

tehkillerbee commented Aug 9, 2023 •

edited

Loading

tehkillerbee commented Aug 9, 2023 •

edited

Loading

jozefKruszynski commented Aug 10, 2023

jozefKruszynski commented Aug 10, 2023 •

edited

Loading

2e0byo commented Aug 13, 2023

tehkillerbee commented Aug 13, 2023 •

edited

Loading

tehkillerbee commented Aug 13, 2023 •

edited

Loading

2e0byo commented Aug 13, 2023

jozefKruszynski commented Aug 14, 2023

tehkillerbee commented Aug 14, 2023

tehkillerbee commented Aug 14, 2023

jozefKruszynski commented Aug 14, 2023 •

edited

Loading

2e0byo commented Aug 14, 2023 •

edited

Loading

tehkillerbee commented Aug 16, 2023

jozefKruszynski commented Aug 16, 2023 •

edited

Loading

tehkillerbee commented Aug 17, 2023

jozefKruszynski commented Aug 17, 2023

tehkillerbee commented Aug 17, 2023 •

edited

Loading

jozefKruszynski commented Aug 17, 2023

tehkillerbee commented Aug 17, 2023

alexandru0-dev commented Aug 24, 2023

tehkillerbee commented Aug 24, 2023

alexandru0-dev commented Aug 24, 2023

Feature/Add ability to set audio/video quality for session + bugfixes #174

Feature/Add ability to set audio/video quality for session + bugfixes #174

Conversation

tehkillerbee commented Aug 5, 2023

2e0byo left a comment

Choose a reason for hiding this comment

jozefKruszynski commented Aug 9, 2023

tehkillerbee commented Aug 9, 2023

jozefKruszynski commented Aug 9, 2023 • edited Loading

tehkillerbee commented Aug 9, 2023 • edited Loading

tehkillerbee commented Aug 9, 2023 • edited Loading

jozefKruszynski commented Aug 10, 2023

jozefKruszynski commented Aug 10, 2023 • edited Loading

2e0byo commented Aug 13, 2023

tehkillerbee commented Aug 13, 2023 • edited Loading

tehkillerbee commented Aug 13, 2023 • edited Loading

2e0byo commented Aug 13, 2023

jozefKruszynski commented Aug 14, 2023

tehkillerbee commented Aug 14, 2023

tehkillerbee commented Aug 14, 2023

jozefKruszynski commented Aug 14, 2023 • edited Loading

2e0byo commented Aug 14, 2023 • edited Loading

tehkillerbee commented Aug 16, 2023

jozefKruszynski commented Aug 16, 2023 • edited Loading

tehkillerbee commented Aug 17, 2023

jozefKruszynski commented Aug 17, 2023

tehkillerbee commented Aug 17, 2023 • edited Loading

jozefKruszynski commented Aug 17, 2023

tehkillerbee commented Aug 17, 2023

alexandru0-dev commented Aug 24, 2023

tehkillerbee commented Aug 24, 2023

alexandru0-dev commented Aug 24, 2023

jozefKruszynski commented Aug 9, 2023 •

edited

Loading

tehkillerbee commented Aug 9, 2023 •

edited

Loading

tehkillerbee commented Aug 9, 2023 •

edited

Loading

jozefKruszynski commented Aug 10, 2023 •

edited

Loading

tehkillerbee commented Aug 13, 2023 •

edited

Loading

tehkillerbee commented Aug 13, 2023 •

edited

Loading

jozefKruszynski commented Aug 14, 2023 •

edited

Loading

2e0byo commented Aug 14, 2023 •

edited

Loading

jozefKruszynski commented Aug 16, 2023 •

edited

Loading

tehkillerbee commented Aug 17, 2023 •

edited

Loading