Appreciate all the offers for help, but please stick to the Spotify ToS: no sharing of files or accounts.
We'll need someone with time and access to lossless capabilities to propose a PR.

Maybe this is possible when librespot can play lossless:

https://community.spotify.com/t5/Live-Ideas/Add-Bit-Perfect-Playback-WASAPI-Exclusive-Mode-on-Windows/idi-p/7125179

Hello! I think this is truly an amazing project. I'm currently using Spotify's Windows desktop client and am successfully achieving lossless playback, so I'd love to contribute. However, I've been unable to figure out how to read the encrypted communication in the control plane. My apologies for that. Once I know that, I could observe the communication flow during normal playback versus FLAC playback.

i have lossless working and enabled for my account

the devtools for my desktop client show an AAC_24 (24-bit?) file format from a GET spclient.wg.spotify.com/metadata/4/track/{TRACK_GID}?market=from_token

here's the request response with a bit of junk and uuids removed.

{
    "gid": "...",
    "name": "Besties",
    ...
    "file": [
        {
            "file_id": "...",
            "format": "OGG_VORBIS_320"
        },
        ...
        {
            "file_id": "...",
            "format": "AAC_24"
        }
    ],
}

my devtools don't show me any actually useful information, like if it's fetching the actual audio data differently from the way it fetches other audio qualities. i maybe need a proxy or some mitm to get what the local backend is fetching?

For the AAC_24 part, probably it’s just the protobufs that need an update to map to FLAC_FLAC or similar.

Yes you can run a proxy to see where the desktop client is getting its files from.

When you say "desktop client" do you mean desktop client or do you mean web browser? We want to know what the former is doing, not the latter.

Hey, just a quick update on lossless.

• The files are served the same way.
• The encryption mode is the same, AES-128-CTR, as is the IV (72e067fbddc...).
• And it looks like there are no additional headers or anything, just raw FLAC files without any modifications.
• Players play the files without a problem, unlike Ogg Vorbis files (if you include the 0xA7 byte header).

Bitrate? Up to 24-bit (in my case, some files are up to 1800 kbps, if anyone's interested).

So, if there's a way to obtain keys through shannon, it would be easy to implement.

The other issue is that this won't be available to everyone, so some checks is needed to determine if the user is lossless-eligible (since this is a server-side restriction, different markets, etc.).

It became available on my account today but I couldn't find where the fileid my desktop app is using is actually coming from. I see requests to https://gew1-spclient.spotify.com/storage-resolve/v2/files/audio/interactive_prefetch/16/d66a44eea7819cbce00e9c9e2abbe7f373bc60ed and then https://audio-fa-l.spotifycdn.com/audio/d66a44eea7819cbce00e9c9e2abbe7f373bc60ed but I don't see fileid d66a44eea7819cbce00e9c9e2abbe7f373bc60ed anywhere in the response from https://spclient.wg.spotify.com/metadata/4/track/fb24dfb1ea0043f9afdd8633a3b75e1b Am I being dense?

We've redacted this discussion to ensure librespot's continued existence, and are now locking it. We've received communication from Spotify that makes it clear we cannot pursue development that circumvents their technical protections. We appreciate your understanding.

Or maybe spotify intentionally locked lossless behind playplay drm. I'm monitoring several repos, and based on the issues I see, there are some changes recently. For example, now when using a free account with the old protocol (shannon), you can't request keys in most cases. It seems this now only works with a premium sub.

This is a distinct possibility. What I would say is that it's possible that librespot needs to update some of it's client parameters to something more recent - it wouldn't be the first time we missed stuff because the version header we were sending was too old for a feature gate on the server side, or the proto requests we send are missing now required fields.

I think the first step would be to update the protobuf definitions to something a bit newer, though this will involve a fair bit of work as proto requests are all over the place. Once one then has a client that is more aligned with current spotify clients, I suspect it will become easier to inspect behaviour and improve functionality.

It would not surprise me if it were possible to retrieve lossless keys over shannon somehow - as many have pointed out Spotify don't want people poking around with their playplay DRM, and the best way to ensure that's the case is to have a means to pull the keys via shannon. Failing that I imagine that as more and more people want lossless, we'll see more hatchety approaches that have already been done, such as extracting the keys/compiled code and feeding the black box for decryption keys.