streamrip: a scriptable lossless downloader for Qobuz, Tidal, Deezer and SoundCloud

The gap streamrip fills for Qobuz and Tidal subscribers

Streaming clients are built for playback, not for keeping files. They do not queue an entire discography, they do not convert to a chosen codec on the way out, and they do not remember what you already pulled. streamrip is aimed at the person who pays for Qobuz or Tidal, wants local copies at a specific quality tier, and is willing to drive a terminal to get them. The README is explicit that downloading is not the whole story: the tool also handles playlists, discographies and labels, and it can follow Spotify or Apple Music playlists indirectly through last.fm. That last point matters, because it means streamrip can be the download half of a workflow where another service is the discovery half. The audience is narrow on purpose. The README states that Tidal and Qobuz need a premium subscription, so the tool is not a way around a paywall; it is a way to move files out of a service you already pay for. If you only use Spotify or Apple Music, there is no direct source here, only the last.fm indirection.

How the download pipeline is put together

The dependency list in pyproject.toml tells most of the story. aiohttp and aiofiles handle the network and disk sides of concurrent downloads, aiolimiter provides rate limiting, and aiodns resolves names asynchronously. Quality selection is a single integer from 0 to 4, mapped in the README to bitrates and bit depths: 0 is 128 kbps, 1 is 320 kbps, 2 is CD-quality 16 bit / 44.1 kHz, 3 is 24 bit up to 96 kHz, and 4 is 24 bit up to 192 kHz. Only Qobuz offers level 4 in the table, and level 3 on Tidal is marked MQA. Conversion is handled by an external ffmpeg binary rather than a bundled encoder, which is why the install notes say ffmpeg is optional but limits functionality. Tagging uses mutagen, path handling uses pathvalidate, and encrypted stream handling pulls in pycryptodomex. The database that prevents repeat downloads is not described in the README beyond its purpose, so its schema and where it lives on disk are things you would have to inspect yourself. The repository layout is conventional for a Python CLI: a streamrip package, a tests directory, and a pyproject.toml at the root.

Installing streamrip and downloading a first album

The README asks for Python 3.10 or greater and pip, and notes that ffmpeg is optional but that skipping it limits some functionality. The primary install is a single pip command, and the README offers a dev-branch install as the fallback when the released version misbehaves.

pip3 install streamrip --upgrade

After that, typing rip with no arguments should print the main help page. If it does not, the README points to the wiki's detailed installation instructions rather than offering a troubleshooting section inline. Arch users are pointed at an AUR package, and Homebrew users at a brew formula; both are listed as alternatives to pip.

The first real download is a URL command against a service link. For a Qobuz album, the README gives this form:

rip url https://www.qobuz.com/us-en/album/rumours-fleetwood-mac/0603497941032

You can pass several album URLs in one invocation, and you can pin the quality tier with the --quality flag, which takes the same 0 to 4 values as the table above. To convert on the way out, pass --codec with a target format such as mp3. Interactive search is a separate subcommand with the service and media type as positional arguments, for example rip search tidal album 'fleetwood mac rumours'. If you want to change concurrency, rate limits or output paths, the config file is opened with rip config open, and the README treats that file as the place for anything beyond the flags.

Where streamrip gets in your way

The premium requirement is the first hard boundary. Without a Qobuz or Tidal subscription, the highest-value sources are unavailable, and the quality table shows that no other source reaches level 4. The README also warns that using quality 4 is generally a waste of space, on the grounds that sampling rates above 44.1 kHz are not perceptible, so the top tier exists mainly for processing or slowed-down audio. That is an unusual thing for a downloader to say about its own maximum setting, and it is worth taking at face value. The project is also strict about bug reports: the README states that issues not following the provided templates will be silently closed. That is a maintenance posture, not a technical limit, but it shapes how much help you can expect when something breaks. Interactive search depends on platform-specific terminal menu libraries, simple-term-menu on macOS and Linux and pick on Windows, with windows-curses added for Windows. That is a lot of surface area for a prompt, and the README does not describe what happens when the terminal does not support it. Finally, the README does not document rollback, partial-download recovery, or what the database does when a file is deleted after being recorded.

streamrip against OrpheusDL and qobuz-dl

The README acknowledges qobuz-dl and Tidal-Media-Downloader among the projects that inspired streamrip, and both appear in the related searches alongside OrpheusDL. The difference in approach is scope. qobuz-dl is named for a single service, so its code path is one API and one quality ladder; streamrip carries four sources plus a last.fm bridge, which is why its dependency list is longer and why quality selection has to be expressed as a shared 0 to 4 scale rather than per-service options. OrpheusDL takes a modular route, with per-service modules behind a common core, which is a different answer to the same multi-service problem: streamrip builds the sources into one CLI, while a modular design pushes service support out to separate components. Neither approach is free. A single CLI keeps the command surface uniform, as the README's examples show, but it means a change in one service's API can affect the shared config and quality mapping. If you only ever download from Qobuz, the single-service tools are the smaller dependency footprint.

Maintenance, licensing and what a fork implies

The repository is not archived, and the last push was on 2026-08-04, which is recent. The release history is uneven: v2.0.5 landed on 2024-01-25, v2.1.0 on 2025-03-10, and v2.2.0 on 2026-03-12. The gap between v2.1.0 and v2.2.0 is about a year, so pinning to a release means waiting through long quiet periods, while the dev branch is where the README says new features land first. That is the practical upgrade decision: released versions for stability, dev branch for currency, with the dev install command documented in the README. The licence is GPL-3.0-only, declared in pyproject.toml and shipped as the LICENSE file at the repository root. GPL-3.0 is a copyleft licence, so redistributing a modified streamrip, or shipping it inside a product, carries obligations that permissive licences do not. This is a summary of what the repository states, not legal advice; if you plan to redistribute, read the licence text and get your own counsel. The README's disclaimer adds that the author is not responsible for how you use the tool and that using it means agreeing to the Qobuz, Tidal and Deezer API terms.

Editorial conclusion

Adopt streamrip if you hold a Qobuz or Tidal premium subscription, are comfortable in a terminal, and want repeatable album or playlist downloads with a deduplicating database. Skip it if you want a graphical client, if you only use Spotify or Apple Music, or if you are not willing to read the wiki when the interactive prompts behave oddly. Before committing, run rip --help and rip config open on your own machine to confirm the CLI and config file behave as the README describes.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. nathom/streamrip on GitHub
4. README
5. Releases