Modelo de dados

O catálogo de bae é SQLite comum, declarado para coven tabela por tabela: tabelas sincronizadas carregam um relógio de conflito e viajam para todo dispositivo; tabelas não declaradas nunca saem do dispositivo. A divisão é a decisão mais determinante do modelo de dados, então esta página se organiza em torno dela.

O grafo do catálogo

O coração sincronizado do esquema:

artists, albums, works: a camada de agrupamento. Um álbum agrega seus lançamentos e aponta para um primário; obras formam um grafo pai/filho para estrutura clássica.
releases: a entidade central, uma linha por prensagem. carrega os fatos de prensagem (etiqueta, número de catálogo, código de barras, país, formato, ano), proveniência de metadados opcionais, um hash de conteúdo da pasta importada e loudness do álbum medido. sem proveniência significa que os metadados foram inseridos diretamente; proveniência externa nomeia o lançamento de origem exata, enquanto Tags dos arquivos registra uma fonte de instantâneo local.
release_identities: identidades externas exatas para o que uma versão é. Nenhuma linha significa nenhuma identidade externa. Cada linha nomeia uma versão MusicBrainz ou Discogs e um grupo de versões, e uma versão pode conter identidades em ambas as fontes ao mesmo tempo. Isso é separado da proveniência: a identidade pode mudar sem afirmar que os metadados editáveis atuais foram redefinidos a partir dessa fonte.
tracks com track_artists, mais release_artist_roles e track_artist_roles: listas de faixas e créditos, cada crédito marcado com sua fonte.
track_works, work_parts, work_artists: gravações vinculadas às obras que executam.
audio_formats e audio_format_segments: as especificações de reprodução. Por faixa: codec, taxa de amostragem, profundidade de bits, canais, intensidade sonora e pico medidos, e durações de pregap. Segmentos mapeiam uma faixa para janelas ordenadas de bytes e amostras dos arquivos-fonte, que é como a faixa de um rip CUE, incluindo pregap, pode atravessar regiões de um arquivo grande ou de vários arquivos.
release_files, covers, artist_images: tabelas que carregam blobs. Linhas são entradas de catálogo; os bytes vivem na camada de blobs de coven (veja abaixo).

Sincronizado, com portão, local

Tudo acima sincroniza, mas não incondicionalmente. releases é declarado como raiz com portão na coluna remote: uma linha de lançamento e toda a sua subárvore (faixas, arquivos, créditos, formatos, capa) sincronizam só enquanto remote é true, isto é, enquanto o lançamento é gerenciado na nuvem. Mudar um lançamento para gerenciado publica a subárvore; um lançamento não gerenciado permanece inteiramente no dispositivo de importação, mesmo que seu esquema seja sincronizado. As tabelas ancestrais (artists, albums, works) sincronizam só enquanto algum lançamento sincronizado ainda as referencia, então um dispositivo nunca recebe um artista sem nada abaixo dele.

Tabelas totalmente locais, nunca declaradas para coven:

playback_state: faixa atual, posição, fila, volume, aleatório e repetição. Reprodução é um fato do dispositivo.
imports: acompanhamento de operações de importação.
source_release_payloads: JSON bruto arquivado de MusicBrainz e Discogs, com chave por versão do provedor em vez de uma versão local.Suporta redefinição e reinterpretação exata sem alterar o gráfico de catálogo sincronizado.

Toda tabela sincronizada carrega uma coluna _updated_at de relógio lógico híbrido, o registrador pelo qual a mesclagem campo a campo de coven ordena edições concorrentes; um teste impõe que o conjunto sincronizado e o conjunto que carrega relógio sejam exatamente iguais.

Blobs

Áudio e imagens passam pela camada de blobs de coven em três namespaces, cada um com seu próprio limite de cache por dispositivo: release_files (20 GiB), covers (512 MiB), artist_images (256 MiB).

Arquivos de lançamento são fornecidos pelo usuário e armazenados em cache sob demanda: para um lançamento não gerenciado, o blob é uma referência externa ao arquivo do usuário no caminho original; para um gerenciado, é um objeto enviado que é buscado para o cache na primeira leitura. Capas e imagens de artistas são fornecidas pelo host e armazenadas de antemão: bae produz os bytes (capas são renderizadas novamente como miniaturas JPEG com no máximo 600px de largura), e todo dispositivo as busca ao puxar para que grades renderizem localmente.

Em um local opaco, blobs sobem com chaves de conteúdo sem significado. Em um local navegável, cada linha de blob registra um caminho legível na nuvem ({artist}/{album}/{filename} para áudio, {album}/{release}/cover.{ext} para capas), calculado uma vez no upload para que uma renomeação posterior nunca mova o objeto.

Identidade de um rip

releases.content_hash é um SHA-256 sobre a estrutura de arquivos da pasta importada (caminhos relativos e tamanhos), independente de onde a pasta fica no disco. É assim que bae reconhece um rip já importado quando ele aparece novamente em uma pasta monitorada, e como reimportações encontram o lançamento que devem substituir.