[GH-ISSUE #152] Support saving audio files

kerem commented

2026-02-27 19:28:53 +03:00

Owner

Originally created by @paulo-raca on GitHub (Feb 14, 2018).
Original GitHub issue: https://github.com/librespot-org/librespot/issues/152

On my spotify-based application, I don't want to just playback the live audio stream, but also to fetch it for offline playback later.

So... Question 1, how do you fell about adding a fetch_audio_file method to the library, and what would be the best way to implement it?

I have hacked a simple patch to do so: https://github.com/paulo-raca/librespot/pull/278/commits/a83f355535cf679262e89261b65522d45a4195e3

It basically splits the flow of load_track in half:

The part responsible for fetching and decrypting the audio file is now on get_track_file, and is shared with the implementation of fetch_audio_file
The part that skips the first few bytes of the file (Ogg headers?) and creates a decoder continues implemented within load_track.

This works perfectly for Ogg Vorbis files, but not at all for other formats:

Using OTHER2 fetches a file successfully, but appears to be garbage (Maybe it has a different decryption scheme? Maybe I just have no idea what is the file format?)
Every other format panics with AudioKeyError.

Question 2, Has there been any investigation on the decryption of those files? (I'm mainly interested in AAC or FLAC

Originally created by @paulo-raca on GitHub (Feb 14, 2018). Original GitHub issue: https://github.com/librespot-org/librespot/issues/152 On my spotify-based application, I don't want to just playback the live audio stream, but also to fetch it for offline playback later. So... Question 1, how do you fell about adding a `fetch_audio_file` method to the library, and what would be the best way to implement it? I have hacked a simple patch to do so: https://github.com/paulo-raca/librespot/pull/278/commits/a83f355535cf679262e89261b65522d45a4195e3 It basically splits the flow of `load_track` in half: - The part responsible for fetching and decrypting the audio file is now on get_track_file, and is shared with the implementation of fetch_audio_file - The part that skips the first few bytes of the file (Ogg headers?) and creates a decoder continues implemented within load_track. This works perfectly for Ogg Vorbis files, but not at all for other formats: - Using `OTHER2` fetches a file successfully, but appears to be garbage (Maybe it has a different decryption scheme? Maybe I just have no idea what is the file format?) - Every other format panics with AudioKeyError. Question 2, Has there been any investigation on the decryption of those files? (I'm mainly interested in AAC or FLAC

kerem

2026-02-27 19:28:53 +03:00

closed this issue
added the
wontfix
label

kerem commented

2026-02-27 19:28:54 +03:00

Author

Owner

@kingosticks commented on GitHub (Feb 14, 2018):

Part 1 would be a blatant violation of Spotify's end user agreement and cannot be endorsed or supported. This sort of functionality makes the project a target for being shut down. There is no place for this in librespot. This issue should be closed to make that clear. If there is still merit in question 2 (maybe some tracks do not provide ogg data?) it should be in new separate issue.

@kingosticks commented on GitHub (Feb 14, 2018): Part 1 would be a blatant violation of Spotify's end user agreement and cannot be endorsed or supported. This sort of functionality makes the project a target for being shut down. There is no place for this in librespot. This issue should be closed to make that clear. If there is still merit in question 2 (maybe some tracks do not provide ogg data?) it should be in new separate issue.

kerem commented

2026-02-27 19:28:54 +03:00

Author

Owner

@sashahilton00 commented on GitHub (Feb 14, 2018):

Hi,

This is unfortunately outside the scope of this project, as offline playback is something that Spotify has only supported in their clients. Since libspotify did not include this functionality, and a number of projects that used libspotify in this way, essentially as an audio ripper, we will not be adding such functionality as it could put the future of the project at risk. Librespot is heavily focused on being a connect receiver anyway, which requires a connection to the internet at all times. Whilst here are a couple of bugs, such as not handling reconnection at the time of writing, if you need to listen to music, it should be whilst librespot is online, and providing the audio in realtime.

@sashahilton00 commented on GitHub (Feb 14, 2018): Hi, This is unfortunately outside the scope of this project, as offline playback is something that Spotify has only supported in their clients. Since libspotify did not include this functionality, and a number of projects that used libspotify in this way, essentially as an audio ripper, we will not be adding such functionality as it could put the future of the project at risk. Librespot is heavily focused on being a connect receiver anyway, which requires a connection to the internet at all times. Whilst here are a couple of bugs, such as not handling reconnection at the time of writing, if you need to listen to music, it should be whilst librespot is online, and providing the audio in realtime.

kerem commented

2026-02-27 19:28:54 +03:00

Author

Owner

@paulo-raca commented on GitHub (Feb 14, 2018):

Got it, thanks!

@paulo-raca commented on GitHub (Feb 14, 2018): Got it, thanks!

kerem commented

2026-02-27 19:28:54 +03:00

Author

Owner

@plietar commented on GitHub (Feb 14, 2018):

While having a save audio file feature is not something we want to expose directly, I'm fine with supporting offline playback as long as it goes through the existing Player/Sink architecture. This won't make ripping any easier than current librespot.

@paulo-raca what's your use case for offline playback? Would my proposal be enough for you?

This would require both #134 and #22 to be implemented. We don't have any cache eviction at the moment (#34), but if we do we'll want to have a way of pinning certain tracks.

Librespot is heavily focused on being a connect receiver anyway.

This may have been true initially, but with libspotify finally going away there are new potential use cases for librespot outside of connect.

@plietar commented on GitHub (Feb 14, 2018): While having a save audio file feature is not something we want to expose directly, I'm fine with supporting offline playback as long as it goes through the existing Player/Sink architecture. This won't make ripping any easier than current librespot. @paulo-raca what's your use case for offline playback? Would my proposal be enough for you? This would require both #134 and #22 to be implemented. We don't have any cache eviction at the moment (#34), but if we do we'll want to have a way of pinning certain tracks. > Librespot is heavily focused on being a connect receiver anyway. This may have been true initially, but with libspotify finally going away there are new potential use cases for librespot outside of connect.

kerem commented

2026-02-27 19:28:54 +03:00

Author

Owner

@paulo-raca commented on GitHub (Feb 14, 2018):

I have a bluetooth speaker that I take everywhere and I currently use it tethered to my phone.
But there are a few (minor) issues on this setup:

Consumes phone battery
Music stops if I walk away
Random sounds other than music comes out of the big speaker if I use the phone, etc...

A small device with librespot could do it all, except I would like it to continue working without internet connection.

My initial plan was to attach a tiny linux computer (fruit-pi) that would sync up a playlist when the internet is available and just play the cached songs forever over the speaker -- As you can see, I managed to do that, but your suggestion for built-in support on librespot would be even better.

@paulo-raca commented on GitHub (Feb 14, 2018): I have a bluetooth speaker that I take everywhere and I currently use it tethered to my phone. But there are a few (minor) issues on this setup: - Consumes phone battery - Music stops if I walk away - Random sounds other than music comes out of the big speaker if I use the phone, etc... A small device with librespot could do it all, except I would like it to continue working without internet connection. My initial plan was to attach a tiny linux computer (fruit-pi) that would sync up a playlist when the internet is available and just play the cached songs forever over the speaker -- As you can see, I managed to do that, but your suggestion for built-in support on librespot would be even better.

kerem commented

2026-02-27 19:28:54 +03:00

Author

Owner

@Zocker1999NET commented on GitHub (Mar 1, 2020):

I do not know if it is possible to follow my propose but what do you think about a solution similar to the official implementation of the Linux client: Store the music files still encrypted but also store the keys "semi-encrypted" and remove the keys after a certain time not having refreshed them OR only store the music so the library only requires internet for getting the keys. This can be just as helpful as the official client, at least in countries with expensive cellular connections (like Germany 🎉) or bad connections, and should be conform to the end user agreements (if reverse-engineering the API was permitted by national laws you have to obey).

@Zocker1999NET commented on GitHub (Mar 1, 2020): I do not know if it is possible to follow my propose but what do you think about a solution similar to the official implementation of the Linux client: Store the music files still encrypted but also store the keys "semi-encrypted" and remove the keys after a certain time not having refreshed them OR only store the music so the library only requires internet for getting the keys. This can be just as helpful as the official client, at least in countries with expensive cellular connections (like Germany :tada:) or bad connections, and should be conform to the end user agreements (if reverse-engineering the API was permitted by national laws you have to obey).

kerem commented

2026-02-27 19:28:54 +03:00

Author

Owner

@aniketfuryrocks commented on GitHub (Sep 16, 2021):

can we implement a proxy cache ?

@aniketfuryrocks commented on GitHub (Sep 16, 2021): can we implement a proxy cache ?

kerem commented

2026-02-27 19:28:54 +03:00

Author

Owner

@roderickvd commented on GitHub (Sep 16, 2021):

What do you want it to do, other than the proxy support and caching support that is already in?

As for saving files locally, please refer to https://github.com/librespot-org/librespot/issues/152#issuecomment-365600191: that's not something we want to support because we don't want to violate the Spotify T&C's.

@roderickvd commented on GitHub (Sep 16, 2021): What do you want it to do, other than the proxy support and caching support that is already in? As for saving files locally, please refer to https://github.com/librespot-org/librespot/issues/152#issuecomment-365600191: that's not something we want to support because we don't want to violate the Spotify T&C's.

kerem referenced this issue

2026-02-27 19:59:56 +03:00

[PR #111] [CLOSED] Rustify recent changes according to @plietar #782

kerem referenced this issue

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

[PR #139] [MERGED] Rustify some recent changes according to plietar #804

kerem referenced this issue

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

[PR #144] [MERGED] Awiouy core api #805

Rows
Columns

[GH-ISSUE #152] Support saving audio files #111