srf
読み方はsurfと同じ
DJ向けの音源管理データベース用の拡張子
波（wave）に乗るという意味でsurf
やりたいこと
音源ファイルとは別のファイルにメタデータを持つようにする
surfファイルがmp3やwavの差分を吸収し、使う側はそれを意識しなくてよいようにする
USBへのエクスポート時などに必要ならwavをmp3に変換してもよいが、そのときに共通のメタデータを使う
楽曲のアーティストを配列で持ちたい
楽曲ライブラリのディレクトリ構造をいい感じにしたい
/Artist/Album/Track ???
=> アーティスト名が同じときに破綻してしまう〜
アイデア
foo.srfという名前のディレクトリを作る
これを"srfファイル"だと思って取り扱う
ディレクトリの中にsrf_meta.jsonというsrf用にmetaファイルを配置する
ディレクトリの中に音源を入れて、それに関するメタ情報をsrf_meta.jsonに書く
例
code:a
foo.srf/
|-foo.wav
|-srf_meta.json
メタデータの中身
code:json
{
"name": "foo",
"artists": "hoge",
....
"path": "foo.wav",
}
srfファイルに複数の楽曲を入れられるようにする？
アルバムを一つのsrfファイルにできる
複数のアルバムを一つのsrfにもできる
"path": "My Album/foo.wav" みたいに相対パスで持つと良さそう
複数のsrfファイルをマージすることができる
Foo/Album1.srfとFoo/Album2.srfをFoo.srfにマージできる
=> 何が嬉しいのか？
srf全体のdb自体をsrfにできる
検索は遅そうなのでアプリで使用する上では別途速度のことを考える必要がある
プロトタイプ
SwiftUIでアプリを作る
1. mp3のタグを読めるようにする
2. wavのタグを読めるようにする（あとでよい）
3. フォルダを指定するとそのフォルダに含まれるmp3およびwavからsrfファイルを作る
ひとまずsandbox appにしてアプリのhome（/User/{name}/Library/Containers/Board/Data/ にBoardLibraryディレクトリを作る
BoardLibraryにsrfファイルをどんどん作る
ディレクトリ構造は一旦気にしない
DANGER: 同じ曲名があったときに困りそう！
4. ライブラリに追加したsrfファイルをGUIに表示する
5. ライブラリ内のディレクトリ構造をsrfのメタデータから決定させる
ディレクトリ構造を更新するボタンを作れば良い
6. GUIからsrfを編集できるようにする
元データに変更を加えずにメタファイルのみが更新される、ということはここで実現できる
変更 => ディレクトリツリーに反映 で体験をみたい
7. 音源を再生できるようにする
問い
楽曲自体のデータとユーザーが追加したデータ（e.g. コメント、キュー、マイタグなど）をどう持つべきか？
カスタムフィールドなどを追加できるようにするか？
glTFのextensionやextraのようなもの
音楽再生機能
トラックリストやプレイリストで選択した楽曲を再生できる
Player
Srf?を持つ
Srfが渡されるとプレイヤーを初期化する
シークバー、再生時刻、長さが表示される
再生ボタン、停止ボタン、最初に戻るボタン、次の曲ボタン
音量スライダー
https://scrapbox.io/files/68073ac42d8bf6bd50f513f6.png
https://scrapbox.io/files/68073aeb161b788ca1ee04c9.png
album metadataとtrack metadataの関係
album metadataの中にtrack metadataを配列で保持できるとおしゃれである
一方で曲単位で取り扱いたいケースはある
曲単位で取り扱うときにalbum nameは必要？
ユースケースを考える
プレイリスト
複数のtrackの配列のようなもの
各trackからその楽曲が含まれるalbumにジャンプしたい
USBにexportされたtrackに対してalbum nameを見たいか？
=> 割とみたい気がしてる
album idしか入ってない場合、album nameを取得する術がない
idとnameを別に保持するべきな気がする
=> 2重管理になるけどそういうものだと思う
rekordbox/CDJはどうなってるか？
Artist/Album/Track という構成になってそう
アルバムアーティストではなく
trackはalbum idを持つ
albumは以下をもつ
id
artist: string
音源に格納された"アルバムアーティスト"との対応のために保持するがアプリとしては使わない
artists: string[]
name
ディレクトリ構造
/root/{album name}_{album id}/
artistsが配列なので/artist/album という形にはしない
やること
mp3ロード時
mp3のアルバムアーティストのタグを読む
アルバムアーティストとアルバム名から対応するアルバムがないか探す
アルバムがある場合はそれのidをsrfのalbumIdに格納する
アルバムがない場合は新しく作る
つまり？
既存のmp3のアルバムアーティストはアルバムidを決定するためのヒントとして使う
=> なければアーティスト名 x アルバム名で探す
=> 間違ったアルバムに入る可能性があるが許容する
=> あとでアルバムをマージする機能を作る
問
全ての楽曲はアルバムに所属するか？
=> noとしてよい
アルバムに入ってない曲をまとめたリストがあればよい
楽曲のmetaデータ変更処理
楽曲一覧画面からやる場合
srfのmetadataのjsonを表示する
jsonがSrfMetadataとして保存できるか確認する
整合したら保存する
ここでパスが変わることはある？
ない（パスはアルバムによって決まるがsrfのmetadataにアルバムの情報は含まれない）
保存した情報をどうやって更新するか
srf一覧は更新する必要があるか
ない
編集したsrfだけが更新されればよい
楽曲リストの再描画が実行されるのは許容する
編集した楽曲
リストは新しくなる
リストの順番も変わりえる
が選択中楽曲にフォーカスは揃って欲しい
つまり？
編集の前後で同じ楽曲を選択しておいて欲しい