ইম্পোর্ট পাইপলাইন

ইম্পোর্ট ফাইলের একটি ফোল্ডারকে রিলিজ-নির্ভুল তালিকা-নথিতে পরিণত করে, ফাইলের এক বাইট-ও না বদলে। এই পৃষ্ঠা ব্যবহার নির্দেশিকা-এ বর্ণিত ধারার পেছনের পাইপলাইন।

স্ক্যান

দেখা ফোল্ডার প্ল্যাটফর্মের ফাইল-system event দিয়ে নজরে রাখা হয়, অল্প বিরতি দিয়ে নেওয়া হয়, এবং বদলালে আবার স্ক্যান হয়; স্ক্যান শুরু থেকে শুরু না করে বিদ্যমান প্রার্থী-তালিকার সঙ্গে মিলিয়ে নেয়। স্ক্যানার একটি ফোল্ডারকে এক রিলিজ হিসেবে চিহ্নিত করে (অডিও সরাসরি ভিতরে, বা CD1/CD2-এর মতো disc-shaped subfolder), বা সংগ্রহ হিসেবে ভিতরে নামে। File extension দিয়ে অডিও, চিত্র, এবং নথি আলাদা হয়, তারপর অডিও পরীক্ষা করা হয়: যে codec গুরুত্বপূর্ণ তা হলো বাইট-এ FFmpeg যা পায়, ফাইল extension নয়। Partial-ডাউনলোড marker থাকা ফোল্ডার ডাউনলোড শেষ না হওয়া পর্যন্ত বাদ থাকে।

CUE sheet এক অডিও ইমেজকে ট্র্যাক-তালিকায় পরিণত করে। Parser pregap ও postgap, প্রতি-ট্র্যাক performer ও ISRC, এবং single-ফাইল image ও one-ফাইল-per-ট্র্যাক CUE layout সামলায়। ট্র্যাকের সীমা CUE frame (সেকেন্ডের 1/75) থেকে exact নমুনা অবস্থান-এ বদলে যায়, যা পরে প্লেব্যাকের ব্যবহৃত বাইট ও নমুনা উইন্ডো হয়।

প্রমাণ, tag নয়

শনাক্তকরণ এক pass-এ ফোল্ডার থেকে তিন ধরনের প্রমাণ পড়ে:

• একটি disc ID, CD-র exact ট্র্যাক layout-এর MusicBrainz fingerprint, rip log বা CUE sheet থেকে computed;
• barcode, প্ল্যাটফর্মের vision framework দিয়ে চিত্র scan থেকে ডিকোড এবং CUE catalog ক্ষেত্র থেকে read;
• text: চিত্র OCR, ফোল্ডার ও ফাইল name, এবং rip-এর text ফাইল থেকে catalog number ও free text।

Embedded audio tag ইচ্ছাকৃতভাবে প্রমাণ নয়: tagger যা বিশ্বাস করেছে তা তারা বর্ণনা করে, প্রেসিং কী তা নয়। (User unknown রিলিজ হিসেবে ইম্পোর্ট করলে fallback মেটাডেটা-র seed হিসেবে ব্যবহৃত হয়।)

Disc ID ও barcode একই সঙ্গে খোঁজা হয়, disc ID MusicBrainz-এ, barcode MusicBrainz ও Discogs-এ একসঙ্গে, এবং ফল মিলিয়ে দেখা হয়: রিলিজ-গোষ্ঠীতে একমত ফল একদিকে জড়ো হয়, catalog-number match প্রেসিং list সংকুচিত করে, আর সংকেতের অমিল silent best guess না হয়ে ব্যবহারকারী-এর জন্য স্পষ্ট বিরোধ হিসেবে ওঠে। প্রতিটি ফল provenance বহন করে (disc ID দিয়ে পাওয়া, barcode দিয়ে, catalog match) যাতে UI বলতে পারে কেন একটি সারি দেওয়া হচ্ছে।

উৎস

MusicBrainz নাম না দিয়ে strict one-request-per-second গতিতে queried হয়। Discogs keyring থেকে ব্যবহারকারী-এর personal টোকেন দিয়ে authenticate করে, নিজের rate limit-এর মধ্যে paced ও retried হয়, আর rejected টোকেন সেইভাবেই reported হয় যাতে UI সেটি flag করতে পারে, search চুপচাপ fail না করে। Response প্রতি session-এ cached হয়, আর যে উৎস জেতে তার raw JSON ভবিষ্যৎ re-interpretation-এর জন্য ডেটাবেস-এ archived হয়।

সংরক্ষণ

ইম্পোর্ট confirm করলে, ক্রমে চলে:

1. Decode verification: প্রতিটি ট্র্যাক শুরু থেকে শেষ পর্যন্ত ডিকোড হয়; পুরো ডিকোড না হওয়া rip কিছু লেখার আগে ইম্পোর্ট fail করে (config flag দিয়ে এটি disable করা যায়)।
2. Loudness মাপা: একই ডিকোড pass-এ প্রতি ট্র্যাক ও প্রতি অ্যালবাম integrated loudness এবং true peak মাপা হয়, replay-gain ব্যবহারের জন্য stored।
3. কভার নির্বাচন: chosen art (remote, ফোল্ডার image, বা embedded) display thumbnail-এ re-rendered হয়; ফোল্ডার থেকে এলে মূল রিলিজের ফাইলের মধ্যে রাখা হয়।
4. এক লেনদেনে লেখা: রিলিজ, ট্র্যাক, কৃতিত্ব, পরিচয়, ফরম্যাট, segment, ফাইল, এবং কভার এক transaction-এ commit হয়। Half-imported state নেই।

রিলিজ ব্যবহারকারীর ফাইলকে জায়গাতেই reference করে lands করে। ব্যবহারকারী ক্লাউড-managed বেছে নিলে আপলোড commit-এর পরে সংরক্ষণ transition হিসেবে হয়, আর ফাইলের মূল বাইট সবসময় উৎস of truth থাকে; ব্যবহারকারী bae-কে যা দিয়েছে তা কখনও delete বা alter হয় না।

Rip চেনা

প্রতিটি রিলিজ imported ফোল্ডার-এর গঠন (relative path ও size, location-independent)-এর উপর content hash record করে। Re-scan সেটি ব্যবহার করে লাইব্রেরি-তে আগে থেকেই থাকা ফোল্ডার mark করে, আর একই rip-এর re-আমদানি prior রিলিজ duplicate না করে find and replace করে।