mirror of
https://github.com/librespot-org/librespot.git
synced 2026-04-27 00:05:55 +03:00
[GH-ISSUE #1590] Support for AAC_320 containers #726
Labels
No labels
A-Alsa
SpotifyAPI
Tokio 1.0
audio
bug
can't reproduce
compilation
dependencies
duplicate
enhancement
good first issue
help wanted
high priority
imported
imported
invalid
new api
pull-request
question
reverse engineering
wiki
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/librespot#726
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @MrCheatEugene on GitHub (Sep 21, 2025).
Original GitHub issue: https://github.com/librespot-org/librespot/issues/1590
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 1But 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.
@kingosticks commented on GitHub (Sep 21, 2025):
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.
@MrCheatEugene commented on GitHub (Sep 21, 2025):
Alright, thanks for nothing, I'll close this issue when I get home.
On Sun, 21 Sept 2025, 13:48 Nick Steel, @.***> wrote:
@SuisChan commented on GitHub (Sep 21, 2025):
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.
@kingosticks commented on GitHub (Sep 21, 2025):
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.
@MrCheatEugene commented on GitHub (Sep 21, 2025):
Alright, thanks!
@drobotk commented on GitHub (Nov 14, 2025):
Is AAC_24 widevine? The android client (no widevine) supports 24kbps "Low" quality, isn't it that?
@MrCheatEugene commented on GitHub (Nov 14, 2025):
It may be, although I'm unclear how it's able to only retrieve the key for the first 10 seconds..
@drobotk commented on GitHub (Nov 17, 2025):
@MrCheatEugene can you confirm whether adding only
AAC_24to supported formats still results in audio key error?@MrCheatEugene commented on GitHub (Nov 18, 2025):
I'll test it today, but I remember errors being mainly from AAC_320, not _24
@drobotk commented on GitHub (Nov 18, 2025):
Context: I can successfully decrypt AAC_24 with REDACTED but I don't have spotify premium so can't test if you can get the key via spirc. If yes, then solving this issue becomes implementing support for Spotify's SpAC container, which is what AAC_24 is.
@kingosticks commented on GitHub (Nov 18, 2025):
Do they store the first bit of the track unencrypted, similar to how they provide separate unencrypted short track segments for ogg files? I understand this is related to reducing playback latency when skipping to random (i.e. non-preloaded) tracks.