متادیتای انتشار موسیقی: چگونه نام هنرمند، عنوان قطعه، هنرمند مهمان، نسخه و متن فارسی را طوری بنویسیم که سالم به مقصد برسد
با تمرکز کامل بر خط فارسی: کاراکترهای همشکلِ ناهمبایت، نیمفاصله، کسرهٔ اضافه و ارقام.
پاسخ کوتاه
نام هنرمند و عنوان قطعه برای فروشگاههای موسیقی «متن» نیستند؛ کلید هستند. سامانهها رشتهٔ بایتها را با هم مقایسه میکنند، نه شکل ظاهری حروف را؛ بنابراین «کیهان» با یِ فارسی U+06CC و «كيهان» با یِ عربی U+064A دو نام کاملاً متفاوتاند، هرچند روی صفحه یکسان دیده شوند. برای فارسی سه قاعده بیشترِ خسارت را جلوگیری میکند: یکبار نامِ رسمی خود را با کدپوینتهای درست بنویسید (ی از U+06CC و ک از U+06A9 است)، آن را در فایلی ذخیره کنید و از آن پس همیشه کپی کنید و هرگز دوباره تایپ نکنید؛ نیمفاصله را در جای درست بگذارید و بدانید که بعضی مسیرهای تحویل آن را حذف میکنند؛ و یک نظام رقمی انتخاب کنید و در کل کاتالوگ به آن پایبند بمانید. عنوان قطعه فقط نام قطعه است — نام هنرمند مهمان، نام ریمیکسر و توکنِ feat. هرگز داخل عنوان تایپ نمیشوند، بلکه در فیلد نقشِ خودشان میروند. و آخر اینکه متادیتای غلط، برخلاف مسترِ بد، هیچ علامت هشداری نمیدهد: پخش میشود، درست دیده میشود، و پول به حساب اشتباه میرود.
۱. متادیتا کجای زنجیرهٔ انتشار ایستاده است
هیچ فروشگاهی آهنگ شما را نمیشنود. آنچه میرسد یک بستهٔ داده است و صوت فقط یکی از فیلدهای آن. تصمیمهایی که این بسته میگیرد — اینکه قطعه روی کدام صفحهٔ هنرمند بنشیند، آمار پخش زیر کدام هویت جمع شود، حقالامتیاز نشر از کدام مخزن پرداخت شود، و اصلاً انتشار پذیرفته شود یا رد — همه از روی متنهایی گرفته میشود که شما در ده دقیقهٔ آخر تایپ کردهاید.
قالب انتقال هم استاندارد است: مجموعهپیامهای DDEX ERN که سرنامِ Electronic Release Notification Message Suite است و انتشار شما را به سرویسها میرساند.
نکتهٔ ساختاری که بیشترین خطاهای گران از آن میآید، لایهها است. یک انتشار سه لایه دارد:
- محصول — آلبوم یا تکآهنگ، با شناسهٔ
UPC/EAN
- ضبط — هر ترک، با شناسهٔ
ISRC
- اثر — آهنگ و شعر، با شناسهٔ
ISWC
اگر نمیدانید یک اطلاعات به کدام لایه تعلق دارد، هنوز آمادهٔ ثبتش نیستید. سالِ خطِ ℗ سالِ نخستین انتشار ضبط است، نه تاریخ آپلود شما؛ خطِ © مالک طرح جلد و بستهبندی را میگوید. این دو مدام جای هم تایپ میشوند.
همچنین «تاریخ انتشار» با «تاریخ انتشار اصلی» یکی نیست. اگر بازنشرِ یک ضبط قدیمی است، تاریخ اصلی را بنویسید؛ وگرنه به کل زنجیره اعلام کردهاید که این ضبط تازه است.
فیلدهایی که واقعاً وجود دارند
هنرمند اصلی. تنها فیلدی که تعیین میکند قطعه روی کدام صفحه بنشیند و آمار و دنبالکننده و تاریخچهٔ الگوریتمی زیر کدام هویت جمع شود. راهنمای عمومی Spotify صریح است:
"List each artist's name in a separate field."
هنرمند مهمان. نقشی جداگانه روی همان ضبط. راهنمای سبک Apple میخواهد هنرمند مهمان در سطح ترک ثبت شود، با نقشِ Featuring یا With و نه بهعنوان هنرمند اصلی.
ریمیکسر. باز هم یک نقش. راهنمای Apple:
"Remix tracks...must list the original artist as Primary with the remixer assigned the remixer role."
آهنگساز و ترانهسرا. توصیفکنندهٔ اثراند، نه ضبط. مسیر پول نشر از همینجا میگذرد.
تهیهکننده. یک کردیت است؛ نه صفحه میسازد و نه پرداخت سمت ضبط دارد.
نسخه یا زیرعنوان. پرانتزی که دو ضبط همنام را از هم جدا میکند (بخش ۸).
پرچم محتوای صریح. یک مقدار بولی است، نه یک کلمه. راهنمای Apple:
"Explicit content must be flagged Explicit with a parental advisory tag. Terms like (Explicit)...must not be used for album...or track titles."
زبان اثر (چیزی که خوانده میشود) و زبان عنوان (زبان و خطِ رشتهٔ عنوان) دو فیلد جدا هستند و میتوانند بهدرستی متفاوت باشند: یک قطعهٔ بیکلامِ سنتور با عنوان فارسی، زبان کلام ندارد ولی زبان عنوانش فارسی است. زبان عنوان به فروشگاه میگوید متن شما را چطور مرتب، نمایه و رندر کند — و در انتشارهای غیرلاتین یکی از پرتأثیرترین فیلدهاست.
ژانر. یک سیگنال مسیریابی است، نه توصیف سلیقه؛ تعیین میکند انتشار در کدام بسترهای الگوریتمی و تحریریه واجد شرایط باشد.
۲. ی و ک: پرتکرارترین خرابیِ کاتالوگ فارسی
اگر از کل این متن فقط یک بخش را میخوانید، باید همین باشد.
فارسی از دو حرف استفاده میکند که در عربی معادلهای دیگری دارند:
- ی — نام یونیکدیاش
ARABIC LETTER FARSI YEH و کدپوینتش U+06CC
- ک — نام یونیکدیاش
ARABIC LETTER KEHEH و کدپوینتش U+06A9
در برابرشان، عربی اینها را دارد:
- ي — نام یونیکدیاش
ARABIC LETTER YEH و کدپوینتش U+064A
- ك — نام یونیکدیاش
ARABIC LETTER KAF و کدپوینتش U+0643
هیچکدام غلط نیستند؛ هرکدام حرفِ درستِ زبانِ خودشاناند. مشکل این است که در حالت آغازین و میانی، ی و ي دقیقاً یک شکل دارند و در بسیاری از قلمها در حالت پایانی هم تفاوتشان فقط دو نقطه است که در قلمهای نمایشی حذف یا کمرنگ میشود؛ ک و ك هم فقط در یک سرکش با هم فرق دارند و بعضی قلمهای عربی همان سرکش را میکشند.
نتیجه: «علی» و «علي» برای چشم یکیاند و برای هر سامانهٔ تطبیق، دو رشتهٔ متفاوت.
سناریوی واقعی، و بسیار رایج:
- هنرمند «کیهان کلهر» تکآهنگ اول را با صفحهکلید فارسی ثبت میکند؛ یعنی ک و ی فارسی.
- برای انتشار دوم، همکارِ استودیو نام را از روی یک صفحهکلید عربی دوباره تایپ میکند: «كيهان كلهر».
- فروشگاه رشتهٔ جدید را با هیچ هویتی تطبیق نمیدهد و یک صفحهٔ هنرمند دوم میسازد.
- آمار پخش دو تکه میشود، دنبالکنندهها منتقل نمیشوند، و هویت دوم بدون هیچ تاریخچهٔ الگوریتمی از صفر شروع میکند.
- هیچکس با نگاهکردن پیدایش نمیکند، چون چیزی برای دیدن وجود ندارد.
همین اتفاق برای نامهای پرتکرار فارسی میافتد: «شجریان»، «علیزاده»، «مشکاتیان»، «لطفی»، «پریسا»، «کامکارها»، «سیاوش»، «کیوان» — همهٔ اینها دستکم یک ی یا ک دارند، یعنی همهٔ اینها دو املای همشکل دارند.
سه نکتهٔ فنیِ لازم:
- هیچ فرم نرمالسازی یونیکد این دو را یکی نمیکند. ی و ي تجزیهٔ متعارف یا سازگاری ندارند؛ چهار فرمِ
NFC / NFD / NFKC / NFKD همه دقیقاً همان کدپوینتی را برمیگردانند که به آنها دادهاید. یعنی نمیتوانید امیدوار باشید که «سامانه خودش درستش میکند».
- تشخیصش با چشم ممکن نیست، با ابزار ممکن است. سادهترین آزمون: در ویرایشگر متن، دنبال «ي» و «ك» عربی بگردید؛ اگر شمارش صفر نبود، اشکال دارید.
- اختلاط فارسی و عربی در یک رشته هم رخ میدهد و بدترین حالت است: «کيهان» با ک فارسی و ی عربی، نه با نسخهٔ کاملاً فارسی تطبیق میشود و نه با نسخهٔ کاملاً عربی. سه هویت از یک نفر.
راهحل روندی است، نه فنی: کدپوینتهای دقیق نام را یکبار تعیین کنید، در یک فایل متنی نگه دارید، و از آن پس در هر فیلد از هر انتشار فقط بچسبانید. تایپ دوباره، جایی است که واریانتها متولد میشوند.
هر دو مرجع سبک هم همین را میگویند. راهنمای Music Biz:
"Artist name spelling should remain consistent for all content for an artist, where possible."
و راهنمای Spotify میخواهد املا و قالببندی از انتشاری به انتشار دیگر ثابت بماند:
"including any punctuation, abbreviations, or acronyms"
و توجه کنید که این خطا معمولاً رد نمیشود. تحویل با موفقیت انجام میشود. به همین دلیل گرانترین قلم این فهرست است. اصلاحش هم ویرایش نیست، درخواست ادغام است: توزیعکننده باید از هر فروشگاه جداگانه بخواهد دو هویت را یکی کند، هر فروشگاه صف و مدارک خودش را دارد، بعضی سریع انجام میدهند و بعضی هرگز.
۳. نیمفاصله: نویسهای که هست، دیده نمیشود، و حذف میشود
فارسی برای جدا کردن اجزای یک واژه بدون ایجاد فاصلهٔ کامل، به اتصالگر تهیِ صفرعرض نیاز دارد؛ کدپوینتش U+200C است و نام یونیکدیاش ZERO WIDTH NON-JOINER. در فارسی به آن نیمفاصله میگویند.
بدون آن، این واژهها غلط میشوند:
| با نیمفاصله | چسبیده | با فاصلهٔ کامل |
|---|---|---|
| میرود | میرود | می رود |
| آهنگها | آهنگها | آهنگ ها |
| تازهتر | تازهتر | تازه تر |
| سهتار | سهتار | سه تار |
| بیکلام | بیکلام | بی کلام |
| نیمفاصله | نیمفاصله | نیم فاصله |
سه رفتار متفاوت از سه سامانهٔ تحویل دیده میشود و هر سه واقعیاند:
۱. حذف بیصدا. برخی فیلدهای فرم و برخی مسیرهای پاکسازی، نویسههای «نامرئی» یا «کنترلی» را دور میریزند. «شبهای تهران» میشود «شبهای تهران». رشته کوتاهتر شده، نام تغییر کرده، و روی صفحه هم بد دیده میشود چون اتصال حروف عوض شده است.
۲. تبدیل به فاصلهٔ کامل. بدتر از حذف است، چون تعداد واژهها را عوض میکند: «سهتار» که نام یک ساز است میشود «سه تار»، یعنی سه عدد تار، و در جستوجو و مرتبسازی رفتاری کاملاً متفاوت پیدا میکند. همین بلا سر «بیکلام»، «چهارمضراب» و «پیشدرآمد» هم میآید.
۳. حفظ درست. که خواستهٔ ماست، ولی تضمینشده نیست.
چند واقعیت فنی:
- کلاس دوسویهٔ این نویسه
BN است، یعنی در الگوریتم دوسویه «خنثیِ حذفشدنی» شمرده میشود و در بسیاری از پیادهسازیها پیش از رندر نادیده گرفته میشود — ولی در مقایسهٔ رشته هرگز نادیده گرفته نمیشود.
- نرمالسازی آن را برنمیدارد. حتی فرمِ سازگاریِ
NFKC هم این نویسه را دستنخورده باقی میگذارد؛ این را در برابر پایگاه دادهٔ نویسههای یونیکد بررسی کردهایم. پس «نرمالسازی کردم» نه به معنای «پاک شد» است و نه به معنای «حفظ میشود»، چون حذفکننده معمولاً یک فیلترِ دستیِ فروشگاه یا واسط است، نه نرمالسازی.
- یک نام که یکبار با نیمفاصله و یکبار بدون آن تحویل شود، دو رشتهٔ متفاوت و بالقوه دو هنرمند است. یعنی نیمفاصله دقیقاً همان ریسک بخش ۲ را دارد، با این تفاوت که حتی جستوجوی چشمی هم کمکی نمیکند.
توصیهٔ عملی: برای نام هنری، اگر واژهٔ مرکب اجازه میدهد، شکل تکواژهایِ بدون نیاز به نیمفاصله را انتخاب کنید. برای عنوان قطعهها که نیمفاصله ناگزیر است، بعد از انتشار متن عنوان را از صفحهٔ فروشگاه کپی کنید و با رشتهٔ اصلی خودتان نویسهبهنویسه مقایسه کنید. این تنها راه اطمینان است.
۴. نیمفاصله در برابر فاصلهٔ کامل در نامهای مرکب
این ادامهٔ بخش قبل است ولی مسئلهاش هویتی است، نه فنی. نامهای مرکب فارسی سه املای رایج دارند و هر سه در طبیعت دیده میشوند:
- علیرضا — با نیمفاصله
- علیرضا — چسبیده
- علی رضا — با فاصلهٔ کامل
برای یک انسان، هر سه یک نفرند. برای موتور تطبیق، سه نفرند. و بدتر: فاصلهٔ کامل معنای ساختاری را هم عوض میکند، چون بسیاری از سامانهها «علی رضا» را نام کوچک بهعلاوهٔ نام خانوادگی تفسیر میکنند و در مرتبسازی زیر «ر» میبرند، در حالی که «علیرضا» زیر «ع» میرود.
همین برای «محمدرضا / محمدرضا / محمد رضا»، «امیرحسین»، «سیدجواد»، «نیکآهنگ» و «خوشنواز» صادق است.
قاعدهای که کار میکند:
- یک املا انتخاب کنید — ترجیحاً همانی که هنرمند در شناسنامهٔ اینترنتیاش (نام کاربری، دامنه، جلد آثار قبلی) استفاده میکند.
- اگر آزادید انتخاب کنید، شکل چسبیده را برای نام هنری ترجیح دهید؛ کمترین سطح آسیبپذیری را دارد، چون نه نیمفاصلهای دارد که حذف شود و نه فاصلهای که تفسیر شود.
- آن را کنار همان فایلِ کدپوینتهای بخش ۲ بنویسید و دیگر تصمیم نگیرید.
۵. کسرهٔ اضافه و حرف «ه»: هٔ، ۀ و ه
فارسی برای نشاندادن اضافه روی واژههای مختوم به «ه» علامتی دارد که در متادیتا سه شکلِ ذخیرهٔ کاملاً متفاوت پیدا میکند، و هیچکدام با نرمالسازی به دیگری تبدیل نمیشود:
الف) دو نویسه: «ه» بهعلاوهٔ همزهٔ بالا، یعنی U+0647 بهاضافهٔ U+0654 — شکل توصیهشده در بیشتر شیوهنامههای فارسی، مثل «خانهٔ پدری» یا «قطعهٔ اول».
ب) یک نویسه: ۀ، یعنی U+06C0 با نام یونیکدی ARABIC LETTER HEH WITH YEH ABOVE.
ج) بدون علامت: «خانه پدری» — املای رایج و پذیرفته در نوشتار غیررسمی، و بسیار پرکاربرد در فرمهای آنلاین و نوار جستوجو.
نکتهٔ فنی که تقریباً همه اشتباه میکنند و ما آن را در برابر پایگاه دادهٔ نویسههای یونیکد بررسی کردهایم: **تجزیهٔ متعارفِ شکل (ب) به «ه» و همزه نیست، بلکه به U+06D5 بهاضافهٔ U+0654 است** — یعنی به ARABIC LETTER AE یعنی حرفی که در املای فارسی به کار نمیرود. نتیجهٔ عملی این است که شکل (الف) و شکل (ب) از نظر یونیکد همارزِ متعارف نیستند: اگر «خانهٔ» را به شکل (الف) بنویسید و NFC بگیرید، همان دو نویسه باقی میماند و به ۀ فشرده نمیشود؛ و اگر ۀ را با NFD باز کنید، به حرفی بیگانه تجزیه میشود که با «ه» فارسیِ شما تطبیق نمیخورد.
پس «قطعهٔ دوم»، «قطعۀ دوم» و «قطعه دوم» سه رشتهٔ متمایز و ماندگارند.
توصیه برای فیلدهای متادیتا. در نام هنرمند هرگز از علامت اضافه استفاده نکنید؛ نام هنرمند یک اسم است، نه یک ترکیب اضافی. در عنوان قطعه، اگر ساختار جمله اضافه میخواهد، شکل (الف) را انتخاب کنید و در کل کاتالوگ همان را نگه دارید. ولی بدانید که مخاطبِ شما در نوار جستوجوی موبایل تقریباً همیشه شکل (ج) را تایپ میکند؛ و اگر فروشگاه پیش از نمایهسازی نویسههای ترکیبی را حذف نکند — و هیچ مقصدی این را تضمین نمیکند — عنوانِ باعلامت هرگز با جستوجوی بیعلامت روبهرو نمیشود.
همین منطق برای همزهٔ روی «ی» هم برقرار است؛ آن هم زیر NFC فشرده نمیشود و دو نویسه باقی میماند.
۶. ارقام: ۰۱۲۳ فارسی در برابر ٠١٢٣ عربی
سه مجموعهٔ رقم در بازیاند و اینها کدپوینتهای متفاوتاند، نه سبکهای متفاوت:
- ارقام لاتین ۰ تا ۹، در بازهٔ
U+0030–U+0039
- ارقام عربی-هندی ٠ ١ ٢ ٣ ٤ ٥ ٦، در بازهٔ
U+0660–U+0669
- ارقام عربی-هندیِ گسترده که فارسی و اردو از آن استفاده میکنند: ۰ ۱ ۲ ۳ ۴ ۵ ۶، در بازهٔ
U+06F0–U+06F9
سه رقم فارسیِ چهار، پنج و شش (۴ ۵ ۶) با معادلهای عربیشان (٤ ٥ ٦) حتی شکل ظاهری متفاوتی دارند، ولی صفر تا سه — یعنی ۰۱۲۳ در برابر ٠١٢٣ — در بیشتر قلمها یکسان دیده میشوند. یعنی همان تلهٔ بخش ۲، اینبار برای اعداد.
و یک تفاوت رفتاری واقعی هم دارند که در پایگاه دادهٔ نویسههای یونیکد ثبت شده است: کلاس دوسویهٔ ارقام عربی-هندی AN است، یعنی «عدد عربی»، اما کلاس ارقام فارسی EN است، یعنی «عدد اروپایی». از منظر الگوریتم دوسویه، ارقام فارسی مثل ارقام لاتین رفتار میکنند، نه مثل ارقام عربی. قاعدهٔ W2 یک عدد اروپایی را وقتی نزدیکترین نویسهٔ قویِ پیش از آن یک حرف عربی باشد به عدد عربی بازنوعدهی میکند، بنابراین در نمایش درون متن فارسی اغلب یکسان دیده میشوند — ولی هرگز در مرتبسازی، جستوجو و مقایسهٔ رشته، چون نویسههای متفاوتیاند.
پیامد عملی: شنوندهای که «آلبوم ۲» را با ارقام فارسی جستوجو میکند، عنوانی را که با ارقام لاتین ذخیره شده پیدا نمیکند، مگر آنکه لایهٔ جستوجوی آن فروشگاه ارقام را همسانسازی کند — و هیچ مقصدی این را تضمین نمیکند. برعکسش هم صادق است.
قاعده: یک مجموعهٔ رقم برای کل کاتالوگ انتخاب کنید و هرگز مخلوط نکنید. برای فیلدهایی که ماشین میخواند — شمارهٔ جلد، شمارهٔ قطعه، شمارهٔ دیسک، سال — ارقام لاتین امنترین پیشفرض است. برای عنوانهای نمایشی، اگر ارقام فارسی میخواهید، از بازهٔ درست استفاده کنید و مطمئن شوید که سهواً ارقام عربی از یک صفحهکلید عربی وارد نشده باشند.
خطای واقعی و پرتکرار: عنوانی مثل «ردیف میرزا عبدالله، دستگاه شور، درآمد ۱» که در آن رقمِ یک از صفحهکلید عربی آمده و در حقیقت ١ است. روی صفحه درست دیده میشود، در جستوجو مرده است. و از آنجا که مجموعهآثار ردیف معمولاً دهها ترکِ شمارهدار دارند، یک صفحهکلید اشتباه میتواند یک آلبوم کامل را نایافتنی کند.
۷. هنرمند مهمان: چرا فیلد عنوان جای این نیست
پرخسارتترین ورودی در توزیع مستقل این است که نام هنرمند مهمان، همراه با توکنِ ft. داخل فیلد عنوان تایپ شود و فیلد نقشِ «هنرمند مهمان» خالی بماند. مثلاً عنوانی که بهجای «دلتنگی»، به شکل «دلتنگی» بهعلاوهٔ آن توکن و نام «سحر» نوشته شده باشد.
فیلد عنوان یک رشتهٔ نمایشی است و هیچ هویتی حمل نمیکند. پس هنرمند مهمان نه کردیت پیونددار میگیرد، نه قطعه روی صفحهٔ خودش ظاهر میشود، نه مسیر کشفی به سمت شما ساخته میشود و نه چیزی وارد آمار او میشود. در عوض، فروشگاه ممکن است آن توکن و نام را بخشی از نام قطعه بداند و قطعه تا ابد با آن دنباله بماند — و بعد وقتی خودش هم رشتهٔ نمایشی میسازد، نام مهمان دو بار در عنوان تکرار میشود. همان قطعههای دوبارهنویسیشدهای که از یک نگاه معلوم است تحویلِ آماتور بودهاند.
فروشگاهها این را صریح گفتهاند. Spotify:
"You shouldn't include any artists' names in your track or release titles."
و در مستندات ارائهدهندگانش:
"Spotify strongly recommends against including additional information, such as references to 'Featured Artists' in track and product titles."
و Music Biz توصیه میکند هنرمندان مهمان در سطح نقشِ هنرمند اعتباردهی شوند و این داده به عنوان ترک یا آلبوم اضافه نشود.
اگر قرارداد شما اجباراً میخواهد این نام در عنوان بیاید، قاعدهاش ثابت است و مخصوصاً برای فارسی مهم. Music Biz دربارهٔ دو توکنِ feat. و with میگوید وقتی در عنوان میآیند عموماً با حروف کوچک و به انگلیسی نوشته میشوند، و راهنمای Apple میگوید قالببندی آنها باید کوچک، انگلیسی، ترجمهنشده و داخل پرانتز یا کروشه باشد.
یعنی: «با همراهی»، «بههمراه»، «فیت»، یا هر نویسهگردانیِ فارسیِ آن توکن را در فیلد عنوان ننویسید. این یک نشانهٔ ماشینخوان است، نه یک کلمه.
ساختار درست این است که فیلد عنوان فقط «دلتنگی» باشد، فیلد هنرمند اصلی «نیما»، و فیلد هنرمند مهمان «سحر». فروشگاه خودش رشتهٔ نمایشی را میسازد و پرانتز را سر جایش میگذارد. نقشها هویتاند و عنوانها نمایش؛ گذاشتن هویت در یک فیلد نمایشی، هم هویت را نابود میکند و هم نمایش را خراب.
۸. فیلد نسخه: زنده، بیکلام، ریمیکس
فیلد نسخه یک کار دارد: تمایز دو ضبط که عنوان مشترک دارند. همین آزمونِ تصمیم است — اگر ضبط دومی وجود ندارد، فیلد را خالی بگذارید.
راهنمای Apple برای این کار اصطلاحهای داخل پرانتز یا کروشه را میخواهد:
"To differentiate multiple versions of the same track title, use terms in parentheses or brackets such as: Alternate Take...Live, Instrumental, Single Version, Radio Edit."
و راهنمای Music Biz میگوید اول پرانتز، و کروشه برای جزئیات بعدی.
برای موسیقی ایرانی چند نکتهٔ اختصاصی هست:
- «بیکلام» یا واژهٔ انگلیسیِ آن. اگر فیلد نسخه انگلیسی میپذیرد و مخاطب بینالمللی دارید،
Instrumental واژهٔ استاندارد است. اگر زبان عنوان را فارسی اعلام کردهاید، «بیکلام» درست است — ولی در کل کاتالوگ فقط یکی از این دو را به کار ببرید. کاتالوگی که نیمی «بیکلام» و نیمی انگلیسی است، در فیلترهای فروشگاه دو دستهٔ جدا میسازد.
- اجرای زنده. یا «اجرای زنده» بنویسید یا معادل انگلیسیاش؛ نه هر دو در یک کاتالوگ.
- بداههنوازی و ردیف. عنوانهایی مثل «بداههنوازی سهتار، دستگاه همایون» یا «ردیف میرزا عبدالله — درآمد ماهور» توصیف محتوا هستند، نه نسخه. اینها در عنوان میآیند، نه در فیلد نسخه؛ چون دو ضبط متفاوت از یک اثر نیستند، دو اثر متفاوتاند.
- «تصنیف»، «چهارمضراب»، «پیشدرآمد» و «رنگ» هم بخشی از عنواناند، نه نسخه.
- ریمیکس. قالب استاندارد، نام ریمیکسر بهاضافهٔ واژهٔ
Remix است، در پرانتز؛ و ریمیکسر باید در فیلد نقش خودش هم ثبت شود.
و دو دام:
**اصطلاحِ Radio Edit مترادف «نسخهٔ بدون کلمات رکیک» نیست.** راهنمای Music Biz آن را برای نسخهای نگه میدارد که واقعاً برای پخش رادیویی آماده شده، و برای ویرایش محتوایی اصطلاحِ Edited Version را میخواهد. اولی ویرایش طول است، دومی ویرایش محتوا.
**برچسبِ Original Mix همهجا امن نیست.** راهنمای منتشرشدهٔ Apple آن را مجاز نمیداند و در فهرست عبارتهای ممنوع میآورد:
"Exclusive, Limited Edition, Album Version, Original Mix, Tone, Alert Tone...Dolby Atmos, lossless, high-resolution audio."
راهنمای عمومی Spotify هیچ قاعدهای که نامِ این برچسب را ببرد منتشر نکرده و موضع منتشرشدهاش همان قاعدهٔ کلی است که عنوان نباید اطلاعات اضافی حمل کند. در عمل، رفتار فروشگاهها با این برچسب متفاوت است و پیشاعتبارسنجی توزیعکنندهٔ شما هم نقش دارد. اگر نسخهٔ اصلی تنها نسخهٔ انتشار است، فیلد را خالی بگذارید؛ این پاسخ همهجا درست است.
۹. چرا یک واژهٔ لاتین وسط جملهٔ فارسی جابهجا میشود
یونیکد متن را به ترتیب منطقی ذخیره میکند — همان ترتیبی که میگویید، تایپ میکنید و بلند میخوانید. ترتیب نمایش هنگام رندر از روی آن محاسبه میشود، بهوسیلهٔ الگوریتم دوسویهٔ یونیکد، یعنی سندِ Unicode Standard Annex #9 که به آن UAX #9 هم میگویند:
"The Unicode Standard prescribes a memory representation order known as logical order"
و:
"When working with bidirectional text, the characters are still interpreted in logical order—only the display is affected."
این توضیح میدهد چرا متادیتای فارسی جنزده به نظر میرسد: رشتهٔ ذخیرهشده میتواند کاملاً درست باشد و نمایش غلط، و میتواند نمایش درست باشد و بایتها غلط — و روی صفحه این دو خرابی عین هم دیده میشوند.
مکانیزم: هر نویسه یک نوع دوسویه دارد. حروف فارسی از نوعِ AL هستند، حروف لاتین از نوعِ L هستند، ارقام لاتین و ارقام فارسی از نوعِ EN و ارقام عربی از نوعِ AN و فاصله و بیشتر نشانههای سجاوندی خنثیاند.
دو قاعده خسارت میزنند. اول جهت بند: قاعدههای P2 و P3 اولین نویسهٔ قوی را پیدا میکنند و جهت پایه را از آن میگیرند؛ پس عنوانی که با یک واژهٔ لاتین شروع شود، جهت پایهاش چپبهراست میشود، حتی اگر بقیهاش فارسی باشد. دوم، حلِ خنثیها. قاعدهٔ N1:
"A sequence of [neutrals] takes the direction of the surrounding strong text if the text on both sides has the same direction"
و قاعدهٔ N2 میگوید خنثیهایی که اجماعی ندارند جهت بند را میگیرند. سپس قاعدهٔ L2 برای نمایش بازچینش میکند:
"reverse any contiguous sequence of characters that are at that level or higher."
نتیجه: عنوانی که شما با دقت به شکل «پرواز شبانه» بهاضافهٔ یک پرانتزِ حاوی نام ریمیکسر به لاتین تایپ کردهاید، در صفحهٔ فروشگاهی که جهت پایهاش چپبهراست است، با پرانتزِ جداشده و برعکس رندر میشود. هیچ چیزی خراب نشده؛ بایتها همانی است که تایپ کردید. فقط بستر جهتِ متفاوتی داشته و خنثیها را طور دیگری حل کرده است.
راههای کاهش آسیب:
- هرجا مدل داده اجازه میدهد، بهجای رشتهٔ دوجهته از فیلدهای جداگانه استفاده کنید؛ نام ریمیکسر در فیلد نقش، نه در عنوان.
- توکن لاتین ناگزیر را از موقعیت اول رشته دور نگه دارید.
- نشانههای سجاوندیِ تزئینی را در مرزهای جهت نگذارید.
- هرگز نمایش را با تایپکردن واژهها بهصورت وارونه «درست» نکنید. حاصل، رشتهای است غلط در ترتیب منطقی، درست فقط در یک بسترِ رندر، و خراب در همهجای دیگر، از جمله در جستوجو.
- این سند نویسههای جداساز تعریف کرده است — چهار جداسازِ
LRI / RLI / FSI / PDI و سه نشانهٔ LRM / RLM / ALM — ولی بسیاری از خطوط لولهٔ تحویل، نویسههای قالببندیِ نامرئی را پاک میکنند. یعنی نمیتوان به آنها تکیه کرد.
۱۰. کشیده، اعراب، و نرمالسازی
کشیده یا تطویل با کدپوینتِ U+0640 واژه را برای همترازی یا تزئین میکشد؛ مثل «مـــحـــمـــد» بهجای «محمد». در فارسی همانقدر رایج است که در عربی، بهویژه در طرح جلدها و در عنوانهایی که از روی یک لوگو بازتایپ شدهاند. در فیلد متادیتا خالص ضرر است: بخشی از رشته است، معنایی حمل نمیکند، هیچکس هنگام جستوجو آن را تایپ نمیکند، و — بخشی که بیشتر مردم اشتباه میکنند — هیچ فرم نرمالسازی آن را حذف نمیکند؛ این نویسه تجزیهٔ متعارف یا سازگاری ندارد، پس هر چهار فرمِ NFC / NFD / NFKC / NFKD آن را دقیقاً سر جایش میگذارند. باید عمداً و پیش از تحویل حذفش کنید.
اعراب — فتحه، ضمه، کسره، سکون و تشدید — در بازهٔ U+064B–U+0652 نویسههای ترکیبیاند. در فارسی معمولاً فقط در متون آموزشی، شعر و جایی که ابهام تلفظ هست به کار میروند. برای متادیتا: از نام هنرمند و عنوان حذفشان کنید، مگر آنکه واقعاً بخشی از هویت اثر باشند؛ و اگر آوردید، هر بار دقیقاً یکسان بیاورید. دلیلش جستوجوست: شنونده شکل بیاعراب را تایپ میکند و اگر فروشگاه پیش از نمایهسازی علامتها را حذف نکند، این دو هرگز به هم نمیرسند. اعرابگذاری ناقص هم با هیچکدام تطبیق نمیشود.
نرمالسازی. سندِ Unicode Standard Annex #15 چهار فرم تعریف میکند؛ دو تای مهم در اینجا NFC است که شکل از پیش ترکیبشده است، و NFD که حرف پایه بهعلاوهٔ نشانههای ترکیبیِ جداست. همارزی متعارف نویسههایی را پوشش میدهد که به تعبیر همان سند:
"when correctly displayed should always have the same visual appearance."
در خط فارسی چند حرف واقعاً ترکیباند: «ئ» با کدپوینتِ U+0626 زیر NFD به دو نویسه تجزیه میشود. یک شکل روی صفحه، ولی یک یا دو کدپوینت در حافظه، بسته به اینکه کدام نرمافزار رشته را ساخته باشد. طول بایت متفاوت، نتیجهٔ مقایسه متفاوت، ظاهر یکسان.
توصیه: بهطور یکنواخت به NFC نرمال کنید. ولی سه هشدار:
- نرمالسازی پاککننده نیست. کشیده را برنمیدارد، نیمفاصلهٔ حذفشده را برنمیگرداند، و ی عربی را به ی فارسی تبدیل نمیکند.
- فرمهای سازگاری را بهعنوان درمانِ همهچیز به کار نبرید؛ خودِ آن سند میگوید فرمِ
NFKC بسیاری از تمایزهای قالببندی را «پاک میکند» و ممکن است «تمایزهایی را که برای معنا مهماند» از بین ببرد.
- همانطور که در بخش ۵ دیدیم، شکل دونویسهایِ «هٔ» زیر
NFC فشرده نمیشود، پس نرمالسازی این ابهام را هم حل نمیکند.
۱۱. آوانویسی لاتین: یکی انتخاب کنید و هرگز عوضش نکنید
هر هنرمند ایرانی در سامانههای جهانی دو نام دارد: فارسی و لاتین. هر دو باید تکمقداری باشند.
آوانویسی در عمل استاندارد نیست. برای «کیهان» اینها همه در طبیعت دیده میشوند:
Kayhan / Keyhan / Kaihan / Kayhaan
برای «شجریان»:
Shajarian / Shajaryan / Shajarrian
برای «خورشید»:
Khorshid / Khurshid / Xorshid
برای «سهتار»:
Setar / Se-tar / Sehtar / Setār
و برای «قاسم»:
Ghasem / Qasem / Ghassem
هرکدام قابلدفاعاند و هرکدام برای موتور تطبیق یک هنرمند متفاوتاند. وقتی هنرمند یکی را قطعی نکند، انتشارهای فارسی روی یک صفحه جمع میشوند و انتشارهای لاتین بین دو-سه صفحهٔ دیگر پخش میشوند، و جستوجو مجموعهای از کاتالوگهای ناقص برمیگرداند. هنرمند این را به شکل «آمارم کمتر از چیزی است که باید باشد» تجربه میکند و هرگز علتش را پیدا نمیکند، چون هر صفحه بهتنهایی سالم به نظر میرسد.
چگونه انتخاب کنیم، به ترتیب اولویت:
- هرچه هنرمند همین حالا علناً استفاده میکند — نام کاربری، دامنه، جلد آثار منتشرشده. سازگاری با ردپای موجود بر درستی زبانشناختی مقدم است.
- اگر چنین چیزی نیست، هرچه روی بزرگترین انتشار موجود هست.
- هرچه شنوندهٔ بازار هدف واقعاً تایپ میکند. رایج بر عالمانه مقدم است: نویسهگردانیهای دانشگاهی با نشانههای ویژه، درستاند و پیدانشدنی.
- یک تصمیم ثابت برای هر دوگانهٔ مبهم؛ یعنی برای این جفتها یکبار برای همیشه انتخاب کنید:
kh / x — gh / q — ou / u — ee / i — v / w
جایی که مدل داده اجازه میدهد، خط بومی در فیلد اصلی و آوانویسی در فیلد بومیسازی یا فیلد آوایی میرود — دقیقاً همان چیزی که راهنمای Apple برای سیریلیک تجویز میکند:
"Content in languages that use the Cyrillic alphabet should not be submitted with transliterated titles. Use Cyrillic in the native title field, English in the English localization field, and transliteration in the available phonetic field."
اگر توزیعکنندهٔ شما این فیلدها را در اختیار نمیگذارد، خطی را انتخاب کنید که مخاطبتان در آن جستوجو میکند و همانجا بمانید.
یک آوانویسی، نام دومِ قانونی شماست؛ و هنرمندی که یکی را انتخاب نکرده، عملاً چند تا انتخاب کرده است.
۱۲. شناسهها
شناسهٔ ضبط. کدِ ISRC دوازده نویسه است: دو نویسهٔ کشور، سه نویسهٔ ثبتکننده، دو رقم سال مرجع، و پنج رقم تخصیص. خط تیره فقط یک قرارداد نمایشی است و بخشی از کد نیست. و در این کد هیچ رقم کنترلی وجود ندارد.
این کد شناسهٔ ضبط است، نه آهنگ — که شناسهاش ISWC است — و نه محصول، که شناسهاش UPC است. هنگام تغییر توزیعکننده، کد با همان ضبط میماند.
کد تازه لازم است برای ریمیکس، ادیت، اجرای زنده و نسخهٔ بیکلام — یعنی هر ضبطی که ماهیتاً متفاوت باشد. برای بازنشرِ همان ضبط کد تازه لازم نیست.
دربارهٔ ریمستر، آنچه معمولاً گفته میشود دقیق نیست. کتابچهٔ راهنمای رسمیِ این شناسه، که IFPI منتشر میکند، در بند A.10.1 میگوید:
"A new ISRC shall be assigned if (and only if) the processes applied to a recording during re-mastering involve the application of creative input to the recording itself."
و صراحتاً اینها را مستثنا میکند: تغییر سادهٔ سطح، اکولایزِ ثابت، فشردهسازی ثابت، حذف نویز، حذف کلیک، تصحیح سرعت و زیروبمی، تغییر نرخ نمونهبرداری و دیترینگ:
"A new ISRC shall not be assigned in the context of essentially invariant or technological adjustment processes."
پس «هر ریمستری کد تازه میخواهد» غلط است. قید عملی و امنی که میتوان گفت این است: اگر ریمستر بهعنوان یک ترک جداگانه کنار نسخهٔ اصلی فروخته میشود، محصول جداگانهای است و کد خودش را میخواهد.
شناسهٔ محصول. کدِ UPC/EAN شناسهٔ محصول است، نه ضبط. قالبِ UPC-A دوازده رقم و قالبِ EAN-13 سیزده رقم دارد؛ با افزودن یک صفر به ابتدای اولی، دومی به دست میآید و رقم کنترلی تغییر نمیکند.
الگوریتم رقم کنترلی: از راست، ارقامِ پیش از رقم کنترلی را یکدرمیان در ۳ و ۱ ضرب کنید و جمع بزنید؛ رقم کنترلی عددی است که مجموع را به مضرب بعدیِ ۱۰ میرساند.
۱۳. آهنگساز، ترانهسرا و سهمها: جایی که پول نشر گم میشود
ضبط و اثر دو حق جدا با دو جریان درآمد جدا هستند. توزیعکننده روی ضبط وصول میکند؛ سمت نشر — حقالامتیاز مکانیکی و اجرای عمومی روی اثر — از مسیر فیلدهای آهنگساز و ترانهسرا و ثبتهای بعدی ردیابی میشود.
اینها ضعیفترین حلقهٔ انتشارهای مستقلاند، به یک دلیل ساختاری: هرگز در نمای بیرونی فروشگاه دیده نمیشوند. انتشاری با فیلد آهنگساز خالی، بینقص به نظر میرسد و عادی پخش میشود، در حالی که حقالامتیاز نشرش تطبیقنیافته میماند.
- آهنگساز و ترانهسرا نام حقوقی میخواهند، نه نام هنری. جوامع حقوقی روی نام ثبتشدهٔ نویسنده تطبیق میدهند.
- همهٔ نویسندگان باید ثبت شوند، حتی کسی که یک مصرع نوشته. نویسندهٔ ازقلمافتاده یعنی سهمِ تطبیقنیافته، نه صرفاً کردیتِ ازدسترفته.
- جمع سهمها باید ۱۰۰٪ شود و پیش از انتشار مکتوب توافق شده باشد. متادیتا بیانِ یک توافق است؛ بدون توافق، حدسی است که بعداً محل نزاع میشود.
- تنظیمِ آثار قدیمی و عمومی هم نویسنده دارد — یعنی تنظیمکننده. این نکته برای موسیقی ایرانی جدی است: تنظیم یک تصنیف قدیمی یا اجرای یک گوشه از ردیف، اگر یکسره بهعنوان «سنتی» ثبت شود، درآمد تنظیم را از دست میدهد. جایی که اثر پایه در مالکیت عمومی است، تنظیمکننده باید ثبت شود.
- ریمیکس، آهنگ را عوض نمیکند. نویسندگان اصلی همان میمانند، مگر ریمیکس ملودی یا شعر تازه بیفزاید، که آن هم سهمی مذاکرهشده است، نه یک فرض.
حقالامتیاز ضبط با سروصدا خراب میشود و حقالامتیاز نشر بیصدا: صفحهٔ هنرمندِ شکسته را ظرف یک روز میبینید، اثرِ تطبیقنیافته میتواند سالها دیده نشود.
۱۴. چه چیزهایی انتشار را رد میکند
- نام هنرمند داخل فیلد عنوان — توکنهای
ft. / feat. / with یا نام ریمیکسر در عنوان، در حالی که فیلد نقش خالی است.
- کلمهٔ محتوای صریح یا پاک در عنوان — یعنی نوشتنِ
(Explicit) یا (Clean) در عنوان. از پرچم استفاده کنید؛ راهنماهای Apple و Music Biz شکل متنی را ممنوع کردهاند.
- متن تبلیغاتی یا توصیفی در عنوان — عبارتهایی مثل
Exclusive, Limited Edition, Album Version, Original Mix یا ادعاهای فرمت مثل Dolby Atmos و lossless.
- تخلف در حالت حروف — همهبزرگ یا همهکوچک در عنوانهای لاتین، مگر انتخاب هنری واقعی و پایدار باشد.
- ناهماهنگی متادیتا با طرح جلد — عنوان، نام هنرمند و نسخه روی جلد باید با فیلدها یکی باشند. انتشارهای فارسی این بند را بیش از حد معمول رد میگیرند، چون جلد معمولاً با یک قلم نمایشی و اغلب با کشیده حروفچینی شده و فیلد از روی همان بازتایپ شده است.
- فیلد زبانِ غلط یا خالی، بهویژه زبان عنوان در انتشارهای غیرلاتین.
- نبود آهنگساز یا ترانهسرا، که بعضی مقصدها یکسره رد میکنند.
- نویسههای ممنوع — ایموجی، نمادهای تزئینی، فاصلهٔ دوتایی، نویسههای نامرئی سرگردان؛ کشیده هم اینجاست.
- شناسهٔ غلط — کدِ ضبطِ بازاستفادهشده روی ضبطی ماهیتاً متفاوت، یا کد محصولی که رقم کنترلیاش نمیخواند.
- نام هنرمندی ناسازگار با کاتالوگ موجود — که اغلب اصلاً رد نمیشود، و دقیقاً به همین دلیل پرخسارتترین قلم این فهرست است.
چکلیست پیش از تحویل، مخصوص فارسی
- [ ] نام هنرمند را چسباندهام، نه تایپ کرده.
- [ ] در همهٔ فیلدها دنبال «ي» و «ك» عربی گشتهام؛ شمارش صفر است.
- [ ] نیمفاصلهها در جای درستاند و تعدادشان با نسخهٔ مرجع میخواند.
- [ ] یک مجموعهٔ رقم انتخاب کردهام؛ رقم عربی در هیچ فیلدی نیست.
- [ ] هیچ کشیدهای در هیچ فیلدی نمانده است.
- [ ] اعراب فقط جایی هست که عمداً خواستهام.
- [ ] املای کسرهٔ اضافه در کل کاتالوگ یکسان است.
- [ ] رشتهها به شکل ترکیبشده نرمال شدهاند.
- [ ] عنوانها فقط نام قطعهاند؛ هیچ نام هنرمند و هیچ توکن مهمانی در آنها نیست.
- [ ] هر نقش فیلد دارد و هر فیلد نقش دارد.
- [ ] زبان اثر و زبان عنوان هر دو تنظیم شدهاند.
- [ ] خطِ ℗ و خطِ © جدا و درستاند.
- [ ] اگر بازنشر است، تاریخ انتشار اصلی وارد شده.
- [ ] جلد را نویسهبهنویسه با فیلدها مقایسه کردهام.
هر ردی که میگیرید ارزان است؛ خطاهایی که از اعتبارسنجی رد میشوند گراناند.
۱۵. یک نکته دربارهٔ ابزار، و دربارهٔ آنچه اندازهگیری نشده
ابزار بررسی متادیتای مازوفا رایگان است، کاملاً روی دستگاه خودتان اجرا میشود و هیچ فایلی آپلود نمیشود؛ چند مورد از حالتهای نامرئی بالا را علامت میزند: اختلاط مجموعههای رقم، کشیده، نیمفاصلهٔ گمشده یا اضافه، ی و ک عربی در متن فارسی، و رشتههایی که به شکل ترکیبشده نرمال نشدهاند. انتشار در آن رایگان است، تنها کسر آن ۵٪ از حقالامتیاز دریافتی است، و هر درخواست کاملِ عضویت را انسان بررسی میکند.
و یک صداقت لازم: تا جایی که ما میدانیم، هیچ اندازهگیری منتشرشدهای از نرخ خطای متادیتای خط عربی-فارسی در هیچجای صنعت وجود ندارد. این مسئله را همه تجربه کردهاند و هیچکس کمّیاش نکرده است. هر عددی که در این باره ببینید — از جمله از ما — تا وقتی منبع اولیه ندارد، حدس است.
به همین ترتیب، سه چیز که مرتب به هنرمندان بهعنوان واقعیت گفته میشود و هیچ سرویسی منتشر نکرده است، اینجا هم ادعا نشدهاند: آستانهها و مدارک لازم برای ادغام صفحهٔ هنرمند؛ منطق داخلیِ تطبیق که تصمیم میگیرد یک تحویل به هویت موجود بپیوندد یا هویت تازه بسازد؛ و — بیرون از ممنوعیت صریحِ Apple — رفتار هر فروشگاه با برچسبِ نسخهٔ اصلی.
۱۶. جمعبندی
- متادیتا در سه لایه ثبت میشود — محصول، ضبط، اثر — و بیشتر خطاهای گران، اطلاعاتیاند که در لایهٔ اشتباه ثبت شدهاند. نام هنرمند یک کلید است، نه یک برچسب؛ نقشها هویتاند و عنوانها نمایش.
- در خط فارسی، رشتهٔ بایت و نمایش، مستقل از هم خراب میشوند و چشم هیچکدام را ممیزی نمیکند. ی و ک عربی، نیمفاصلهٔ حذفشده، ارقام عربی بهجای فارسی، املای کسرهٔ اضافه، کشیده، اعراب و اختلاف شکلهای نرمال — هرکدام بهتنهایی یک هنرمند را نامرئی به دو هنرمند تبدیل میکنند.
- یک آوانویسی لاتین انتخاب کنید و با آن مثل نام دومِ قانونی رفتار کنید.
- آهنگساز و ترانهسرا مسیر پول نشرند و بدون هیچ علامتی از کار میافتند.
منابع
فهرست زیر همان منابع اولیهای است که نقلقولهای این متن از آنها آمده است.
- Unicode Standard Annex #9, Unicode Bidirectional Algorithm
https://www.unicode.org/reports/tr9/
- Unicode Standard Annex #15, Unicode Normalization Forms
https://www.unicode.org/reports/tr15/
- Unicode Character Database
ویژگیهای نویسه، شامل کلاس دوسویه و نگاشت تجزیه
- Music Business Association, Music Metadata Style Guide
https://www.musicbiz.org/wp-content/uploads/2016/04/MusicMetadataStyleGuide_V2.1.pdf
- Apple Music Style Guide
https://help.apple.com/itc/musicstyleguide/en.lproj/static.html
- Spotify for Artists, Music metadata guidelines
https://support.spotify.com/us/artists/article/metadata-formatting-guidelines/
- Spotify Provider Support, Featured artist in a product or track title
https://providersupport.spotify.com/article/featured-artist-in-a-product-or-track-title
- IFPI, ISRC Handbook
بندِ A.10.1 دربارهٔ ریمستر
- DDEX, Standards
شامل مجموعهپیامهای اعلان انتشار الکترونیکی