SpotifyとYouTube Musicを端末へ映すStash
Spotify + YouTube Music ライブラリと毎日のミックス。ロスレス FLAC でストリーミングまたはダウンロードします。永久に無料でオープンソース。
ひと目でわかる
- これは何?
- オンライン索引とFLAC保存を切り替えるAndroid音楽アプリの同期、認証Cookie、再生機能、容量条件を読む。
- 誰に向いている?
- 二つの音楽サービスのライブラリをAndroidで一つに扱い、通信なしの再生を優先する人にはOffline modeが候補になります。採用前に利用規約とアカウント影響を確認し、同期する曲数、9から15GB程度の空き容量、Cookieの失効、誤マッチの再検索を実端末で確かめてください。
- 商用利用できる?
- 条件付きでできます。GPL-3.0 はコピーレフトのライセンスで、これを含むソフトウェアを配布する場合、そのソフトウェアのソースコードを同じライセンスで公開する必要があります。配布せず社内で使うだけなら、この義務は生じません。
- 今もメンテナンスされている?
- されています。最後のコミットは 5 日前です。
- 何の言語で書かれている?
- 主に Kotlin です(GitHub の言語統計による)。
回答はプロジェクトの GitHub データ(最終同期:2026年9月14日)と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
一つのライブラリを二つの保存方式へ
StashはSpotifyとYouTube MusicのライブラリをAndroid端末へミラーします。接続後にプレイリストやmixを選び、Offline modeでは各トラックをFLAC、または利用できる範囲で最も近いlossless sourceとして端末へ保存します。Online modeでは保存量を抑えたstreamable local indexを作り、再生時に接続を必要とします。二つのモードは見た目の切替だけでなく、Syncが実行する処理と必要な容量を変えるため、ライブラリの規模と移動中の通信条件から選ぶ必要があります。
マッチングとライブラリ同期
READMEはSpotifyとYouTube Musicのliked songs、playlist、daily mixなどを統合し、曲のマッチングを自称99%と説明しています。この数値はREADME上の自報であり、すべての地域、版、音源での検証結果を意味しません。Now Playingから誤マッチを一度の操作で報告し、再検索をキューに入れられます。Likes and History mirroringを有効にすると、Stash内でのlikeや再生を元サービスへ反映します。同期前に対象プレイリストを限定し、元アカウントへ書き戻される操作を確認してください。
FLACを生む外部の背骨
FLAC取得にはQBDLXとarcodが関係するとREADMEに記載されています。Stashが単独で音源を作るのではなく、これらの外部プロジェクトを使ってlossless fileを得る構成です。音源の可用性、品質、サービス側の変更はStashの画面だけでは判断できません。保存したファイルのcodec、sample rate、容量を数曲で確認し、著作権と各サービスの利用条件を利用地域で確認する必要があります。READMEの「lossless source available」という表現も、すべての曲が同じ形式になる保証として扱わないことが重要です。
再生機能と端末内プライバシー
再生側には5-band equalizer、preset、bass boost、virtualizer、crossfader、normalizer、LRCLIBから取得してスクロールする同期歌詞があります。Stashサーバー、Stashアカウント、analytics、第三者crash reporterは使わず、認証Cookieは端末内にAES-256-GCMで暗号化保存するとREADMEは説明しています。ネットワーク要求はSpotifyとYouTubeへ直接行うとされていますが、Cookieを扱う以上、端末のバックアップやrootアクセスも脅威モデルに含めるべきです。ログアウトでWebセッションを失効できるという説明も含め、実際の保存場所と削除動作を確認してください。
導入と容量を先に試す
直接APK、ObtainiumによるGitHub Releases追跡、ソースビルドの三つの導入経路があります。ソースからはAndroid Studio Hedgehog以降、JDK 17、Android SDK 35が必要で、Android 8.0、API 26以降が要件です。Offlineの中規模ライブラリには約9から15GBの空き容量が目安として示され、Onlineはほぼ容量を使いません。テストでは通常のブラウザからCookieを取得し、最小のプレイリストを同期して、再ログイン、曲の再生、誤マッチ、削除、モード変更を順に確認してから全ライブラリへ広げてください。
同期を小さく始めて復旧を試す
Stashの初回テストではSpotifyまたはYouTube Musicの片方だけを接続し、数曲のプレイリストをOnlineで索引化してからOfflineへ切り替えます。保存したFLACの再生、歌詞の取得、equalizer、crossfader、normalizerを順に試し、曲が存在しない場合と誤マッチの場合を別に記録します。Likes and History mirroringは最初は無効にし、元サービスへ書き戻す操作を理解してから有効にします。AES-256-GCMで保存されるCookieがログアウト後に消えるか、端末のバックアップに含まれないかを確認します。Android 8.0の端末と新しいSDKで作ったdebug APKの両方を試し、9から15GBという容量目安が自分のライブラリでどう増えるかを測ります。Releases APKと自作版を混ぜず、更新前に再生と設定復元を確認してください。
認証失効と保存容量を実際に確認する
Stashの接続テストは通常のブラウザから取得したSpotifyのsp_dc、またはYouTube Musicのcookie headerを最小範囲で使います。同期が始まる前後で端末内のCookieがAES-256-GCMで保存され、ログアウトやサービス側の失効後に再認証を要求するかを確認します。Onlineのlocal indexとOfflineのFLACを同じ数曲で比較し、再生に必要な通信、ファイル容量、LRCLIB歌詞の有無を記録します。誤マッチをNow Playingから報告し、再検索結果を元ライブラリへ書き戻さないことも試します。Android 8.0以上、JDK 17、SDK 35でdebug APKを作り、9から15GBの目安をライブラリの曲数と実測容量に結び付けます。
CookieとFLACを少量で試す
SpotifyまたはYouTube Musicの片方を接続し、数曲をOnline索引とOffline FLACで同期します。CookieのAES-256-GCM保存、ログアウト後の失効、誤マッチの再検索、Likes書き戻しを別々に確認します。Android 8.0以上で容量を測り、9から15GBの目安と実ライブラリの曲数を対応させます。 Stashは公式APIではなく既存ログインCookieを使うと説明されています。Cookieの取り扱いとサービス側の仕様変更は、FLACの音質確認とは別のリスクとして記録し、同期対象を増やす前にアカウントのlikesとhistoryへの反映を確認します。 Offlineでは実際の空き容量を同期前後で測り、Onlineでは機内モード時に再生が止まることを確認します。Cookieをissueやログへ出さない運用も定めます。
編集部の結論
二つの音楽サービスのライブラリをAndroidで一つに扱い、通信なしの再生を優先する人にはOffline modeが候補になります。採用前に利用規約とアカウント影響を確認し、同期する曲数、9から15GB程度の空き容量、Cookieの失効、誤マッチの再検索を実端末で確かめてください。
コミュニティノート