डेटा मॉडल

bae का कैटलॉग साधारण SQLite है, जिसे coven को हर तालिका के हिसाब से बताया जाता है: समन्वयित तालिकाएं conflict clock रखती हैं और हर उपकरण तक जाती हैं; घोषित न की गई तालिकाएं उपकरण से बाहर कभी नहीं जातीं। यह विभाजन डेटा मॉडल का सबसे असरदार निर्णय है, इसलिए यह पेज उसी के इर्द-गिर्द बना है।

कैटलॉग graph

schema का समन्वयित केंद्र:

• artists, albums, works: समूह बनाने की परत। एल्बम अपनी रिलीज़ें को जोड़ता है और primary रिलीज़ की ओर इशारा करता है; works classical संरचना के लिए parent/child graph बनाते हैं।
• releases: केंद्रीय इकाई, हर प्रेसिंग के लिए एक पंक्ति। प्रेसिंग facts (label, catalog number, barcode, country, फ़ॉर्मैट, year), मेटाडेटा स्रोत, आयातित फोल्डर का content hash, और मापा गया एल्बम loudness रखती है।
• release_identities: हर स्रोत के हिसाब से रिलीज क्या है। पंक्तियां न हों तो अज्ञात; MusicBrainz या Discogs पंक्ति में रिलीज़ ID हो तो ठीक पहचान; उसके बिना अनुमानित। कोई रिलीज दोनों स्रोतों की identities साथ रख सकती है।
• tracks with track_artists, plus release_artist_roles and track_artist_roles: ट्रैक सूचियां और credits, हर credit अपने स्रोत से चिन्हित।
• track_works, work_parts, work_artists: recordings उन works से जुड़ी हैं जिन्हें वे प्रस्तुत करती हैं।
• audio_formats and audio_format_segments: प्लेबैक विशिष्टताएं। हर ट्रैक के लिए: codec, नमूना rate, bit depth, channels, मापा गया loudness और peak, और pregap lengths। Segments ट्रैक को उसकी स्रोत फाइलों की क्रमबद्ध बाइट और नमूना खिड़कियों पर रखते हैं; इसी से CUE rip का ट्रैक, प्रीगैप सहित, एक बड़ी फाइल या कई फाइलों के हिस्सों में फैल सकता है।
• release_files, covers, artist_images: blob रखने वाली तालिकाएं। पंक्तियां कैटलॉग प्रविष्टियां हैं; बाइट coven की blob layer में रहते हैं (नीचे देखें)।

समन्वयित, शर्तबद्ध, स्थानीय

ऊपर की सारी चीजें समन्वयित होती हैं, पर बिना शर्त नहीं। releases अपने remote स्तंभ पर gated root के रूप में घोषित है: रिलीज़ पंक्ति और उसका पूरा subtree (ट्रैक, फ़ाइलें, credits, फ़ॉर्मैट, कवर) केवल तब समन्वयित होता है जब remote true हो, यानी रिलीज क्लाउड-प्रबंधित हो। किसी रिलीज को प्रबंधित बनाना subtree प्रकाशित करता है; अप्रबंधित रिलीज पूरी तरह आयात करने वाले उपकरण पर रहती है, भले उसका schema समन्वयित हो। Ancestor टेबल (artists, albums, works) केवल तब समन्वयित होती हैं जब कोई समन्वयित रिलीज अभी भी उन्हें संदर्भित करती हो, इसलिए किसी उपकरण को ऐसा कलाकार कभी नहीं मिलता जिसके नीचे कुछ न हो।

पूरी तरह स्थानीय तालिकाएं, जिन्हें coven को कभी घोषित नहीं किया जाता:

• playback_state: मौजूदा ट्रैक, स्थिति, कतार, volume, shuffle और repeat। प्लेबैक उपकरण की अवस्था है।
• imports: आयात प्रक्रिया पर नजर।
• release_metadata: MusicBrainz और Discogs से archived raw JSON, आगे फिर समझने के लिए रखा गया।

हर समन्वयित तालिका में _updated_at hybrid-logical-clock column होता है, वही register जिससे coven का फ़ील्ड-by-फ़ील्ड merge साथ-साथ हुए edits को क्रम देता है; test यह लागू करता है कि समन्वयित set और clock रखने वाला set बिल्कुल समान हों।

Blobs

Audio और images coven की blob layer से तीन namespaces में जाते हैं, हर एक के अपने उपकरण कैश budget के साथ: release_files (20 GiB), covers (512 MiB), artist_images (256 MiB)।

रिलीज फाइलें उपयोगकर्ता से आई होती हैं और जरूरत पड़ने पर कैश होती हैं: अप्रबंधित रिलीज के लिए blob उपयोगकर्ता की फाइल के मूल path का बाहरी reference है; प्रबंधित रिलीज के लिए यह uploaded object है, जो पहली पढ़ाई पर कैश में आता है। Covers और कलाकार images host से आती हैं और पहले से कैश की जाती हैं: bae बाइट बनाता है (कवर अधिकतम 600px wide JPEG thumbnails के रूप में फिर बनाए जाते हैं), और हर उपकरण pull पर उन्हें लाता है ताकि grids स्थानीय रूप से render हों।

अपारदर्शी घर पर, blobs अर्थहीन content कुंजियां के नीचे अपलोड होते हैं। ब्राउज-योग्य घर पर हर blob पंक्ति पढ़ने योग्य क्लाउड path दर्ज करती है ({artist}/{album}/{filename} audio के लिए, {album}/{release}/cover.{ext} कवर के लिए), जो अपलोड पर एक बार निकाला जाता है ताकि बाद में नाम बदलने से object न हिले।

rip की पहचान

releases.content_hash आयातित फोल्डर की फाइल संरचना (सापेक्ष paths और sizes) पर SHA-256 है, इस बात से स्वतंत्र कि फोल्डर disk पर कहां है। इसी से bae watched फ़ोल्डर में फिर दिखने वाले पहले से आयातित rip को पहचानता है, और दोबारा आयात उस रिलीज को ढूंढते हैं जिसे बदलना चाहिए।