librespot-org
Support for AAC_320 containers
Is your feature request related to a problem? Please describe. As far as I know, Librespot doesn't support MP4-AAC/AAC_320 correctly, which spotify (rarely) uses when streaming some tracks, I've noticed it on: https://open.spotify.com/track/67hXs9oizk6evBJxuk42cb Issue is, this specific track doesn't seem to have any working OGG/MP3/FLAC formats, so Librespot simply can't play it. By "Working" format I consider a format that has a key, that can be retrieved by librespot, and which librespot successfully decrypts the stream with. I can get these formats: AAC_320, AAC_24 ,OGG_VORBIS_160, but the last two fail to even play, and in hex editor, I see encrypted gibberish, nothing similar to an audio container header.
If I'd simply add AAC_320, and other ones to available formats, and try to request it's key, it'll fail with:
2025-09-21T09:38:01.745519Z ERROR librespot_core::audio_key: error audio key 0 1
But will give me a file which plays, has correct headers, which looks unencrypted, but has a small issue. Anything after first 10 seconds are encrypted AAC atoms. Which can't be decrypted, due to Librespot failing to retrieve the key.
Describe the solution you'd like I would like if Librespot properly decrypted partially encrypted MP4-AAC streams, and supported them.
We don't support use cases which break Spotify's terms of service, such as downloading and storing unencrypted audio data. We have no interest in this idea or your project that's focused on this. We also do not require links to copies of Spotify's data that you have stored.
Please either edit your post to contain just things we can support and remove the parts we don't, or it'll be removed entirely.
Alright, thanks for nothing, I'll close this issue when I get home.
On Sun, 21 Sept 2025, 13:48 Nick Steel, @.***> wrote:
kingosticks left a comment (librespot-org/librespot#1590) https://github.com/librespot-org/librespot/issues/1590#issuecomment-3315913774
We don't support use cases which break Spotify to terms of service, such as downloading and storing unencrypted audio data. We have no interest in this idea or your project. Please either edit your post to request something we do support, or it'll be removed.
— Reply to this email directly, view it on GitHub https://github.com/librespot-org/librespot/issues/1590#issuecomment-3315913774, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJWMY2RGGN5SMLBC4XXNEM33TZ7A5AVCNFSM6AAAAACHCTBUW6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTGMJVHEYTGNZXGQ . You are receiving this because you authored the thread.Message ID: @.***>
AAC files are encrypted with widevine and have nothing to do with librespot. And what about the lack of playable ogg files - interesting, I'll check it out later.
I've edited your post, no need to close it unless you want to. I think I've left sufficient context but feel free to improve it if necessary. The underlying ogg issue is fine and something we should try to fix or at least better document. Just keep the discussion on topic, please.
Is AAC_24 widevine? The android client (no widevine) supports 24kbps "Low" quality, isn't it that?
Is AAC_24 widevine? The android client (no widevine) supports 24kbps "Low" quality, isn't it that?
It may be, although I'm unclear how it's able to only retrieve the key for the first 10 seconds..
@MrCheatEugene can you confirm whether adding only AAC_24 to supported formats still results in audio key error?