what's changed
fixed
- non-latin tracks download again - cyrillic, greek, cjk, indic (closes #77's report). the youtube matcher normalized every non-latin title to an empty string, so even a character-identical upload was rejected and the track skipped as "not found". normalization now keeps letters, digits, and combining marks from any script (category-based per unicode's general categories - marks must survive or distinct indic words collapse into the same consonant skeleton), and a fully non-latin artist no longer arms the artist filter against romanized uploads. latin matching is byte-identical to before - proven with a 100,000-case fuzz against the old implementation - so the #52 never-grab-the-wrong-audio safeguard is untouched.
added
- filename order setting: "Artist - Song" (closes #77). a settings checkbox swaps the two filename components everywhere (playlists, single tracks, the duplicate-name guard) and composes with the track-number prefix. both parts still pass the same sanitizer documented against the windows naming rules and posix pathname rules, so the swap can't change what's safe to write on any of the three OSes.
- sample rate setting: auto, 44.1 kHz, or 48 kHz (closes #80). youtube audio is 48 kHz, so flac/wav rips had no way to come out at cd-standard 44.1 kHz; the new selector feeds ffmpeg's
-arthrough yt-dlp's postprocessor args. deliberately limited to the formats that always transcode (mp3/flac/wav): opus is 48 kHz-only by codec design and m4a can stream-copy its source (where ffmpeg silently ignores-ar), so both grey the selector out instead of sometimes-working. - the macos intel binary is back:
Sunnify-macOS-Intel.zip(closes #79). intel builds were dropped in 01c241e on the mistaken premise that rosetta covers intel macs - rosetta 2 only translates x86_64 to apple silicon, never the reverse, so intel users on macos 15 (the last macos for intel hardware) hit "not supported on this type of Mac" while the readme still claimed intel support. builds now run natively on github'smacos-15-intelrunner against qt 6.11's supported x86_64 target, with the same hash-locked deps, sha-pinned ffmpeg, and slsa l3 provenance as every other binary.brew install --cask sunnifynow picks your architecture automatically. intel builds ride github's final x86_64 image (supported into august 2027), which carries intel macs through the rest of their supported life - right alongside apple's own timeline. - every macos build now has to boot before it ships. the pipeline launches the freshly built app headless on its build runner and fails the release if it dies within 10 seconds - the gate that would have caught arm64-only builds reaching intel users.
- signal deaths now leave a forensic log line. a default-action SIGINT/SIGTERM skips every exit hook, which made historical "the app just died, nothing in the log" reports untraceable; the app now logs
terminated by signal <NAME>, flushes, and re-raises with identical kill behavior.
verifying this release
sha256sum -c checksums.txt --ignore-missing
gh attestation verify Sunnify-Linux --repo sunnypatell/sunnify-spotify-downloaderinstall via homebrew (macos)
brew tap sunnypatell/sunnify https://github.com/sunnypatell/sunnify-spotify-downloader
brew install --cask sunnifyfull changelog: v2.1.0...v2.1.1
⭐ if sunnify saved you time, star the repo - stars are how people find it.
attestations from this build
direct links to each attestation generated by the workflow run that produced these binaries (sigstore-signed, public-good rekor log entry, SLSA build L3 via the release-build.yml reusable workflow):
- build provenance: Sunnify-Windows.exe
- build provenance: Sunnify-Linux
- build provenance: Sunnify-macOS.zip
- build provenance: Sunnify-macOS-Intel.zip
- sbom attestation for the binaries
- build provenance for the source tarball
the *.sigstore.json assets attached above are the same attestations as offline-verifiable bundles. these get auto-refreshed on every release re-build, so the links above always correspond to the binaries currently attached to this release.