Müzik Künyesi (Metadata): Sanatçı Adı, Şarkı Adı, Konuk Sanatçı ve Türkçe Metin Dağıtım Zincirinden Bozulmadan Geçsin Diye Teknik Referans

Türkçe karakter kümesi, noktasız ı / noktalı İ sorunu ve makam–tür sözlüğü tam olarak ele alınmıştır.

Kısa cevap

Künye, müziğin yanına iliştirilen evrak değildir; zincirin geri kalanı için müziğin kendisidir — hiçbir servis kaydınızı dinlemez, teslimatınızı okur. Sanatçı adını her yayında bayt bayt aynı yazın (yeniden yazmayın, kopyalayıp yapıştırın), konuk sanatçıyı başlığa değil kendi rol alanına girin, versiyon bilgisini versiyon alanında tutun, besteci ve söz yazarını gerçek adlarıyla doldurun. Türkçeye özgü asıl tehlike, dağıtım zincirindeki bir sistemin metninizi yerel ayardan habersiz büyük/küçük harfe çevirmesidir: "İSTANBUL" ham toLowerCase() çağrısında i̇stanbul (U+0069 + U+0307) olur, "IŞIK" ise işik olur — bu, gerçek kataloglarda gerçekten yaşanmış bir üretim hatasıdır ve düzeltilmesi teslimattan önceki on dakikadan sonra neredeyse imkânsızdır. İkinci tehlike ASCII katlamadır: ç ş ğ ü ö ı sadeleştirildiğinde birbirinden bağımsız iki Türk sanatçı adı aynı dizgeye düşer ve tek sayfada birleşir ya da tek sanatçı iki sayfaya bölünür. Bunların hepsi teslimattan önce ücretsiz, sonra ise dosya açıp umut etmekle çözülür.

1. Hangi alan neyi belirler

Bir yayın tek bir nesne değil, üç katmanlı bir hiyerarşidir: yayın (ürün) içinde kayıtlar (parçalar), her kaydın içinde bir ya da daha fazla eser (beste) vardır. Her katmanın kendi kimlik numarası ve kendi parası vardır: yayın için UPC/EAN, kayıt için ISRC, eser için ISWC. Pahalıya patlayan künye hatalarının hemen tamamı, doğru bilginin yanlış katmana yazılmasıdır. Taşıma katmanı standarttır: bir yayının servise ulaşma biçimi DDEX'in ERN (Electronic Release Notification Message Suite) mesaj takımıdır.

Ana sanatçı (primary artist). Kaydın hangi sanatçı sayfasına düşeceğini, dinleyici sayısının, takipçilerin ve algoritmik geçmişin kime yazılacağını yalnızca bu alan belirler. Spotify'ın açık yönergesi nettir: "List each artist's name in a separate field." — her sanatçının adı ayrı bir alana.

Konuk sanatçı (featured artist). Aynı kayıt üzerinde ayrı bir roldür; konuk sanatçıyı kendi sayfasına bağlar ama ana faturalandırmayı ona vermez. Apple'ın üslup kılavuzu konuk sanatçının parça düzeyinde Featuring ya da With rolüyle girilmesini, "not as Primary" — ana sanatçı olarak değil — diye şart koşar.

Remixçi (remixer). O da bir roldür. Apple: "Remix tracks...must list the original artist as Primary with the remixer assigned the remixer role." Remixçiyi ana sanatçı alanına yazmak, remix kataloglarının bir sanatçının sayfasını kirletmesinin tek sebebidir.

Besteci ve söz yazarı. Bunlar eseri tarif eder, kaydı değil; yayıncılık (publishing) ve mekanik telifin izi bu alanlardan sürülür.

Prodüktör. Katkı rolüdür: künyede görünür, kayıt tarafında ödeme üretmez.

Versiyon / alt başlık. Aynı adı taşıyan iki kaydı birbirinden ayıran parantez içi bilgi: Live, Instrumental, Radio Edit (bölüm 6).

Explicit bayrağı. Kelime değil, boole değeridir. Apple: "Explicit content must be flagged Explicit with a parental advisory tag. Terms like (Explicit)...must not be used for album...or track titles." Spotify de aynı yerde: "you shouldn't add it to your track title." Music Biz kılavuzu tersini de yasaklar: başlığa "Clean" ya da "Temiz" yazılmaz.

Eserin dili (ne söyleniyor) ile başlığın dili (başlık dizgesinin dili ve yazı sistemi) ayrı alanlardır ve meşru biçimde farklı olabilir: Türkçe adlı bir enstrümantal taksimin şarkı sözü dili yoktur ama başlık dili Türkçedir. Başlık dili alanı, mağazaya metninizi nasıl sıralayacağını, dizinleyeceğini ve — Türkçe için kritik — hangi yerel ayara göre harf dönüşümü yapacağını söyleyen alandır. Türkçe yayınlarda boş bırakılan ya da yanlış doldurulan başlık dili, bölüm 4'te anlatılan hatanın en yaygın tetikleyicisidir.

P-line: yıl + ses kaydının hak sahibi; yıl, o kaydın ilk yayımlandığı yıldır, sizin yükleme tarihiniz değil. C-line: yıl + kapak görseli ve ambalajın hak sahibi. Birbirinin yerine geçmez, ama sürekli birbirine kopyalanır.

Tür (genre). Zevkinizin tarifi değil, bir yönlendirme sinyalidir; yayının hangi editoryal ve algoritmik bağlamlara aday olacağını belirler (bölüm 7).

Yayın tarihi bu ürünün yayına gireceği tarihtir; orijinal yayın tarihi kaydın herhangi bir yerde ilk kez yayımlandığı tarihtir. 2003'te çıkmış bir kaydı orijinal yayın tarihi 2026 olarak teslim etmek, zincirdeki bütün sistemlere "bu yeni bir kayıt" demektir.

Kimlik numaraları, tam olarak. ISRC on iki karakterdir: iki karakter ülke (Türkiye için TR), üç karakter kayıt sahibi (registrant), iki karakter referans yılı, beş karakter tayin numarası. Tirelerin kodun kendisiyle ilgisi yoktur, yalnızca gösterim geleneğidir; ISRC'de kontrol hanesi yoktur. UPC-A on iki, EAN-13 on üç hanedir; başa bir sıfır eklemek birini diğerine çevirir ve kontrol hanesi değişmez. Kontrol hanesi şöyle hesaplanır: sağdan başlayarak kontrol hanesinden önceki rakamlara sırayla ×3 ve ×1 uygulanır, toplanır, kontrol hanesi toplamı bir sonraki 10 katına tamamlayan rakamdır.

ISRC kaydı tanımlar — şarkıyı değil (o ISWC'dir), yayını değil (o UPC'dir) — ve dağıtımcı değiştirdiğinizde kayıtla birlikte kalır. Yeni bir ISRC gerektiren durumlar: remix, edit, canlı versiyon, enstrümantal — kısacası maddi olarak farklı her kayıt. Aynı kaydın yeniden yayımlanması yeni ISRC gerektirmez.

Remaster konusunda yaygın anlatım yanlıştır. IFPI ISRC Handbook §A.10.1 şunu söyler: "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." Kılavuz, basit seviye değişikliğini, sabit EQ'yu, sabit kompresyonu, gürültü/çıtırtı temizliğini, hız/perde düzeltmesini, örnekleme frekansı değişimini ve dither'ı açıkça dışarıda bırakır: "A new ISRC shall not be assigned in the context of essentially invariant or technological adjustment processes." Yani "her remaster yeni ISRC ister" cümlesi doğru değildir. Güvenle söylenebilecek pratik kural şudur: remaster, orijinalin yanında ayrı bir ürün olarak satılıyorsa ayrı bir üründür ve kendi kodunu ister.

Bir bilginin yayın mı, kayıt mı, eser mi olduğunu söyleyemiyorsanız, o bilgiyi henüz doğru dolduramazsınız.

2. Sanatçı adı: en pahalı küçük hata

Bir mağaza için sanatçı adı metin değil, anahtardır. Teslimat geldiğinde eşleştirme mantığı ya bu dizgeyi mevcut bir kimliğe bağlar ya da yeni bir kimlik açar; güveni düşüren her şey — farklı bir yazım, farklı bir aksan, fazladan bir boşluk, aynı harfin farklı bayt dizisi — terazi kolunu "yeni kimlik" tarafına iter.

Sonuç: bir sanatçı iki olur. Katalog bölünür, dinlenmeler bölünür, takipçiler ikinci kimliğe taşınmaz ve o kimlik sıfır algoritmik geçmişle hayata başlar. Telif yine ödenir, ama iki ayrı birikim geçmişi üzerinden; katalog düzeyinde ölçülen her şey — editoryal değerlendirme, analitik, doğrulama — kariyerin yarısı üzerinden ölçülür.

İki büyük üslup referansı da aynı şeyi söyler. Music Biz: "Artist name spelling should remain consistent for all content for an artist, where possible." Spotify: yayından yayına yazımı ve biçimi aynı tutun, "including any punctuation, abbreviations, or acronyms."

Türkçede bu hatanın kaynakları sıradandır ve tam da bu yüzden gözden kaçar: bir yayında Şebnem, ötekinde Sebnem; bir yayında Rüzgâr, ötekinde Rüzgar; bir yayında İstanbul'da, ötekinde İstanbul’da (farklı kesme işareti); bir yayında Gökçe, ötekinde GÖKÇE; klavye düzeni Q ile F arasında değiştiğinde kaçan bir düzeltme işareti. Hiçbiri yazım hatası gibi görünmez, hepsi ayrı bir anahtardır.

Sonradan düzeltmek bir "düzenleme" değil, bir birleştirme talebidir: dağıtımcınız her mağazadan iki kimliği birleştirmesini ister, her mağaza bunu kendi kuyruğunda ve kendi kanıt eşiğiyle ele alır, bazıları hızlı çözer, bazıları hiç çözmez. Bölünmüş sanatçı sayfası düzelttiğiniz bir hata değil, açtığınız bir dosyadır.

Savunma tek cümledir: kanonik adı bir kez yazın, bir dosyaya kaydedin ve bundan sonra her teslimata yapıştırın. Varyantlar yeniden yazma anında doğar.

3. Türkçe karakter kümesi: neyi teslim ettiğinizi tam olarak bilin

Türkçe Latin alfabesi kullanır; bu, metnin sorunsuz taşındığı anlamına gelmez. Türkçeye özgü altı harfin kod noktaları şunlardır ve teslimattan önce hangi kod noktasını gönderdiğinizi bilmek zorundasınız:

Türkçe alfabede ı ve i ayrı harflerdir, aksanlı varyantlar değil. ı (U+0131) hiçbir normalleştirme biçiminde parçalanmaz; kendi başına bir harftir. İ (U+0130) ise kanonik olarak I + birleşen üstteki noktaya (U+0307) ayrışır — bu, bölüm 3.3'teki hatanın teknik kökenidir.

3.1 Noktasız i / noktalı İ: Unicode'un dile duyarlı harf dönüşümü kuralı

Unicode'da büyük/küçük harf dönüşümü çoğu harf için dilden bağımsızdır. Üç dil bunun istisnasıdır ve bunlardan ikisi Türkçe ve Azericedir. Unicode Karakter Veritabanı'ndaki SpecialCasing.txt dosyası bu istisnayı açıkça belirtir. Dosyanın kendi yorum satırı şudur:

# Turkish and Azeri # I and i-dotless; I-dot and i are case pairs in Turkish and Azeri # The following rules handle those cases. — Unicode Character Database, SpecialCasing-17.0.0.txt (2025-07-31)

Ardından gelen veri satırları kuralı tam olarak verir:

0130; 0069; 0130; 0130; tr; # LATIN CAPITAL LETTER I WITH DOT ABOVE 0049; 0131; 0049; 0049; tr Not_Before_Dot; # LATIN CAPITAL LETTER I 0069; 0069; 0130; 0130; tr; # LATIN SMALL LETTER I

Türkçe okunuşuyla: tr yerel ayarında İ küçültülünce i olur; I küçültülünce ı olur; i büyütülünce İ olur. (ı → I eşlemesi zaten UnicodeData.txt içindedir, dosya bunu ayrıca not düşer.)

Kritik olan, aynı dosyanın yerel ayar belirtilmemiş hâlinde ne yazdığıdır:

0130; 0069 0307; 0130; 0130; # LATIN CAPITAL LETTER I WITH DOT ABOVE

Yani tr etiketi yokken İ (U+0130), tek bir i harfine değil, iki kod noktasına — U+0069 + U+0307 COMBINING DOT ABOVE — küçülür. Bu bir hata değil, standardın kanonik denkliği koruma yöntemidir: İ zaten I + üstteki nokta olarak ayrıştığı için, küçültülmüş hâli de noktayı ayrı bir birleşen karakter olarak taşımak zorundadır.

3.2 Aynı sorunun ikinci yarısı: I her zaman i değildir

Yerel ayar belirtilmemiş dönüşümde I (U+0049) → i (U+0069) olur; Türkçede ise I → ı (U+0131) olmalıdır. Sonuç, Türkçe metinde asimetrik bir bozulmadır:

• "ışık" büyütülür → "IŞIK" (her iki yerel ayarda da doğru görünür)
• "IŞIK" yerel ayarsız küçültülür → "işik" (Türkçesi "ışık" olmalıydı)

Yani büyütme yönü sorunsuz görünür, küçültme yönü metni yok eder. Kapak görselinde büyük harfle yazdığınız için alanları da büyük harfle doldurduysanız ve zincirdeki herhangi bir sistem "başlıklar tümü büyük harf olmasın" kuralı gereği küçültme uyguluyorsa, IŞIK adlı albümünüz Işık değil İşik olarak çıkar.

3.3 Üretimde gerçekten olan hata

Bu, teorik bir kenar durum değildir; gerçek katalogları bozmuş bir üretim hatasıdır ve iki yönde birden çalışır.

Birinci yön — tr yerel ayarı unutulur. Dağıtım zincirindeki bir bileşen (dağıtımcının doğrulayıcısı, bir toplayıcının içe aktarma betiği, bir mağazanın arama dizini, hatta bir DDEX ERN dönüştürücüsü) toLowerCase() çağrısını yerel ayar vermeden yapar:

"İSTANBUL".toLowerCase()   →  "i̇stanbul"     (U+0069 U+0307 s t a n b u l)
"İSTANBUL".toLowerCase(tr) →  "istanbul"      (doğru)

Ekranda görünen fark, i harfinin üzerinde iki noktalı bir şey olmasıdır — i̇. Çoğu yazı tipinde bu, sıkışık bir "i" gibi görünür ve gözle denetlenemez. Ama dizge artık dokuz değil on kod noktası uzunluğundadır ve "istanbul" ile hiçbir karşılaştırmada eşleşmez. Aranmaz, sıralanmaz, birleşmez.

İkinci yön — tr yerel ayarı beklenmedik yerde vardır. Sunucusu Türkiye'de kurulmuş, sistem yerel ayarı tr_TR olan bir makinede çalışan aynı kod, bu kez İngilizce dizgeleri bozar:

"INSTRUMENTAL".toLowerCase()  →  "ınstrumental"   (tr_TR yerel ayarında)
"Radio Edit".toUpperCase()    →  "RADİO EDİT"     (tr_TR yerel ayarında)
"ISRC".toLowerCase()          →  "ısrc"

Bu, Java dünyasında yıllardır bilinen klasik hatadır: String.toLowerCase() argümansız çağrıldığında JVM'in varsayılan yerel ayarını kullanır, o da makinenin yerel ayarıdır. Aynı kod Frankfurt'ta doğru, İstanbul'daki yedek sunucuda yanlış çalışır — ve hata, ancak katalog teslim edildikten sonra fark edilir.

Uygulamada bilinmesi gerekenler:

• Java: toLowerCase() yerine her zaman toLowerCase(Locale.ROOT) veya toLowerCase(new Locale("tr")) — hangisini istediğinize karar verin, ama açıkça yazın.
• JavaScript: String.prototype.toLocaleLowerCase("tr") Türkçe kuralını uygular; düz toLowerCase() uygulamaz.
• Python: str.lower() ve str.upper() hiç yerel ayar desteklemez; kök eşlemeleri uygular. "İSTANBUL".lower() Python'da her zaman i̇stanbul verir. Python tabanlı bir teslimat hattı, ek bir kütüphane (örneğin PyICU) olmadan Türkçe harf dönüşümü yapamaz — bunu "yapabiliyor" varsaymak yaygın bir yanılgıdır.
• PostgreSQL: lower() ve upper() veritabanının derleme (collation) ayarına bağlıdır. Aynı teslimat, iki farklı collation ile kurulmuş iki sunucuda farklı sonuç verir.
• ICU/CLDR: doğru davranışı garanti eden tek yaygın yol, dönüşümü ICU'ya yerel ayar vererek yaptırmaktır.

Pratik sonuç — künye tarafında ne yapmalı: teslimat alanlarında büyük/küçük harf dönüşümüne hiç güvenmeyin. Sanatçı adını ve başlıkları, yayımlanmasını istediğiniz tam biçimde girin; tümü büyük harf yazmayın (zaten üslup kılavuzları da yasaklıyor, bölüm 8); başlık dili alanını Türkçe olarak doldurun ki dönüşüm yapan sistemlerin doğru yerel ayarı seçme şansı olsun; ve yayın çıktıktan sonra kendi başlığınızı mağazalarda arayarak kontrol edin — İşik ile Işık arasındaki farkı gözünüz değil, arama kutusu gösterir.

Bir kontrol daha: dizgenizde U+0307 (COMBINING DOT ABOVE) varsa, neredeyse kesinlikle bu hatanın kurbanı olmuşsunuzdur. Türkçe metinde bu karakterin bulunması için meşru bir sebep yoktur.

3.4 Turna dönüşü: İ → I → ı ve geri dönüşü olmayan bilgi kaybı

Diyarbakır sözcüğü tek başına bu sorunun tam haritasıdır:

"Diyarbakır".toUpperCase()  →  "DIYARBAKIR"    (hem kök hem tr yerel ayarında)
"DIYARBAKIR".toLowerCase(tr) →  "dıyarbakır"    (ilk "ı" artık yanlış)
"DIYARBAKIR".toLowerCase()   →  "diyarbakir"    (son "ı" artık yanlış)

Büyük harfe çevirme, i ile ı arasındaki ayrımı kalıcı olarak yok eder: her ikisi de I olur (Türkçe yerel ayarında i → İ olduğu için bu yönde bilgi korunur, ama kök yerel ayarında korunmaz). Geri dönüşte hangi harfin hangisi olduğunu bilecek bilgi kalmamıştır. Bu yüzden tümü büyük harf yazılmış Türkçe bir başlık, tersine çevrilemez bir kayıptır. Kapak görselinizde İÇİMDEKİ FIRTINA yazması sorun değildir; künye alanına İçimdeki Fırtına yazın.

3.5 ASCII katlama: ç ş ğ ü ö ı sadeleşince ne oluyor

Arama dizinleri, URL/slug üreticileri, eski CMS'ler, bazı raporlama araçları ve dağıtımcıların bazı iç doğrulayıcıları Türkçe harfleri ASCII karşılıklarına katlar (folding): ç→c, ş→s, ğ→g, ü→u, ö→o, ı→i, İ→i, â→a.

Katlama, tek yönlü bir işlemdir ve iki ayrı zarar üretir.

Zarar 1 — bir sanatçı iki olur. Şebnem ve Sebnem, Gökçe ve Gokce, Uğur ve Ugur, Öztürk ve Ozturk farklı dizgelerdir. Sanatçı bir yayında Türkçe harflerle, sonrakinde ASCII ile teslim ederse iki sayfa oluşur ve hiçbiri diğerini bulmaz.

Zarar 2 — iki sanatçı bir olur. Bu daha az bilinir ve daha az düzeltilebilir. Türkçede katlandığında çakışan gerçek ad çiftleri vardır:

• Şen ve Sen — ikisi de gerçek soyadıdır; katlanınca ikisi de Sen.
• Çan ve Can — Can çok yaygın bir addır, Çan Çanakkale'nin ilçesidir; katlanınca ikisi de Can.
• Öz ve Oz — katlanınca ikisi de Oz.
• Sıla ve Sila — katlanınca ikisi de Sila.
• Gül ve Gul, Şahin ve Sahin, Çelik ve Celik — aynı biçimde.

Bir arama dizini bu ikisini aynı anahtara indirdiğinde, bir sanatçının dinleyicisi diğerinin sayfasına düşer; bu, birleştirme talebiyle çözülmez, çünkü iki kimlik gerçekten farklıdır.

Zarar 3 — anlam değişir, bazen kötü yönde. Katlama, Türkçede anlamı taşıyan bir ayrımı siler: şık (zarif) ve sık (sıkı/sık) katlandığında aynı ASCII dizgeye düşer ve ortaya çıkan biçim Türkçede kaba bir kelimeyle çakışır. kar (kar yağışı) ile kâr (kazanç), hala (teyze/hala) ile hâlâ (henüz), adet (sayı) ile âdet (gelenek) aynı sınıftadır. Bir başlığı ASCII'ye indirgemek, bazen onu farklı bir başlık yapar.

Kural: Türkçe harflerle mi ASCII ile mi yayımlayacağınıza bir kez karar verin ve kataloğun tamamında ona sadık kalın. Doğru olanı Türkçe harflerdir; dinleyici Türkçe klavyeyle arar ve mağazaların arama katmanları genellikle katlamayı kendileri yapar. Kendi elinizle katlamayın — mağazanın katlaması sizin lehinize çalışır, sizin katlamanız sizin aleyhinize.

3.6 Düzeltme işareti (â, î, û): aynı şarkının iki adı

Türkçede düzeltme işareti modern imlada büyük ölçüde seçimliktir ve tam da bu yüzden künye açısından tehlikelidir: aynı sözcük iki meşru yazımla dolaşır.

• Rüzgâr / Rüzgar
• Lâle / Lale
• Elâzığ / Elazığ
• Kâğıt / Kağıt

Makam adlarında bu doğrudan başlık alanına girer: Segâh / Segah, Kürdilihicazkâr / Kürdilihicazkar, Nikriz — bir fasıl albümünün parça listesinde iki farklı yazımın yan yana durması sıradan bir manzaradır. Aynı sanatçının iki albümünde iki farklı yazım varsa, iki farklı başlık vardır; aynı albümün içinde iki farklı yazım varsa, tutarsız bir künye vardır.

Kural: düzeltme işaretini kullanın ya da kullanmayın — ama katalog boyunca aynı kararı verin ve kararı yazılı tutun.

3.7 Kesme işareti: Türkçenin en sessiz bölücüsü

Türkçe imlada özel adlara gelen çekim ekleri kesme işaretiyle ayrılır: İstanbul'da, Ankara'ya, Barış'ın, Anadolu'nun. Bu, Türkçe şarkı adlarında son derece yaygındır — ve kesme işareti diye tek bir karakter yoktur:

• ' U+0027 APOSTROPHE (klavyedeki düz tırnak)
• ’ U+2019 RIGHT SINGLE QUOTATION MARK (kelime işlemcilerin otomatik dönüştürdüğü tipografik apostrof)
• ´ U+00B4 ACUTE ACCENT (yanlışlıkla basılan)
• ʼ U+02BC MODIFIER LETTER APOSTROPHE

İstanbul'da Sonbahar ile İstanbul’da Sonbahar gözle ayırt edilemez ve aynı dizge değildir. Word'de yazıp panoya kopyalanan bir parça listesi otomatik olarak U+2019'a dönüşür; doğrudan forma yazılan aynı ad U+0027 kalır. Aynı albümün yarısı bir karakterle, yarısı diğeriyle teslim edilir.

Kural: kesme işareti olarak U+0027 (düz apostrof) kullanın ve teslim etmeden önce metni bir düz metin düzenleyicisinden geçirin. Kelime işlemciden forma doğrudan yapıştırmayın.

3.8 Benzeşen harfler: Türkçe ş ile Romence ș

Türkçe ş harfi çengelli (cedilla) bir s'dir: ş U+015F / Ş U+015E. Romence ise virgüllü (comma below) s kullanır: ș U+0219 / Ș U+0218. Pek çok yazı tipinde bu ikisi neredeyse ayırt edilemez; bazı yazı tiplerinde tamamen aynı çizilir.

Bu karışıklık kazara değildir: eski kod sayfalarında Romence de çengelli biçimi kullanıyordu ve Unicode ayrı kod noktaları tanımladıktan sonra bile pek çok yazı tipi, klavye düzeni ve dönüştürücü ikisini karıştırmaya devam etti. Sonuç: Romence bir klavyeden ya da eski bir Romence yazı tipiyle hazırlanmış bir metinden kopyalanan Șebnem, Türkçe Şebnem ile aynı görünür ve farklı bir sanatçıdır.

Aynı sınıfta: ğ (U+011F, breve) ile karıştırılan ǧ (U+01E7, caron), ve bazı dönüştürücülerin ı (U+0131) yerine kullandığı ɪ (U+026A, küçük büyük harf I). Bunların hiçbirinin Türkçe künyede yeri yoktur.

3.9 NFC / NFD: aynı ad, iki farklı bayt dizisi

Unicode Standard Annex #15 (Unicode Normalization Forms) dört normalleştirme biçimi tanımlar; burada önemli olan ikisi NFC (birleşik) ve NFD (taban harf + ayrı birleşen işaret).

Türkçenin ç ş ğ ü ö â harflerinin hepsi NFD altında ikiye ayrışır (yukarıdaki tabloya bakın). Yani Gökçe adı, ürettiği yazılıma göre ya beş kod noktası (NFC) ya da yedi kod noktası (NFD) olabilir. Ekranda tıpatıp aynıdır; bayt uzunluğu farklıdır; karşılaştırma sonucu farklıdır. Bu, macOS'ta hazırlanan dosya adlarında ve bazı formlarda düzenli olarak yaşanır.

Türkçeye özgü ek bir ayrıntı: ı (U+0131) ayrışmaz, ama İ (U+0130) ayrışır. Yani NFD uygulanmış bir Türkçe metinde, büyük İ harflerinin her biri zaten I + U+0307 hâline gelmiştir — ve bölüm 3.3'teki hatayla birleştiğinde ortaya çıkan dizge iki farklı yoldan aynı bozulmuş hâle ulaşır.

Kural: teslimattan önce bütün metin alanlarını NFC'ye normalleştirin, tek biçimde. UAX #15, uyumluluk biçimlerinin (NFKC/NFKD) her derde deva sanılmasına karşı uyarır: NFKC "erase[s] many formatting distinctions" ve "may remove distinctions that are important to the semantics." NFC yeterlidir ve güvenlidir.

Şunu da unutmayın: normalleştirme bir temizleyici değildir. NFC, yanlış yerel ayarla küçültülmüş bir i̇ dizisini geri getirmez (aslında NFC onu İ olarak birleştirebilir ve hatayı görünmez kılabilir), Romence ș'yi Türkçe ş yapmaz, kesme işaretini standartlaştırmaz.

3.10 Eski kodlama artıkları (mojibake)

Türkiye'de 2000'lerin başına kadar hâkim kodlama ISO 8859-9 (Latin-5) ve Windows-1254 idi. Bu dönemden gelen metinler — eski katalog dosyaları, eski web sitelerinden kopyalanan parça listeleri, eski veritabanı dökümleri — hâlâ dolaşımdadır ve yanlış yorumlandıklarında tanınabilir izler bırakır:

• Latin-5 metin, Latin-1 olarak okunursa: Şarkı → Þarký (Ş=0xDE→Þ, ı=0xFD→ý). Aynı biçimde ğ → ð, İ → Ý, Ğ → Ð.
• UTF-8 metin, Windows-1252 olarak okunursa: Şarkı → Şarkı (Ş = C5 9E, ı = C4 B1).

Bu dizgelerden birini gördüğünüz anda metin bozulmuştur ve elle düzeltilmemelidir; kaynağa dönüp doğru kodlamayla yeniden okunmalıdır. Bozuk metni "düzeltmek" için harfleri tek tek değiştirmek, çoğu zaman ikinci bir bozulma katmanı ekler.

3.11 Sıralama ve arama: Türk alfabesi sırası farklıdır

Türk alfabesinde harf sırası ... f g ğ h ı i j... ve ... s ş t u ü v y z biçimindedir; yani ı, i'den önce gelir ve ğ, ş kendi başlarına harflerdir. Varsayılan Unicode sıralama algoritması (UCA/DUCET) ise ı ve ğ gibi harfleri temel harflerin varyantı gibi ele alır. Sonuç, aynı albümün parça listesinin dağıtımcınızın panelinde bir sırada, mağazada başka bir sırada görünmesidir.

Bunu siz çözemezsiniz ve çözmeye çalışmamalısınız. Yapabileceğiniz tek şey, sıralamaya bağımlı olmayan bir künye teslim etmektir: parça numaralarını açıkça verin, disk numarasını doldurun, "Part 1 / Part 2" gibi ayrımları başlıkta ASCII rakamla yazın.

3.12 Teslimattan önce çalıştırılacak kontrol

Türkçe bir yayında en az şunlar denetlenmelidir: dizgede U+0307 var mı (bölüm 3.3); Romence ș/ț var mı (3.8); kesme işareti tek tip mi (3.7); düzeltme işareti kullanımı katalog boyunca tutarlı mı (3.6); bütün alanlar NFC mi (3.9); mojibake izi var mı (3.10); başlıkların tamamı büyük harf mi (3.4); başlık dili alanı dolu mu.

mazufa.com üzerinde bu denetimlerin bir bölümünü yapan ücretsiz bir künye denetleyicisi var; tamamen tarayıcıda çalışır ve hiçbir dosya yüklenmez.

4. Konuk sanatçı: feat. başlığa yazılmaz

Bağımsız dağıtımda en sık ve en pahalı giriş hatası, konuk sanatçının adını başlık alanına yazıp rol alanını boş bırakmaktır: Yol Ayrımı ft. Ceza gibi.

Başlık alanı bir gösterim dizgesidir; kimlik taşımaz. Bu yüzden konuk sanatçı hiçbir bağlantı almaz, kendi sayfasında görünmez, sizin kaydınıza dönen bir keşif yolu oluşmaz ve analitiğinde hiçbir şey birikmez. Mağaza ise ft. Ceza ifadesini şarkı adının parçası sayabilir; parçanın adı sonsuza kadar Yol Ayrımı ft. Ceza olur ve listelerde Yol Ayrımı ft. Ceza — Sanatçı A, Ceza gibi iki kez yazılmış bir künye görünür.

Mağazalar bunu açıkça yazar. Spotify: "You shouldn't include any artists' names in your track or release titles." Sağlayıcı dokümantasyonunda: "Spotify strongly recommends against including additional information, such as references to 'Featured Artists' in track and product titles." Music Biz, konuk sanatçının "at the Artist role level and not add this data to the track or album release title" biçiminde girilmesini önerir.

Sözleşme başlıkta anılmayı şart koşuyorsa biçim standarttır ve Türkçeleştirilmez. Music Biz: "feat." ve "with" başlığa girdiğinde "generally lowercase and in English." Apple daha da nettir: "Formatting of 'feat.' and 'with' must be lowercase, in English, not localized, and in parentheses or brackets."

Bu Türkçe için doğrudan bir kuraldır: başlık alanına ile, düet, düet:, konuk ya da ft yerine featin Türkçe karşılığı yazılmaz. feat. bir kelime değil, makine tarafından okunan bir işarettir. Doğrusu:

• Doğru: başlık = Yol Ayrımı, ana sanatçı = Sanatçı A, konuk sanatçı = Ceza
• Sözleşme gerektiriyorsa: Yol Ayrımı (feat. Ceza) — küçük harf, İngilizce, parantez içinde, ve rol alanı yine doldurulmuş olarak
• Yanlış: Yol Ayrımı ile Ceza, Yol Ayrımı - Düet Ceza, Yol Ayrımı Feat. Ceza

Roller kimliktir, başlıklar gösterimdir; kimliği gösterim alanına koymak hem kimliği yok eder hem gösterimi bozar.

5. Versiyon alanı, taksim ve remix

Versiyon alanının tek işi, aynı adı taşıyan iki kaydı birbirinden ayırmaktır; doldurup doldurmayacağınızın testi de budur. Sözlük istikrarlıdır: Radio Edit, Extended Mix, Live, Acoustic, Instrumental, Single Version, Alternate Take, Demo, Remastered ve adlandırılmış remixler için Sanatçı Adı Remix. 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." Noktalama için Music Biz önce parantez, ek ayrıntı için köşeli parantez kullanılmasını söyler.

Radio Edit, "küfürsüz olan" demek değildir. Music Biz bu terimi gerçekten yayın için hazırlanmış versiyona ayırır ve müstehcen içeriği çıkarılmış versiyon için Edited Version kullanılmasını söyler. Radio Edit normalde bir süre kısaltmasıdır; Edited Version bir içerik düzenlemesidir.

Original Mix her yerde güvenli değildir. Apple'ın yayımlanmış kılavuzu bunu yasaklar: "The standard, original version of an album, track, or music video must not include any additional information in the title unless it is needed to identify the content" — yasaklı terimler listesinde "Exclusive, Limited Edition, Album Version, Original Mix, Tone, Alert Tone...Dolby Atmos, lossless, high-resolution audio" sayılır. Spotify'ın kamuya açık künye yönergesi Original Mix terimini adıyla anan bir kural yayımlamaz; yayımlanmış tutumu, başlıkların ek bilgi taşımaması yönündeki genel kuraldır. Elektronik müzik perakendesinde ise bu etiket yerleşik gelenektir. Apple açıkça yasaklamıştır; diğer servisler bu terimi adıyla anan bir kural yayımlamamıştır ve uygulama mağazadan mağazaya, dağıtımcıdan dağıtımcıya değişir. Yayında yalnızca orijinal versiyon varsa alanı boş bırakın — her yerde doğrudur.

Türk müziğine özgü nokta: Taksim. Taksim, bir makam içinde yapılan doğaçlamadır; bir versiyon türü değildir. Hicaz Taksim bir eserin adıdır, Sultanıyegâh Peşrevinin bir "versiyonu" değildir. Versiyon alanına Taksim yazmak, aslında ayrı bir kayıt olan bir icrayı başka bir kaydın varyantı gibi gösterir. Aynı biçimde Bağlama Solo, Ney Doğaçlama ve Darbuka Solo da versiyon değil, başlıktır — eğer parça gerçekten oysa. Buna karşılık, aynı şarkının sazsız/sözsüz hâlini yayımlıyorsanız versiyon alanı Instrumental olmalıdır, Enstrümantal değil (versiyon sözlüğü İngilizcedir ve makinece okunur).

Bir kayıt gerçekten farklı bir kayıtsa — canlı, enstrümantal, edit, remix — yeni ISRC gerekir (bölüm 1). Remix'te yaygın hata, remixçiyi ana sanatçı alanına yazmaktır; Apple'ın kuralı bölüm 1'de alıntılanmıştır.

6. Tür alanı: arabesk, fasıl ve makam sözlüğünün yönlendirme karşılığı

Tür alanı bir tanım değil, bir yönlendirmedir. Türkiye'de üretilen müziğin büyük bir bölümü, mağazaların tür ağaçlarında birebir karşılığı olmayan yerel kategorilere aittir:

• Arabesk — Orhan Gencebay'dan bu yana kendi başına bir tür; çoğu mağaza ağacında ayrı bir düğüm olarak bulunmaz.
• Fasıl — Türk sanat müziğinin makam bütünlüğü içinde sıralanmış suit biçimi.
• Türk Sanat Müziği (TSM) ve Türk Halk Müziği (THM) — Türkiye'de birbirinden kesin ayrılan iki gelenek; birçok tür ağacında ikisi de "World" ya da "Middle Eastern" altına düşer.
• Türkü, oyun havası, ilahi / tasavvuf müziği, özgün müzik, Anadolu rock ve damar — hepsi Türkiye'de anlamı olan, dışarıda karşılığı olmayan etiketler.

Buradan çıkan pratik kural şudur: dağıtımcınızın sunduğu tür listesinde ne varsa ona göre karar verin, olmayan bir türü başlığa yazarak telafi etmeye çalışmayın. Bir Sevda Masalı (Arabesk) biçiminde bir başlık, tür alanını doldurmaz, sadece başlığı bozar. Türü listede bulamıyorsanız en yakın üst kategoriyi seçin ve alt tür alanı varsa oraya yazın.

Enstrüman ve makam sözlüğü ise başlıkta yaşar, tür alanında değil. Saz (genel olarak çalgı; dar anlamda bağlama), cura, divan sazı, ney, kanun, ud, tanbur, kemençe, kaval, mey, zurna, davul, darbuka, kabak kemane, cümbüş — bunların adları başlıkta geçtiğinde Türkçe yazılır ve bölüm 3.6'daki düzeltme işareti kuralına tabidir.

Makam adları da öyle: Hicaz, Rast, Nihavend, Uşşak, Hüseyni, Kürdi, Segâh, Saba, Hüzzam, Muhayyer, Acemaşiran, Kürdilihicazkâr. Bir fasıl yayınında bu adlar hem parça başlıklarında hem de albüm adında geçer; aynı makam adının albüm içinde iki farklı yazımla görünmesi (Segâh ve Segah) tek bir albümde bile katalog tutarsızlığı üretir.

7. Eser künyesi: yayıncılık parası burada kazanılır ya da kaybedilir

Kayıt ile beste iki ayrı haktır ve iki ayrı gelir akışı üretir. Dağıtımcınız kayıt tarafını toplar; eser tarafı — mekanik ve temsili telif — besteci ve söz yazarı alanlarından ve bunlara bağlı tesciller üzerinden izlenir. Bağımsız yayınlarda en zayıf halka budur, çünkü bu alanlar mağazanın önyüzünde hiç görünmez: besteci alanı boş bir yayın kusursuz görünür ve normal biçimde dinlenir, yayıncılık telifi ise eşleşmeden bekler.

• Besteci ve söz yazarı alanlarına sahne adı değil, resmî ad yazılır. Meslek birlikleri yazarın tescilli adı üzerinden eşleştirir.
• Tek dize yazan dahil, bütün yazarlar listelenir. Eksik yazar, eksik künye değil, eşleşmemiş bir paydır.
• Paylar %100'ü tamamlamalı ve yayından önce yazılı olarak anlaşılmalıdır. Künye bir anlaşmayı ifade eder; anlaşma yoksa künye bir tahmindir ve sonradan itiraza uğrar.
• Anonim ve geleneksel eserlerin düzenlemesinin de bir yazarı vardır — düzenleyen. Bir türküyü sadece "Anonim" olarak vermek, düzenleme payından vazgeçmektir. Türk halk müziği repertuvarında bu, en sık karşılaşılan gelir kaybıdır: kaynak kişi, derleyen ve düzenleyen ayrı ayrı belirtilmelidir.
• Remix besteyi değiştirmez. Remix yeni bir beste katmadıkça orijinal yazarlar yazar olarak kalır; kattıysa bu müzakere edilmiş bir paydır, varsayılan değil.

Türkiye'de eser tarafındaki tescil, yazarlar için MESAM ya da MSG üzerinden, bağlantılı haklar için MÜYAP ve MÜYORBİR üzerinden yürür. Dağıtımcıya girdiğiniz besteci/söz yazarı adlarının bu tescillerdeki adlarla birebir aynı olması, eşleşmenin çalışmasının önkoşuludur — ve bu, bölüm 3'teki bütün karakter sorunlarının eser tarafında da geçerli olduğu anlamına gelir.

Kayıt telifi gürültülü biçimde bozulur, yayıncılık telifi sessizce: bozuk bir sanatçı sayfası bir günde görülür, eşleşmemiş bir eser yıllarca fark edilmeyebilir.

8. Bir yayın gerçekte neden reddedilir

1. Başlık alanında sanatçı adı — ft., feat., with, ile, düet ya da remixçinin adı başlıkta, rol alanı boş (bölüm 4).
2. Başlıkta explicit/temiz ifadesi — (Explicit), (Clean), (Küfürlü). Bayrağı kullanın; Apple ve Music Biz metin biçimini yasaklar.
3. Başlıkta tanıtım ya da tanım metni — Exclusive, Limited Edition, Album Version, Original Mix, ya da Dolby Atmos ve lossless gibi format iddiaları; hepsi Apple'ın kılavuzunda adıyla sayılır.
4. Büyük/küçük harf ihlali — tümü büyük, tümü küçük ya da rastgele harf düzeni; gerçek ve tutarlı bir sanatsal tercih değilse kabul edilmez. Türkçede bu maddenin ek bir bedeli vardır: tümü büyük harf yazılmış bir Türkçe başlık, bölüm 3.4'te anlatıldığı gibi geri döndürülemez biçimde bozulabilir.
5. Künye ile kapak görselinin uyuşmaması — kapaktaki başlık, sanatçı ve versiyon alanlarla aynı olmalıdır. Türkçede bu, karakter karakter aynı demektir: kapakta Rüzgar, alanda Rüzgâr yazıyorsa uyuşmuyordur.
6. Dil alanlarının yanlış ya da boş olması — özellikle başlık dili.
7. Besteci ya da söz yazarının eksikliği — bazı hedefler doğrudan reddeder.
8. Yasak karakterler — emoji, süs sembolleri, çift boşluk, görünmez karakterler. Türkçe için buraya U+0307 artıkları ve Romence ș/ț de girer.
9. Yanlış kimlik numarası — maddi olarak farklı bir kayıtta yeniden kullanılmış ISRC, ya da kontrol hanesi tutmayan UPC.
10. Mevcut katalogla tutarsız sanatçı adı — ki bu çoğu zaman hiç reddedilmez, listedeki en zararlı madde olmasının sebebi de budur.

Teslimat öncesi rutin: kanonik sanatçı adını yazmak yerine yapıştırın; her başlık alanında yalnızca şarkının adının bulunduğunu doğrulayın; her rolün bir alanı, her alanın bir rolü olduğunu doğrulayın; bütün alanları NFC'ye normalleştirin; kesme işaretlerini tek tipe indirin; düzeltme işareti kararınızı katalog boyunca uygulayın; U+0307 ve mojibake taraması yapın; iki dil alanını da doldurun; P-line ve C-line'ı ayrı ayrı kontrol edin; ilk yayın değilse orijinal yayın tarihini girin; kapağı alanlarla karakter karakter karşılaştırın.

Aldığınız her ret ucuzdur; doğrulamadan geçen hatalar pahalıdır.

9. ABD stopajı: künyeden sonraki ilk idari adım

Künyeyi doğru teslim eden Türkiyeli sanatçının bir sonraki gerçek sorusu, ABD kaynaklı telifin nasıl vergilendiğidir. Bu, künyenin konusu değildir ama aynı teslimat gününde halledilmesi gereken bir şeydir.

Dosyada geçerli bir W-8BEN yoksa, ABD kaynaklı telife yasal oran olan %30 stopaj uygulanır. IRS Table 1'e göre (Rev. Mayıs 2023) Türkiye için anlaşmalı telif hakkı oranı %10'dur — yani formu doğru doldurmak farkı doğrudan gelirinize yazar.

İki pratik nokta: W-8BEN'in 6. satırı yabancı vergi kimlik numarasını kabul eder, dolayısıyla sanatçıların büyük çoğunluğunun ABD ITIN numarası almasına gerek yoktur; ve form, imzalandığı yılı izleyen üçüncü takvim yılının son gününe kadar geçerlidir — yani süresiz değildir, takviminize not düşün.

Ödeme tarafında yaygın bir yanlış anlamayı da kayda geçirmek gerekir: Spotify akış başına sabit bir ücret ödemediğini açıkça belirtir; gelir havuzlanır ve akış payına (streamshare) göre bölüşülür. Ülkeden ülkeye farklar, o ülkedeki abonelik fiyatlarından ve reklam gelirlerinden doğar. Hiçbir servis ülke bazlı akış başı ödeme oranı yayımlamaz; internette dolaşan tablolar servislerin verisi değildir.

10. Özet

• Künye üç katmanda tutulur — yayın, kayıt, eser — ve pahalı hataların çoğu, doğru bilginin yanlış katmana yazılmasıdır. Sanatçı adı bir etiket değil, bir anahtardır; roller kimlik, başlıklar gösterimdir.
• Türkçede asıl tehlike görünmez olandır: yerel ayarsız bir toLowerCase() çağrısı İSTANBUL'u i̇stanbul (U+0069 + U+0307), IŞIK'ı işik yapar; tümü büyük harf yazılmış bir Türkçe başlıkta i ile ı ayrımı geri getirilemez biçimde kaybolur. Bu, gerçek kataloglarda gerçekten yaşanmış bir hatadır.
• ASCII katlama bir sanatçıyı ikiye böler (Şebnem / Sebnem), iki sanatçıyı birleştirir (Şen / Sen, Çan / Can) ve bazen anlamı değiştirir (kâr / kar, şık / sık). Düzeltme işareti, kesme işareti, Romence ș, NFC/NFD ve eski Latin-5 artıkları aynı sınıftan sessiz bölücülerdir.
• Konuk sanatçı başlığa yazılmaz ve feat. Türkçeleştirilmez — makine tarafından okunan bir işarettir.
• Besteci ve söz yazarı alanları yayıncılık parasının izlendiği yerdir ve belirti vermeden bozulur; türkü düzenlemelerinde "Anonim" demek, düzenleme payından vazgeçmektir.

Kaynaklar

• Unicode Character Database, SpecialCasing.txt (SpecialCasing-17.0.0.txt, 2025-07-31) — Türkçe/Azerice harf dönüşümü kuralları — https://www.unicode.org/Public/UNIDATA/SpecialCasing.txt
• Unicode Character Database — karakter özellikleri: ayrışma eşlemeleri, harf dönüşümü eşlemeleri — https://www.unicode.org/ucd/
• Unicode Standard Annex #15, Unicode Normalization Forms — https://www.unicode.org/reports/tr15/
• Unicode Standard Annex #44, Unicode Character Database (SpecialCasing.txt'in dokümantasyonu) — https://www.unicode.org/reports/tr44/
• Music Business Association, Music Metadata Style Guide v2.1 — 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 — https://isrc.ifpi.org/en/isrc-standard/handbook
• DDEX, Standards (Electronic Release Notification Message Suite, ERN dahil) — https://ddex.net/standards/
• IRS, Tax Treaty Tables, Table 1 (Rev. Mayıs 2023) — https://www.irs.gov/businesses/international-businesses/tax-treaty-tables
• IRS, Form W-8BEN — https://www.irs.gov/forms-pubs/about-form-w-8ben

Yayımlanmamış olanın sınırı üzerine. Buradaki her mağaza kuralı, o mağazanın kendi kamuya açık dokümantasyonundan alıntılanmıştır. Sanatçılara sürekli kesin bilgi diye aktarılan üç şey ise hiçbir servis tarafından yayımlanmamıştır ve burada iddia edilmemiştir: sanatçı sayfası birleştirmeleri için gereken eşikler ve kanıtlar; bir teslimatın mevcut bir sanatçıya mı bağlanacağını yoksa yeni kimlik mi açacağını belirleyen iç eşleştirme mantığı; ve Apple'ın adıyla andığı yasak dışında, mağazaların Original Mix terimine yaklaşımı. Ayrıca, Türkçe künye hatalarının oranına dair yayımlanmış hiçbir ölçüm bilmiyoruz — sorun sektörde herkesçe yaşanmakta, hiç ölçülmemektedir.