fixed oauth tokens for Tidal FLAC downloads

[dkvdm]

Solves #966

[sjbrownrigg]

Confirmed these credentials work — but the picture turns out to be more complicated than "these are the right ones", and I think it explains why people are reporting completely different results on this and on #998.

Short version: Tidal grants different entitlements to different official clients, and neither of the two client ids in circulation is served everything. The one currently on dev gets hi-res but is handed AAC for anything without a hi-res master. The one in this PR gets true lossless for those releases but is never offered hi-res at all. Which one you are running determines which half of the catalogue you can actually download losslessly.

All measurements below are on one Tidal account with a "Max" subscription, taken within a few minutes of each other, changing nothing but the client credentials.

The two clients

	fX2JxdmntZWK0ixT (on dev)	4N3n6Q1x95LL5K7p (this PR)
release with a hi-res master	DASH manifest → FLAC 24-bit	BTS manifest → FLAC 16/44.1
release without one	BTS manifest → AAC 320	BTS manifest → FLAC 16/44.1

Neither is strictly better. Swapping to this PR's credentials fixes the large majority of the catalogue and costs you 24-bit on the minority that has it.

How to tell which releases are which

audioQuality is not the field to look at — it reads LOSSLESS for everything, including hi-res albums. The useful one is mediaMetadata.tags:

Jean-Michel Jarre - OXYMORE         mediaMetadata.tags = ['LOSSLESS', 'HIRES_LOSSLESS']
Fortification 55 - Trancemigration  mediaMetadata.tags = ['LOSSLESS']

The second is the ordinary case. Tidal's own app badges it HIGH, which by the legend on Tidal's audio quality settings screen means 16-bit/44.1kHz — lossless. So the content is lossless; it is the client that decides whether you are given it.

The measurements

Same track (468653362, tagged ['LOSSLESS']), asking for every tier.

On dev's credentials — note it never offers FLAC, whatever you ask for:

asked LOSSLESS           -> audioQuality=HIGH  manifest=vnd.tidal.bts  codecs=mp4a.40.2
asked HI_RES             -> audioQuality=HIGH  manifest=vnd.tidal.bts  codecs=mp4a.40.2
asked HI_RES_LOSSLESS    -> audioQuality=HIGH  manifest=vnd.tidal.bts  codecs=mp4a.40.2

On this PR's credentials:

asked LOSSLESS           -> audioQuality=LOSSLESS  manifest=vnd.tidal.bts  codecs=flac
asked HI_RES_LOSSLESS    -> audioQuality=LOSSLESS  manifest=vnd.tidal.bts  codecs=flac

Downloaded and probed:

credentials	file	codec	rate	size
dev	.m4a	aac	44.1kHz	13.3 MB
this PR	.flac	flac 16-bit	44.1kHz	39.2 MB

And the reverse, on a release tagged HIRES_LOSSLESS:

track	dev credentials	this PR's credentials
Jarre — OXYMORE	FLAC 24/48, 18.1 MB	FLAC 16/44.1, 9.0 MB
Fleetwood Mac — Rumours	FLAC 24/96, 57.3 MB	FLAC 16/44.1, 18.4 MB

On this PR's credentials every request returns audioQuality=LOSSLESS over BTS; a DASH manifest is never offered, so #998's hi-res support has nothing to act on.

Why people are reporting different things

what you are running	hi-res releases	everything else
upstream dev	AAC (no DASH support)	AAC
dev + #998	FLAC 24-bit	AAC
dev + #1017	FLAC 16/44.1	FLAC 16/44.1
dev + #998 + #1017	FLAC 16/44.1	FLAC 16/44.1

That last row is worth noting: applying both PRs disables the hi-res path, because these credentials are never given a DASH manifest. So "#998 doesn't work for me" and "#998 works for me" can both be true depending on whether #1017 is also applied and which releases were tested.

Scale of it

Across 90 Tidal tracks in one library, all downloaded with #998 applied and quality = 4: 15 came back FLAC, 75 came back AAC. Every one of those 75 is a release Tidal lists as LOSSLESS and plays losslessly in its own app. The FLAC ones were major-label releases with hi-res masters; the rest were smaller independent labels.

What I ended up doing

Locally, using both: ask the hi-res client first, and if the manifest it returns is lossy, ask the other client before settling for it. Releases with a hi-res master keep the DASH path at 24-bit, and everything else arrives as 16/44.1 FLAC instead of AAC. The choice is made from the manifest actually returned rather than predicted in advance, so it adapts if Tidal changes what it serves.

The cost is that tokens are issued per client, so it needs a second authorisation of the same account — same subscription, effectively a second device — and a second token set in the config. I ran both clients concurrently, including simultaneous downloads, without Tidal refusing either.

I am happy to open that as a PR if it is useful, though it is obviously more involved than swapping two constants, and it would sit better on top of whichever of these lands first.

The open question

Tidal's own app plainly gets both: it shows MAX on the hi-res releases and HIGH on the lossless-only ones, from the same login. So at least one client is served both entitlements.

Does anyone know of a client id already in circulation that is served both? If so, this collapses to a one-line change and none of the two-client juggling is needed. That would be much better than what I have locally, and I would rather ask than assume the two ids we have are the only ones people know about.