個人向け音楽サーバーを作ってみた

普段から音楽を聴く時間が多く、手元にある音源をもっと自由に管理できる環境がほしいと感じていました。
配信サービスはとても便利ですが、自分で所有している音源を中心に聴きたい場面もあります。
昔から持っている音源、配信されていない音源、自分で整理しておきたい楽曲。そういったものを、端末やアプリに縛られず扱える場所を作りたいと思いました。
そこで制作したのが、音楽ファイルをアップロードし、ブラウザ上で管理・検索・再生できる個人向け音楽サーバーです。
今回の制作では、単に音楽を再生できるプレイヤーを作るのではなく、自分の音楽ライブラリを育てていけるような体験を目指しました。
なぜ音楽サーバーを作ろうと思ったのか
音楽を聴く環境は、今ではかなり便利になっています。
検索すればすぐに曲が見つかり、スマートフォンでもPCでも同じように再生できます。
ただ、その便利さの一方で、自分が持っている音源を自分の感覚で整理する機会は少なくなっているようにも感じていました。
曲をどのフォルダに置くのか、どのアルバムとして見たいのか、アーティストごとにどう並べたいのか。
そういった整理の仕方には、少しだけその人の聴き方や思い入れが出ると思っています。
既存サービスに任せるだけではなく、自分の手元にある音源を、自分のルールで管理できる場所を作りたい。
その気持ちが、この音楽サーバーを作る出発点になりました。
単なる音楽プレイヤーでは終わらせたくなかった

最初に思い浮かぶ機能は、もちろん音楽を再生することです。
ですが、再生ボタンがあり、シークバーがあり、音量を調整できるだけでは、自分が作りたいものには少し届かないと感じていました。
大切にしたかったのは、音楽ファイルをアップロードしたあとに、その曲がライブラリの中へ自然に収まっていく感覚です。
ファイルを追加すると、曲名、アルバム、アーティストなどの情報が読み取られ、一覧の中に並んでいく。
必要なときには検索でき、アルバム単位でも、アーティスト単位でも、フォルダ単位でも辿れる。
そうすることで、ただ再生するための画面ではなく、手元の音楽を見渡せる場所になると考えました。
▶ 操作デモを見る音楽ライブラリを管理するという体験
今回の制作で特に意識したのは、音楽ファイルと楽曲情報を分けて扱うことです。
音源そのものはサーバー上のstorageフォルダに保存し、曲名やアルバム名、アーティスト名などのメタデータはデータベースで管理する構成にしました。
この分け方にすることで、ファイルを保管する場所と、画面上で検索・分類するための情報を整理しやすくなります。
また、アップロード時にメタデータを解析し、必要に応じてアルバムやアーティストの情報を自動的に作成するようにしました。
一曲ずつ手作業で分類するのではなく、音楽ファイルが持っている情報をできるだけ活かしながら、ライブラリとして積み上がっていく形を目指しています。
音楽を聴く体験は、再生画面だけで完結するものではありません。
探す、眺める、整理する、思い出す。そういった行動も含めて、音楽ライブラリを持つ楽しさだと考えています。
実装した機能
基本機能として、音楽ファイルのアップロード、曲一覧表示、アルバム一覧、アーティスト一覧、フォルダ一覧を実装しました。
アップロードされた楽曲はサーバー上に保存され、解析したメタデータをもとにデータベースへ登録されます。
検索機能では、目的の曲へすぐに辿り着けるようにし、曲数が増えても使いやすさが大きく落ちない構成を意識しました。
再生機能では、ブラウザ上で楽曲を再生できるようにし、再生・停止、シークバー操作、音量調整など、音楽プレイヤーとして必要な操作を揃えています。
自宅PCだけで完結するのではなく、他の端末からもアクセスできる構成を目指した点も、この制作で意識した部分です。
ローカルに閉じた音楽管理ではなく、Webアプリケーションとして扱うことで、端末を変えても同じライブラリへアクセスできる形に近づけました。
制作中に苦労したこと
特に難しかったのは、音楽ファイルをただ保存するだけではなく、ライブラリとして扱える状態にすることでした。
アップロード処理では、ファイルを受け取り、保存先を決め、データベースへ登録する必要があります。
さらに、music-metadataを使って楽曲情報を読み取り、その情報からアルバムやアーティストを紐づける処理も必要でした。
メタデータは必ず綺麗に入っているとは限らないため、情報が足りない場合にどう扱うかも考える必要がありました。
再生状態の管理も苦労した点の一つです。
再生中の曲、現在位置、音量、シークバーの状態など、画面上の操作とaudio要素の状態を合わせて扱う必要がありました。
また、検索機能や一覧表示も、曲、アルバム、アーティスト、フォルダという複数の見方があるため、データベース設計の段階から整理して考える必要がありました。
技術スタックと構成
バックエンドにはNode.jsとExpressを使用し、データベース操作にはSequelize、保存先にはSQLiteを採用しました。
フロントエンドはEJS、HTML、CSS、JavaScriptで構成し、サーバーサイドで生成した画面をブラウザから操作する形にしています。
ファイルアップロードにはMulter、音楽ファイルのメタデータ解析にはmusic-metadataを使用しました。
プロジェクト構成としては、src/models、src/routes、src/views、src/public、src/services/importer.jsのように役割を分けています。
特にimporter.jsでは、音楽ファイルを取り込み、メタデータを読み取り、データベースへ反映する処理を担当させました。
派手な技術を詰め込むよりも、音源、メタデータ、画面表示、再生操作の責務を分けて、管理しやすい構成にすることを優先しました。
作ってみて感じたこと
この制作を通して、音楽プレイヤーを作ることと、音楽ライブラリを作ることは似ているようで違うのだと感じました。
プレイヤーは今聴いている一曲に集中しますが、ライブラリはこれまで集めてきた音源全体をどう扱うかまで考える必要があります。
曲を保存する場所、分類の仕方、検索のしやすさ、再生までの導線。その一つひとつが、音楽を聴く前後の体験に影響します。
また、ファイルとデータベースを結びつける設計や、メタデータが不完全な場合の扱いなど、実際に管理アプリケーションを作るうえで避けて通れない課題にも触れることができました。
今後は、プレイリスト機能や再生履歴、ジャケット画像の扱い、複数端末での使いやすさなども改善していきたいと考えています。
自分の音源を自分で管理するための小さなサーバーですが、作ってみたことで、Webアプリケーションが個人の生活に近い道具にもなれることを実感しました。
技術スタック
Backend
- Node.js
- Express
- Sequelize
- SQLite
Frontend
- EJS
- HTML
- CSS
- JavaScript
Music Processing
- Multer
- music-metadata
Development
- nodemon
- npm scripts
Data Storage
- SQLite
- storage/
Structure
- src/models
- src/routes
- src/views
- src/public
- src/services/importer.js