[GH-ISSUE #1583] Spotify lossless will not be supported

kerem commented

2026-02-27 19:32:08 +03:00

Owner

Originally created by @kingosticks on GitHub (Sep 15, 2025).
Original GitHub issue: https://github.com/librespot-org/librespot/issues/1583

Discussed in https://github.com/librespot-org/librespot/discussions/1578

^{Originally posted by michaelherger September 10, 2025}
https://newsroom.spotify.com/2025-09-10/lossless-listening-arrives-on-spotify-premium-with-a-richer-more-detailed-listening-experience/

(no pressure 😂)

I'm focusing on a few other things now, but depending on how Spotify implemented this it may actually not be difficult.

Clearly removing the bitrate command line limitations won't work, but some years ago (yeah) I already took care to pave the way for FLAC support in the decoder and audio file selection. If the FLACs and its decryption keys are served over the same way as the Ogg Vorbis files, then that could be quick work... any takers?

Originally posted by @roderickvd in https://github.com/librespot-org/librespot/discussions/1578#discussioncomment-14377362

It would be nice to have real files to check if there is anything to take into account, like with ogg (header) https://github.com/librespot-org/librespot/blob/dev/playback/src/player.rs#L1050 but yeah, it should be a pretty quick work

Originally posted by @SuisChan in https://github.com/librespot-org/librespot/discussions/1578#discussioncomment-14377540

Originally created by @kingosticks on GitHub (Sep 15, 2025). Original GitHub issue: https://github.com/librespot-org/librespot/issues/1583 ### Discussed in https://github.com/librespot-org/librespot/discussions/1578 <div type='discussions-op-text'> <sup>Originally posted by **michaelherger** September 10, 2025</sup> https://newsroom.spotify.com/2025-09-10/lossless-listening-arrives-on-spotify-premium-with-a-richer-more-detailed-listening-experience/ (no pressure 😂)</div> ----------------- I'm focusing on a few other things now, but depending on how Spotify implemented this it may actually not be difficult. Clearly removing the bitrate command line limitations won't work, but some years ago (yeah) I already took care to pave the way for FLAC support in the decoder and audio file selection. If the FLACs and its decryption keys are served over the same way as the Ogg Vorbis files, then that could be quick work... any takers? _Originally posted by @roderickvd in https://github.com/librespot-org/librespot/discussions/1578#discussioncomment-14377362_ ------------------ It would be nice to have real files to check if there is anything to take into account, like with ogg (header) [https://github.com/librespot-org/librespot/blob/dev/playback/src/player.rs#L1050](https://github.com/librespot-org/librespot/blob/dev/playback/src/player.rs#L1050) but yeah, it should be a pretty quick work _Originally posted by @SuisChan in https://github.com/librespot-org/librespot/discussions/1578#discussioncomment-14377540_

kerem added the

audio

SpotifyAPI

labels

2026-02-27 19:32:08 +03:00

kerem commented

2026-02-27 19:32:08 +03:00

Author

Owner

@roderickvd commented on GitHub (Sep 18, 2025):

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.

@roderickvd commented on GitHub (Sep 18, 2025): 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.

kerem commented

2026-02-27 19:32:08 +03:00

Author

Owner

@heinzgruber commented on GitHub (Sep 19, 2025):

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

@heinzgruber commented on GitHub (Sep 19, 2025): 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

kerem commented

2026-02-27 19:32:08 +03:00

Author

Owner

@guredora403 commented on GitHub (Sep 21, 2025):

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.

@guredora403 commented on GitHub (Sep 21, 2025): 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.

kerem commented

2026-02-27 19:32:08 +03:00

Author

Owner

@clepdn commented on GitHub (Sep 25, 2025):

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?

@clepdn commented on GitHub (Sep 25, 2025): 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?

kerem commented

2026-02-27 19:32:08 +03:00

Author

Owner

@roderickvd commented on GitHub (Sep 25, 2025):

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.

@roderickvd commented on GitHub (Sep 25, 2025): 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.

kerem commented

2026-02-27 19:32:08 +03:00

Author

Owner

@kingosticks commented on GitHub (Sep 25, 2025):

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.

@kingosticks commented on GitHub (Sep 25, 2025): 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.

kerem commented

2026-02-27 19:32:08 +03:00

Author

Owner

@clepdn commented on GitHub (Sep 27, 2025):

it’s the desktop application for windows, since that’s the only way I can stream lossless right now

@clepdn commented on GitHub (Sep 27, 2025): it’s the desktop application for windows, since that’s the only way I can stream lossless right now

kerem commented

2026-02-27 19:32:08 +03:00

Author

Owner

@SuisChan commented on GitHub (Sep 29, 2025):

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.).

@SuisChan commented on GitHub (Sep 29, 2025): 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.).

kerem commented

2026-02-27 19:32:08 +03:00

Author

Owner

@kingosticks commented on GitHub (Sep 29, 2025):

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?

@kingosticks commented on GitHub (Sep 29, 2025): 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?

kerem commented

2026-02-27 19:32:08 +03:00

Author

Owner

@SuisChan commented on GitHub (Sep 29, 2025):

but I don't see fileid d66a44eea7819cbce00e9c9e2abbe7f373bc60ed anywhere in the response from

Must be from the extended-metadata response @ AUDIO_FILES, here it is, haven't seen it anywhere else

If you link the track URI, I can check it now

edit: In fact, the app might not have had to make a request just now to get the file_id, since it might already be cached in their database, it caches a lot of things, including protobuf responses.

@SuisChan commented on GitHub (Sep 29, 2025): > but I don't see `fileid` d66a44eea7819cbce00e9c9e2abbe7f373bc60ed anywhere in the response from Must be from the `extended-metadata` response @ `AUDIO_FILES`, here it is, haven't seen it anywhere else If you link the track URI, I can check it now edit: In fact, the app might not have had to make a request just now to get the `file_id`, since it might already be cached in their database, it caches a lot of things, including protobuf responses.

kerem commented

2026-02-27 19:32:08 +03:00

Author

Owner

@vemsom commented on GitHub (Sep 29, 2025):

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.).

Wouldn't this be part of the configuration?
The player is configured for a specific bit rate already (for ex. BITRATE="320")

@vemsom commented on GitHub (Sep 29, 2025): > 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.). Wouldn't this be part of the configuration? The player is configured for a specific bit rate already (for ex. BITRATE="320")

kerem commented

2026-02-27 19:32:08 +03:00

Author

Owner

@kingosticks commented on GitHub (Sep 29, 2025):

@SuisChan track fb24dfb1ea0043f9afdd8633a3b75e1b
I had deleted the cache so i don't think it's that, I see it doing all the other requests.

@kingosticks commented on GitHub (Sep 29, 2025): @SuisChan track fb24dfb1ea0043f9afdd8633a3b75e1b I had deleted the cache so i don't think it's that, I see it doing all the other requests.

kerem commented

2026-02-27 19:32:08 +03:00

Author

Owner

@SuisChan commented on GitHub (Sep 29, 2025):

I had deleted the cache so i don't think it's that

Oh okay, but I can confirm that the AUDIO_FILES response contains that file_id. Let Me by Anxious spotify:track:7L77eB8vi2vpuqniEHqdzl, right?

Wouldn't this be part of the configuration?

Someone might try to enable lossless without even knowing whether it's available, so... idk

@SuisChan commented on GitHub (Sep 29, 2025): > I had deleted the cache so i don't think it's that Oh okay, but I can confirm that the `AUDIO_FILES` response contains that `file_id`. `Let Me` by `Anxious` `spotify:track:7L77eB8vi2vpuqniEHqdzl`, right? > Wouldn't this be part of the configuration? Someone might try to enable lossless without even knowing whether it's available, so... idk

kerem commented

2026-02-27 19:32:08 +03:00

Author

Owner

@SuisChan commented on GitHub (Sep 29, 2025):

And it looks like there are no additional headers or anything, just raw FLAC files without any modifications.

huh! Even better, head-fa files are just a chunk of the original, they are identical down to the last bit

@SuisChan commented on GitHub (Sep 29, 2025): > * And it looks like there are no additional headers or anything, just raw FLAC files without any modifications. huh! Even better, `head-fa` files are just a chunk of the original, they are identical down to the last bit

kerem commented

2026-02-27 19:32:08 +03:00

Author

Owner

@SuisChan commented on GitHub (Sep 29, 2025):

Not so good news, on my end the keys to lossless don't work via shannon, someone needs to check and confirm or prove me wrong...

@SuisChan commented on GitHub (Sep 29, 2025): Not so good news, on my end the keys to lossless don't work via shannon, someone needs to check and confirm or prove me wrong...

kerem commented

2026-02-27 19:32:08 +03:00

Author

Owner

@kingosticks commented on GitHub (Sep 29, 2025):

Oh okay, but I can confirm that the AUDIO_FILES response contains that file_id. Let Me by Anxious spotify:track:7L77eB8vi2vpuqniEHqdzl, right?

Yep, thanks. I see this now. I didn't realise there were different kinds of extended metadata requests.

@kingosticks commented on GitHub (Sep 29, 2025): > Oh okay, but I can confirm that the `AUDIO_FILES` response contains that `file_id`. `Let Me` by `Anxious` `spotify:track:7L77eB8vi2vpuqniEHqdzl`, right? Yep, thanks. I see this now. I didn't realise there were different kinds of extended metadata requests.

kerem commented

2026-02-27 19:32:08 +03:00

Author

Owner

@Fletcher-Alderton commented on GitHub (Oct 1, 2025):

Hey, I have Spotify lossless on all my devices and would love to get it on Librespot. Is there anyway I can help?

@Fletcher-Alderton commented on GitHub (Oct 1, 2025): Hey, I have Spotify lossless on all my devices and would love to get it on Librespot. Is there anyway I can help?

kerem commented

2026-02-27 19:32:08 +03:00

Author

Owner

@AmilieDev commented on GitHub (Oct 1, 2025):

Is there any specific documentation on this with Shannon? If so I'll toy around myself and see if this is just a you issue or a completely new hurdle. Would be appreciated for a link. ^-^

Not so good news, on my end the keys to lossless don't work via shannon, someone needs to check and confirm or prove me wrong...

@AmilieDev commented on GitHub (Oct 1, 2025): Is there any specific documentation on this with Shannon? If so I'll toy around myself and see if this is just a you issue or a completely new hurdle. Would be appreciated for a link. ^-^ > Not so good news, on my end the keys to lossless don't work via shannon, someone needs to check and confirm or prove me wrong...

kerem commented

2026-02-27 19:32:08 +03:00

Author

Owner

@SuisChan commented on GitHub (Oct 1, 2025):

Is there any specific documentation on this with Shannon? If so I'll toy around myself and see if this is just a you issue or a completely new hurdle. Would be appreciated for a link. ^-^

@AmilieCoding, nothing special, just use the function to request keys with the correct track_id and file_id. You can easily get the file_id (lossless) using dev-tools (spicetify enable-devtools, then ctrl+shift+D in the application), and you'll find everything you need in the playback window. I just used a slightly modified play example. https://github.com/librespot-org/librespot/blob/dev/examples/play.rs

If it works, you'll get a key. If not... well, either lossless won't be supported, or significant changes might be required...

example

use std::process::exit;

use librespot_core::{FileId, Session, SessionConfig, SpotifyId, authentication::Credentials};
use librespot_protocol::authentication::AuthenticationType;

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
  let session_config = SessionConfig::default();

  let credentials = Credentials {
      username: Some("username".to_string()),
      auth_type: AuthenticationType::AUTHENTICATION_STORED_SPOTIFY_CREDENTIALS,
      auth_data: b"stored_credentials".to_vec(),
  };

  println!("Connecting...");
  let session = Session::new(session_config, None);
  if let Err(e) = session.connect(credentials, false).await {
      println!("Error connecting: {e}");
      exit(1);
  }

  println!("Authenticated as '{}' !", session.username());

  let track = SpotifyId::from_uri("spotify:track:2tdNI4jmNQkOT41LSTSA17").unwrap();

  let file_id_24bit = FileId::from_raw(&hex::decode("c976f33893d9c3a868b353cc761e68874a226faf")?);

  match session.audio_key().request(track, file_id_24bit).await {
      Ok(key) => println!("key @ {:#02x?}", key.0),
      Err(err) => println!("err @ {}", err.to_string()),
  }

  println!("Done");

  Ok(())
}

@SuisChan commented on GitHub (Oct 1, 2025): > Is there any specific documentation on this with Shannon? If so I'll toy around myself and see if this is just a you issue or a completely new hurdle. Would be appreciated for a link. ^-^ @AmilieCoding, nothing special, just use the [function to request keys](https://github.com/librespot-org/librespot/blob/a407beaa45e140f492f9cc5b3c5cdd3c7fe2ad69/playback/src/player.rs#L1063) with the correct `track_id` and `file_id`. You can easily get the `file_id` (lossless) using dev-tools (`spicetify enable-devtools`, then `ctrl+shift+D` in the application), and you'll find everything you need in the `playback` window. I just used a slightly modified play example. [https://github.com/librespot-org/librespot/blob/dev/examples/play.rs](https://github.com/librespot-org/librespot/blob/dev/examples/play.rs) If it works, you'll get a key. If not... well, either lossless won't be supported, or significant changes might be required... <details> <summary>example</summary> ```rust use std::process::exit; use librespot_core::{FileId, Session, SessionConfig, SpotifyId, authentication::Credentials}; use librespot_protocol::authentication::AuthenticationType; #[tokio::main] async fn main() -> Result<(), Box<dyn std::error::Error>> { let session_config = SessionConfig::default(); let credentials = Credentials { username: Some("username".to_string()), auth_type: AuthenticationType::AUTHENTICATION_STORED_SPOTIFY_CREDENTIALS, auth_data: b"stored_credentials".to_vec(), }; println!("Connecting..."); let session = Session::new(session_config, None); if let Err(e) = session.connect(credentials, false).await { println!("Error connecting: {e}"); exit(1); } println!("Authenticated as '{}' !", session.username()); let track = SpotifyId::from_uri("spotify:track:2tdNI4jmNQkOT41LSTSA17").unwrap(); let file_id_24bit = FileId::from_raw(&hex::decode("c976f33893d9c3a868b353cc761e68874a226faf")?); match session.audio_key().request(track, file_id_24bit).await { Ok(key) => println!("key @ {:#02x?}", key.0), Err(err) => println!("err @ {}", err.to_string()), } println!("Done"); Ok(()) } ``` </details>

kerem commented

2026-02-27 19:32:08 +03:00

Author

Owner

@Lustyn commented on GitHub (Oct 2, 2025):

I have yet to figure out keys, but I can confirm that the current format values (16 and 22) for FLAC and FLAC_24 respectively are correct. It seems the API we are currently using for retrieving audio files does not support FLAC but whatever spotify.playback_esperanto.proto.PlaybackService/GetFiles is using receives it.

POST spotify.playback_esperanto.proto.PlaybackService/GetFiles

{
    "1": "spotify:track:0aNdtLrUvMMSKZ2EqEFYJK"
}

->

{
    "2": [
        {
            "1": "0bd90f1f59709a0bb39aa599af0a7d7b69e23af3",
            "2": "ogg/vorbis",
            "3": 96000
        },
        {
            "1": "009268940493d5776403c4c766df69a108aa43e5",
            "2": "flac/flac",
            "3": 1400000,
            "4": 22
        },
        {
            "1": "ee53b08f22eae71b171ed84c6af69e2ab4bc2337",
            "2": "flac/flac",
            "3": 700000,
            "4": 16
        },
        {
            "1": "73727fd0675d9bf71166ee3eecbfce3ce1265e37",
            "2": "ogg/vorbis",
            "3": 320000,
            "4": 2
        },
        {
            "1": "9b5d26dba99da845821d5d9da133b2ecc9f8afdc",
            "2": "spac/aac",
            "3": 24000,
            "4": 8
        },
        {
            "1": "a96e546c001db26943bd352e460b9affa532fe81",
            "2": "ogg/vorbis",
            "3": 160000,
            "4": 1
        }
    ]
}

@Lustyn commented on GitHub (Oct 2, 2025): I have yet to figure out keys, but I can confirm that the current format values (16 and 22) for FLAC and FLAC_24 respectively are correct. It seems the API we are currently using for retrieving audio files does not support FLAC but whatever `spotify.playback_esperanto.proto.PlaybackService/GetFiles` is using receives it. <details> ``` POST spotify.playback_esperanto.proto.PlaybackService/GetFiles { "1": "spotify:track:0aNdtLrUvMMSKZ2EqEFYJK" } -> { "2": [ { "1": "0bd90f1f59709a0bb39aa599af0a7d7b69e23af3", "2": "ogg/vorbis", "3": 96000 }, { "1": "009268940493d5776403c4c766df69a108aa43e5", "2": "flac/flac", "3": 1400000, "4": 22 }, { "1": "ee53b08f22eae71b171ed84c6af69e2ab4bc2337", "2": "flac/flac", "3": 700000, "4": 16 }, { "1": "73727fd0675d9bf71166ee3eecbfce3ce1265e37", "2": "ogg/vorbis", "3": 320000, "4": 2 }, { "1": "9b5d26dba99da845821d5d9da133b2ecc9f8afdc", "2": "spac/aac", "3": 24000, "4": 8 }, { "1": "a96e546c001db26943bd352e460b9affa532fe81", "2": "ogg/vorbis", "3": 160000, "4": 1 } ] } ``` </details>

kerem commented

2026-02-27 19:32:09 +03:00

Author

Owner

@pickpocket commented on GitHub (Oct 2, 2025):

Is there any specific documentation on this with Shannon? If so I'll toy around myself and see if this is just a you issue or a completely new hurdle. Would be appreciated for a link. ^-^

@AmilieCoding, nothing special, just use the function to request keys with the correct track_id and file_id. You can easily get the file_id (lossless) using dev-tools (spicetify enable-devtools, then ctrl+shift+D in the application), and you'll find everything you need in the playback window. I just used a slightly modified play example. https://github.com/librespot-org/librespot/blob/dev/examples/play.rs

If it works, you'll get a key. If not... well, either lossless won't be supported, or significant changes might be required...
example

use std::process::exit;

use librespot_core::{FileId, Session, SessionConfig, SpotifyId, authentication::Credentials};
use librespot_protocol::authentication::AuthenticationType;

#[tokio::main]
async fn main() -> Result<(), Box> {
let session_config = SessionConfig::default();

let credentials = Credentials {
username: Some("username".to_string()),
auth_type: AuthenticationType::AUTHENTICATION_STORED_SPOTIFY_CREDENTIALS,
auth_data: b"stored_credentials".to_vec(),
};

println!("Connecting...");
let session = Session::new(session_config, None);
if let Err(e) = session.connect(credentials, false).await {
println!("Error connecting: {e}");
exit(1);
}

println!("Authenticated as '{}' !", session.username());

let track = SpotifyId::from_uri("spotify:track:2tdNI4jmNQkOT41LSTSA17").unwrap();

let file_id_24bit = FileId::from_raw(&hex::decode("c976f33893d9c3a868b353cc761e68874a226faf")?);

match session.audio_key().request(track, file_id_24bit).await {
Ok(key) => println!("key @ {:#02x?}", key.0),
Err(err) => println!("err @ {}", err.to_string()),
}

println!("Done");

Ok(())
}

My account has lossless. I tested this and got err @ Service unavailable { audio key error }

I have a strong feeling this is because the session config needs to be updated.

@pickpocket commented on GitHub (Oct 2, 2025): > > Is there any specific documentation on this with Shannon? If so I'll toy around myself and see if this is just a you issue or a completely new hurdle. Would be appreciated for a link. ^-^ > > [@AmilieCoding](https://github.com/AmilieCoding), nothing special, just use the [function to request keys](https://github.com/librespot-org/librespot/blob/a407beaa45e140f492f9cc5b3c5cdd3c7fe2ad69/playback/src/player.rs#L1063) with the correct `track_id` and `file_id`. You can easily get the `file_id` (lossless) using dev-tools (`spicetify enable-devtools`, then `ctrl+shift+D` in the application), and you'll find everything you need in the `playback` window. I just used a slightly modified play example. https://github.com/librespot-org/librespot/blob/dev/examples/play.rs > > If it works, you'll get a key. If not... well, either lossless won't be supported, or significant changes might be required... > example > > use std::process::exit; > > use librespot_core::{FileId, Session, SessionConfig, SpotifyId, authentication::Credentials}; > use librespot_protocol::authentication::AuthenticationType; > > #[tokio::main] > async fn main() -> Result<(), Box<dyn std::error::Error>> { > let session_config = SessionConfig::default(); > > let credentials = Credentials { > username: Some("username".to_string()), > auth_type: AuthenticationType::AUTHENTICATION_STORED_SPOTIFY_CREDENTIALS, > auth_data: b"stored_credentials".to_vec(), > }; > > println!("Connecting..."); > let session = Session::new(session_config, None); > if let Err(e) = session.connect(credentials, false).await { > println!("Error connecting: {e}"); > exit(1); > } > > println!("Authenticated as '{}' !", session.username()); > > let track = SpotifyId::from_uri("spotify:track:2tdNI4jmNQkOT41LSTSA17").unwrap(); > > let file_id_24bit = FileId::from_raw(&hex::decode("c976f33893d9c3a868b353cc761e68874a226faf")?); > > match session.audio_key().request(track, file_id_24bit).await { > Ok(key) => println!("key @ {:#02x?}", key.0), > Err(err) => println!("err @ {}", err.to_string()), > } > > println!("Done"); > > Ok(()) > } My account has lossless. I tested this and got err @ Service unavailable { audio key error } I have a strong feeling this is because the session config needs to be updated.

kerem commented

2026-02-27 19:32:09 +03:00

Author

Owner

@SuisChan commented on GitHub (Oct 2, 2025):

the session config needs to be updated

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.

@SuisChan commented on GitHub (Oct 2, 2025): > the session config needs to be updated 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.

kerem commented

2026-02-27 19:32:09 +03:00

Author

Owner

@kingosticks commented on GitHub (Oct 2, 2025):

I did see the desktop app doing requests to playplay for keys. Isn't that their DRM-based system? But it seemed to be doing that for both lossless and lossy audio quality modes.

@kingosticks commented on GitHub (Oct 2, 2025): I did see the desktop app doing requests to playplay for keys. Isn't that their DRM-based system? But it seemed to be doing that for both lossless and lossy audio quality modes.

kerem commented

2026-02-27 19:32:09 +03:00

Author

Owner

@SuisChan commented on GitHub (Oct 2, 2025):

Isn't that their DRM-based system?

That's exactly it

@SuisChan commented on GitHub (Oct 2, 2025): > Isn't that their DRM-based system? That's exactly it

kerem commented

2026-02-27 19:32:09 +03:00

Author

Owner

@AmilieDev commented on GitHub (Oct 2, 2025):

Is there any specific documentation on this with Shannon? If so I'll toy around myself and see if this is just a you issue or a completely new hurdle. Would be appreciated for a link. ^-^

@AmilieCoding, nothing special, just use the function to request keys with the correct track_id and file_id. You can easily get the file_id (lossless) using dev-tools (spicetify enable-devtools, then ctrl+shift+D in the application), and you'll find everything you need in the playback window. I just used a slightly modified play example. https://github.com/librespot-org/librespot/blob/dev/examples/play.rs

If it works, you'll get a key. If not... well, either lossless won't be supported, or significant changes might be required...
example

I haven't been able to personally get this working - but that's just because I'm a god awful programmer.

I did manage to take a look though and I did see something about DRM keys as mentioned above by @kingosticks . Would be worth taking a look into.

@AmilieDev commented on GitHub (Oct 2, 2025): > > Is there any specific documentation on this with Shannon? If so I'll toy around myself and see if this is just a you issue or a completely new hurdle. Would be appreciated for a link. ^-^ > > [@AmilieCoding](https://github.com/AmilieCoding), nothing special, just use the [function to request keys](https://github.com/librespot-org/librespot/blob/a407beaa45e140f492f9cc5b3c5cdd3c7fe2ad69/playback/src/player.rs#L1063) with the correct `track_id` and `file_id`. You can easily get the `file_id` (lossless) using dev-tools (`spicetify enable-devtools`, then `ctrl+shift+D` in the application), and you'll find everything you need in the `playback` window. I just used a slightly modified play example. https://github.com/librespot-org/librespot/blob/dev/examples/play.rs > > If it works, you'll get a key. If not... well, either lossless won't be supported, or significant changes might be required... > example I haven't been able to personally get this working - but that's just because I'm a god awful programmer. I did manage to take a look though and I did see something about DRM keys as mentioned above by @kingosticks . Would be worth taking a look into.

kerem commented

2026-02-27 19:32:09 +03:00

Author

Owner

@SuisChan commented on GitHub (Oct 3, 2025):

Would be worth taking a look into.

Uhhh, I'm not entirely sure about that.

Spotify doesn't even want to think about anyone else using playplay DRM.
I'd say that as soon as something is revealed, it will be removed due to DMCA. They even added it to their bug bounty scope list.

It's an interesting opportunity tbh, but they didn't provide enough information or criteria to be considered an acceptable bug report.

@SuisChan commented on GitHub (Oct 3, 2025): > Would be worth taking a look into. Uhhh, I'm not entirely sure about that. Spotify doesn't even want to think about anyone else using playplay DRM. I'd say that as soon as something is revealed, it will be removed due to DMCA. They even added it to their bug bounty scope list. It's an interesting opportunity tbh, but they didn't provide enough information or criteria to be considered an acceptable bug report.

kerem commented

2026-02-27 19:32:09 +03:00

Author

Owner

@Laxii-null commented on GitHub (Oct 3, 2025):

so are we actually close to the implemention of the lossless in the librespot? 🤔

@Laxii-null commented on GitHub (Oct 3, 2025): so are we actually close to the implemention of the lossless in the librespot? 🤔

kerem commented

2026-02-27 19:32:09 +03:00

Author

Owner

@AmilieDev commented on GitHub (Oct 4, 2025):

Would be worth taking a look into.

Uhhh, I'm not entirely sure about that.

Spotify doesn't even want to think about anyone else using playplay DRM. I'd say that as soon as something is revealed, it will be removed due to DMCA. They even added it to their bug bounty scope list.

It's an interesting opportunity tbh, but they didn't provide enough information or criteria to be considered an acceptable bug report.

I see okay, so DRM is something to avoid as a whole from what I'm seeing? Got it. 👍

@AmilieDev commented on GitHub (Oct 4, 2025): > > Would be worth taking a look into. > > Uhhh, I'm not entirely sure about that. > > Spotify doesn't even want to think about anyone else using playplay DRM. I'd say that as soon as something is revealed, it will be removed due to DMCA. They even added it to their bug bounty scope list. > > It's an interesting opportunity tbh, but they didn't provide enough information or criteria to be considered an acceptable bug report. I see okay, so DRM is something to avoid as a whole from what I'm seeing? Got it. 👍

kerem commented

2026-02-27 19:32:09 +03:00

Author

Owner

@SuisChan commented on GitHub (Oct 4, 2025):

I see okay, so DRM is something to avoid as a whole from what I'm seeing? Got it. 👍

Just saying don't be surprised if all your efforts go to waste, which is what will most likely happen

@SuisChan commented on GitHub (Oct 4, 2025): > I see okay, so DRM is something to avoid as a whole from what I'm seeing? Got it. 👍 Just saying don't be surprised if all your efforts go to waste, which is what will most likely happen

kerem commented

2026-02-27 19:32:09 +03:00

Author

Owner

@roderickvd commented on GitHub (Oct 5, 2025):

I think most efforts to crack the new decryption have been from decompiling or some other white box approach. The best chance we have is by taking a black box approach: develop a decryption algorithm ourselves without looking at any protected code.

@roderickvd commented on GitHub (Oct 5, 2025): I think most efforts to crack the new decryption have been from decompiling or some other white box approach. The best chance we have is by taking a black box approach: develop a decryption algorithm ourselves without looking at any protected code.

kerem commented

2026-02-27 19:32:09 +03:00

Author

Owner

@roderickvd commented on GitHub (Oct 5, 2025):

To clarify a bit more on the output rather than on the process: this should result in a human-readable, pure Rust implementation with semantic names of functions, variables and such.

@roderickvd commented on GitHub (Oct 5, 2025): To clarify a bit more on the output rather than on the process: this should result in a human-readable, pure Rust implementation with semantic names of functions, variables and such.

kerem commented

2026-02-27 19:32:09 +03:00

Author

Owner

@Lustyn commented on GitHub (Oct 5, 2025):

I don't believe what @roderickvd is describing is possible if the only means to acquire keys for these files is to use PlayPlay. From what I understand that DRM scheme, very similarly to Widevine, does white-box cryptography. That means even if we reimplement the license request scheme the keys remain encrypted unless we use Spotify's code or otherwise recover the key from it.

So unless other means to acquire the keys are discovered (perhaps Shannon can provide them and we're just missing something) or Spotify graciously changes these restrictions at a later time, this issue is at a dead end. My guess would be that the PlayPlay restriction for lossless is very much intentional and Spotify only keeps Shannon around to allow librespot and others to continue to function out of goodwill.

@Lustyn commented on GitHub (Oct 5, 2025): I don't believe what @roderickvd is describing is possible if the only means to acquire keys for these files is to use PlayPlay. From what I understand that DRM scheme, very similarly to Widevine, does white-box cryptography. That means even if we reimplement the license request scheme the keys remain encrypted unless we use Spotify's code or otherwise recover the key from it. So unless other means to acquire the keys are discovered (perhaps Shannon can provide them and we're just missing something) or Spotify graciously changes these restrictions at a later time, this issue is at a dead end. My guess would be that the PlayPlay restriction for lossless is very much intentional and Spotify only keeps Shannon around to allow librespot and others to continue to function out of goodwill.

kerem commented

2026-02-27 19:32:09 +03:00

Author

Owner

@roderickvd commented on GitHub (Oct 5, 2025):

We can try using the private key. I mean, we’ve had keymaster keys in the codebase since the start. No guarantees for the future, but we can try.

Problem seems that so far, regardless of key, I’ve not seen a clean implementation.

@roderickvd commented on GitHub (Oct 5, 2025): We can try using the private key. I mean, we’ve had keymaster keys in the codebase since the start. No guarantees for the future, but we can try. Problem seems that so far, regardless of key, I’ve not seen a clean implementation.

kerem commented

2026-02-27 19:32:09 +03:00

Author

Owner

@photovoltex commented on GitHub (Oct 5, 2025):

My guess would be that the PlayPlay restriction for lossless is very much intentional and Spotify only keeps Shannon around to allow librespot and others to continue to function out of goodwill.

That's less a good will and more a necessity I would assume. As @SuisChan pointed out before, there are other devices who still use the old way of communicating. Mostly devices with spotify connect integration like receivers. They can't just update the firmware of these devices as with the clients. So those will probably never get lossless support unless the firmware of the device is updated.

I guess it would be interesting to know if anyone with lossless access and a receiver with connect integration could validate if lossless on the receiver would work.

@photovoltex commented on GitHub (Oct 5, 2025): > My guess would be that the PlayPlay restriction for lossless is very much intentional and Spotify only keeps Shannon around to allow librespot and others to continue to function out of goodwill. That's less a good will and more a necessity I would assume. As @SuisChan pointed out before, there are other devices who still use the old way of communicating. Mostly devices with spotify connect integration like receivers. They can't just update the firmware of these devices as with the clients. So those will probably never get lossless support unless the firmware of the device is updated. I guess it would be interesting to know if anyone with lossless access and a receiver with connect integration could validate if lossless on the receiver would work.

kerem commented

2026-02-27 19:32:09 +03:00

Author

Owner

@peteralm80 commented on GitHub (Oct 6, 2025):

My guess would be that the PlayPlay restriction for lossless is very much intentional and Spotify only keeps Shannon around to allow librespot and others to continue to function out of goodwill.

That's less a good will and more a necessity I would assume. As @SuisChan pointed out before, there are other devices who still use the old way of communicating. Mostly devices with spotify connect integration like receivers. They can't just update the firmware of these devices as with the clients. So those will probably never get lossless support unless the firmware of the device is updated.

I guess it would be interesting to know if anyone with lossless access and a receiver with connect integration could validate if lossless on the receiver would work.

The Marantz/Denon built-in HeOS player currently supports lossless.

@peteralm80 commented on GitHub (Oct 6, 2025): > > My guess would be that the PlayPlay restriction for lossless is very much intentional and Spotify only keeps Shannon around to allow librespot and others to continue to function out of goodwill. > > That's less a good will and more a necessity I would assume. As [@SuisChan](https://github.com/SuisChan) pointed out before, there are other devices who still use the old way of communicating. Mostly devices with spotify connect integration like receivers. They can't just update the firmware of these devices as with the clients. So those will probably never get lossless support unless the firmware of the device is updated. > > I guess it would be interesting to know if anyone with lossless access and a receiver with connect integration could validate if lossless on the receiver would work. The Marantz/Denon built-in HeOS player currently supports lossless.

kerem commented

2026-02-27 19:32:09 +03:00

Author

Owner

@d3xter-dev commented on GitHub (Oct 6, 2025):

My guess would be that the PlayPlay restriction for lossless is very much intentional and Spotify only keeps Shannon around to allow librespot and others to continue to function out of goodwill.

That's less a good will and more a necessity I would assume. As @SuisChan pointed out before, there are other devices who still use the old way of communicating. Mostly devices with spotify connect integration like receivers. They can't just update the firmware of these devices as with the clients. So those will probably never get lossless support unless the firmware of the device is updated.

I guess it would be interesting to know if anyone with lossless access and a receiver with connect integration could validate if lossless on the receiver would work.

Lossless via Spotify Connect works fine on my Denon AVR-X4500H, using HEOS.
But my Onkyo TX-NR575E does not support Lossless via Spotify Connect.

@d3xter-dev commented on GitHub (Oct 6, 2025): > > My guess would be that the PlayPlay restriction for lossless is very much intentional and Spotify only keeps Shannon around to allow librespot and others to continue to function out of goodwill. > > That's less a good will and more a necessity I would assume. As [@SuisChan](https://github.com/SuisChan) pointed out before, there are other devices who still use the old way of communicating. Mostly devices with spotify connect integration like receivers. They can't just update the firmware of these devices as with the clients. So those will probably never get lossless support unless the firmware of the device is updated. > > I guess it would be interesting to know if anyone with lossless access and a receiver with connect integration could validate if lossless on the receiver would work. Lossless via Spotify Connect works fine on my Denon AVR-X4500H, using HEOS. But my Onkyo TX-NR575E does not support Lossless via Spotify Connect.

kerem commented

2026-02-27 19:32:09 +03:00

Author

Owner

@drobotk commented on GitHub (Oct 6, 2025):

FYI, the is-pigeon product state attribute seems to be what enables lossless on my phone

@drobotk commented on GitHub (Oct 6, 2025): FYI, the `is-pigeon` product state attribute seems to be what enables lossless on my phone

kerem commented

2026-02-27 19:32:09 +03:00

Author

Owner

@drobotk commented on GitHub (Oct 6, 2025):

How does it know?

Also, the quality selection menu for librespot doesn't actually work, librespot plays what it wants

@drobotk commented on GitHub (Oct 6, 2025): <img width="349" height="65" alt="Image" src="https://github.com/user-attachments/assets/94ca3073-c207-40fc-a750-605e69836863" /> How does it know? Also, the quality selection menu for librespot doesn't actually work, librespot plays what *it* wants

kerem commented

2026-02-27 19:32:09 +03:00

Author

Owner

@miholobolo commented on GitHub (Oct 6, 2025):

My guess would be that the PlayPlay restriction for lossless is very much intentional and Spotify only keeps Shannon around to allow librespot and others to continue to function out of goodwill.

That's less a good will and more a necessity I would assume. As @SuisChan pointed out before, there are other devices who still use the old way of communicating. Mostly devices with spotify connect integration like receivers. They can't just update the firmware of these devices as with the clients. So those will probably never get lossless support unless the firmware of the device is updated.

I guess it would be interesting to know if anyone with lossless access and a receiver with connect integration could validate if lossless on the receiver would work.

I have access to lossless in the andorid app. My NAD C338 amp supports spotify connect and chromecast, but it does not work with lossless. I can select the lossless option when playing on the amp in both modes, it shows that i'ts playing but keeps skipping after a couple of seconds without playing a sound.

@miholobolo commented on GitHub (Oct 6, 2025): > > My guess would be that the PlayPlay restriction for lossless is very much intentional and Spotify only keeps Shannon around to allow librespot and others to continue to function out of goodwill. > > That's less a good will and more a necessity I would assume. As [@SuisChan](https://github.com/SuisChan) pointed out before, there are other devices who still use the old way of communicating. Mostly devices with spotify connect integration like receivers. They can't just update the firmware of these devices as with the clients. So those will probably never get lossless support unless the firmware of the device is updated. > > I guess it would be interesting to know if anyone with lossless access and a receiver with connect integration could validate if lossless on the receiver would work. I have access to lossless in the andorid app. My NAD C338 amp supports spotify connect and chromecast, but it does not work with lossless. I can select the lossless option when playing on the amp in both modes, it shows that i'ts playing but keeps skipping after a couple of seconds without playing a sound.

kerem commented

2026-02-27 19:32:09 +03:00

Author

Owner

@photovoltex commented on GitHub (Oct 6, 2025):

Also, the quality selection menu for librespot doesn't actually work, librespot plays what it wants

Yeah, I think we could look into adding support for external quality adjustment support. It shouldn't be to hard from the connect side, but I'm not so sure if our player supports switching the quality on the fly. But that's a different topic for now.

@photovoltex commented on GitHub (Oct 6, 2025): > Also, the quality selection menu for librespot doesn't actually work, librespot plays what it wants Yeah, I think we could look into adding support for external quality adjustment support. It shouldn't be to hard from the connect side, but I'm not so sure if our player supports switching the quality on the fly. But that's a different topic for now.

kerem commented

2026-02-27 19:32:09 +03:00

Author

Owner

@justinerickson commented on GitHub (Oct 9, 2025):

Anybody know how Chromecast Audio works? I wonder if enough people upvote this request to compel Spotify to support lossless with Chromecast Audio that might unstick other third-party Spotify devices too: https://community.spotify.com/t5/Live-Ideas/Allow-lossless-playback-to-Chromecast-Audio-device/idi-p/7138979

@justinerickson commented on GitHub (Oct 9, 2025): Anybody know how Chromecast Audio works? I wonder if enough people upvote this request to compel Spotify to support lossless with Chromecast Audio that might unstick other third-party Spotify devices too: https://community.spotify.com/t5/Live-Ideas/Allow-lossless-playback-to-Chromecast-Audio-device/idi-p/7138979

kerem commented

2026-02-27 19:32:09 +03:00

Author

Owner

@roderickvd commented on GitHub (Oct 10, 2025):

Chromecast devices need to have a public key that can only be signed by Google’s private key. Unless that private key leaks into the public, no chance to find it.

@roderickvd commented on GitHub (Oct 10, 2025): Chromecast devices need to have a public key that can only be signed by Google’s private key. Unless that private key leaks into the public, no chance to find it.

kerem commented

2026-02-27 19:32:09 +03:00

Author

Owner

@cshin1213 commented on GitHub (Oct 23, 2025):

HI everyone:
I noticed this issue for several days. I found it may be difficult for librespot to support spotify lossless.
Is this issue end? Or there is still a possibility to achieve this problem?

@cshin1213 commented on GitHub (Oct 23, 2025): HI everyone: I noticed this issue for several days. I found it may be difficult for librespot to support spotify lossless. Is this issue end? Or there is still a possibility to achieve this problem?

kerem commented

2026-02-27 19:32:09 +03:00

Author

Owner

@AmilieDev commented on GitHub (Oct 23, 2025):

HI everyone: I noticed this issue for several days. I found it may be difficult for librespot to support spotify lossless. Is this issue end? Or there is still a possibility to achieve this problem?

I believe the main issue currently is actually making proper human readable code, in a way which actually works with the project. As stated above by @SuisChan , it's not getting it to work - it's getting human readable code while it works

@AmilieDev commented on GitHub (Oct 23, 2025): > HI everyone: I noticed this issue for several days. I found it may be difficult for librespot to support spotify lossless. Is this issue end? Or there is still a possibility to achieve this problem? I believe the main issue currently is actually making proper human readable code, in a way which actually works with the project. As stated above by @SuisChan , it's not getting it to work - it's getting human readable code while it works

kerem commented

2026-02-27 19:32:09 +03:00

Author

Owner

@KernelFreeze commented on GitHub (Oct 28, 2025):

The main problem with PlayPlay is that it requires a private key to be provided to the decryption module, and Spotify invalidates any key they find published in any GitHub repository, then sends a DMCA to the repository. So even if we get a custom implementation of the decryption system, we would also need a way to distribute a key without risking a DMCA. Maybe it could be downloaded and extracted from an official binary when a user runs librespot, but I think that's still a big risk.

@KernelFreeze commented on GitHub (Oct 28, 2025): The main problem with PlayPlay is that it requires a private key to be provided to the decryption module, and Spotify invalidates any key they find published in any GitHub repository, then sends a DMCA to the repository. So even if we get a custom implementation of the decryption system, we would also need a way to distribute a key without risking a DMCA. Maybe it could be downloaded and extracted from an official binary when a user runs librespot, but I think that's still a big risk.

kerem commented

2026-02-27 19:32:09 +03:00

Author

Owner

@roderickvd commented on GitHub (Nov 6, 2025):

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.

@roderickvd commented on GitHub (Nov 6, 2025): 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.

kerem commented

2026-02-27 19:32:09 +03:00

Author

Owner

@sashahilton00 commented on GitHub (Nov 9, 2025):

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.

@sashahilton00 commented on GitHub (Nov 9, 2025): > 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.

kerem referenced this issue

2026-02-27 20:00:56 +03:00

[PR #721] [CLOSED] Bump vergen from 3.2.0 to 5.1.5 #1042

Rows
Columns

[GH-ISSUE #1583] Spotify lossless will not be supported #721

Discussed in https://github.com/librespot-org/librespot/discussions/1578