데이터 모델

bae의 카탈로그는 일반 SQLite이며, coven에 table별로 선언됩니다. 동기화되는 table은 conflict clock을 가지고 모든 기기로 이동합니다. 선언되지 않은 table은 기기를 떠나지 않습니다. 이 분리는 데이터 모델에서 가장 load-bearing한 결정이므로, 이 페이지는 그 기준으로 구성되어 있습니다.

카탈로그 그래프

schema에서 동기화되는 중심부는 다음과 같습니다.

artists, albums, works: 묶음 계층입니다. 앨범은 릴리스를 모으고 primary 릴리스를 가리킵니다. 작품은 클래식 구조를 위한 부모/자식 그래프를 이룹니다.
releases: 중심 entity이며 프레싱 하나당 한 row입니다. 프레싱 사실(레이블, 카탈로그 번호, barcode, 국가, 형식, 연도), 메타데이터 소스, 가져온 폴더의 content hash, 측정한 앨범 loudness를 담습니다.
release_identities: 소스별로 릴리스가 무엇인지를 나타냅니다. row가 없으면 알 수 없음입니다. release ID가 있는 MusicBrainz 또는 Discogs row는 정확한 일치를 뜻하고, 없으면 근사입니다. 릴리스는 두 소스의 identity를 동시에 가질 수 있습니다.
**tracks**와 track_artists, 그리고 **release_artist_roles**와 track_artist_roles: 트랙 목록과 크레딧입니다. 각 크레딧에는 소스가 붙습니다.
track_works, work_parts, work_artists: 녹음을 그들이 연주하는 작품에 연결합니다.
**audio_formats**와 audio_format_segments: 재생 spec입니다. 트랙별 codec, sample rate, bit depth, channels, 측정 loudness와 peak, pregap length가 있습니다. Segment는 트랙을 소스 파일의 정렬된 byte 및 sample window에 매핑합니다. 그래서 CUE 리핑의 트랙이 pregap을 포함해 하나의 큰 파일 여러 영역이나 여러 파일에 걸칠 수 있습니다.
release_files, covers, artist_images: blob을 가진 table입니다. row는 카탈로그 항목이고, 바이트는 coven의 blob 계층에 있습니다(아래 참고).

동기화, 조건, 로컬

위 항목은 모두 동기화되지만 무조건은 아닙니다. releases는 remote column을 기준으로 gated root로 선언됩니다. release row와 그 전체 subtree(tracks, files, credits, formats, cover)는 remote가 true일 때, 즉 릴리스가 cloud-managed일 때만 동기화됩니다. 릴리스를 managed로 바꾸면 subtree가 게시됩니다. 관리되지 않는 릴리스는 schema가 동기화 대상이어도 가져온 기기에만 온전히 남습니다. ancestor table(artists, albums, works)은 어떤 synced release가 아직 참조하는 동안만 동기화되므로, 기기는 아래에 아무것도 없는 artist를 받지 않습니다.

완전히 local인 table은 coven에 선언되지 않습니다.

playback_state: 현재 트랙, 위치, 대기열, 볼륨, 셔플과 반복입니다. 재생은 기기의 사실입니다.
imports: 가져오기 작업 추적입니다.
release_metadata: MusicBrainz와 Discogs에서 받은 raw JSON 보관본입니다. 나중에 다시 해석하기 위해 보관합니다.

모든 synced table은 _updated_at hybrid-logical-clock column을 가집니다. coven이 동시 편집을 필드별로 병합할 때 이 register로 순서를 정합니다. 테스트는 synced set과 clock-carrying set이 정확히 같은지 확인합니다.

Blob

오디오와 이미지는 coven의 blob 계층을 통하며, 세 namespace는 각자 기기 캐시 예산을 가집니다. release_files(20 GiB), covers(512 MiB), artist_images(256 MiB)입니다.

릴리스 파일은 사용자가 제공하고 요청 시 캐시됩니다. 관리되지 않는 릴리스에서 blob은 사용자 파일의 원래 경로를 가리키는 외부 참조입니다. 관리되는 릴리스에서는 첫 읽기 때 캐시에 가져오는 업로드 객체입니다. 커버와 아티스트 이미지는 호스트가 제공하며 미리 캐시됩니다. bae가 바이트를 만들고(커버는 최대 너비 600px의 JPEG 썸네일로 다시 렌더링), 가져올 때 모든 기기가 가져와 그리드를 로컬에서 렌더링합니다.

불투명 홈에서는 blob이 의미 없는 content key 아래 업로드됩니다. 탐색 가능한 홈에서는 각 blob 행가 읽을 수 있는 클라우드 경로를 기록합니다. 오디오는 {artist}/{album}/{filename}, 커버는 {album}/{release}/cover.{ext}입니다. 업로드 때 한 번 계산하므로 나중에 이름을 바꿔도 객체는 이동하지 않습니다.

리핑본의 신원

releases.content_hash는 가져온 폴더의 파일 구조(상대 경로와 크기)에 대한 SHA-256이며, 폴더가 디스크 어디에 있는지와 무관합니다. 이것으로 bae는 이미 가져온 리핑본이 감시 폴더에 다시 나타났을 때 알아보고, 다시 가져오기에서 교체해야 할 릴리스를 찾아 중복을 피합니다.