เมทาดาทาของการเผยแพร่เพลง: คู่มืออ้างอิงทางเทคนิคสำหรับภาษาไทย

ชื่อศิลปิน ชื่อเพลง ศิลปินรับเชิญ เวอร์ชัน และการเขียนให้ผ่านสายการจัดจำหน่ายโดยไม่เสียหาย

คำตอบสั้น

เมทาดาทาคือสิ่งเดียวที่ระบบปลายทางทุกระบบ "ได้ยิน" — สตรีมมิงเซอร์วิสไม่เคยฟังเพลงของคุณ มันอ่านไฟล์ข้อมูลที่คุณส่งไป ฉะนั้นชื่อศิลปินไม่ใช่ข้อความ แต่เป็น กุญแจ (key) ที่ใช้จับคู่ตัวตน และการพิมพ์ชื่อใหม่ทุกครั้งคือการเสี่ยงสร้างศิลปินคนที่สองขึ้นมาโดยไม่รู้ตัว สำหรับภาษาไทยความเสี่ยงนี้รุนแรงกว่าภาษาที่เขียนด้วยอักษรละตินมาก เพราะสองเหตุผลที่ตาเปล่ามองไม่เห็นเลย: ภาษาไทยไม่มีช่องว่างระหว่างคำ ระบบค้นหาและระบบตัดข้อความทุกตัวจึงต้อง เดา ขอบเขตคำด้วยพจนานุกรม และสระกับวรรณยุกต์ที่ซ้อนอยู่บนพยัญชนะตัวเดียวกันสามารถเรียงสลับลำดับในสายไบต์ได้โดยที่หน้าจอแสดงผลออกมาเหมือนกันทุกประการ — และการ normalize แบบ NFC ก็ ไม่ แก้ให้ (ข้อนี้ผมตรวจสอบเองแล้ว ดูหัวข้อ 4) วินัยที่ใช้ได้จริงมีข้อเดียว: กำหนดสตริงมาตรฐานของชื่อศิลปินและชื่อเพลงไว้ครั้งเดียว เก็บเป็นไฟล์ แล้ว วาง (paste) ทุกครั้ง ห้ามพิมพ์ใหม่ พร้อมกับกรอกทุกบทบาท (ศิลปินรับเชิญ ผู้รีมิกซ์ ผู้ประพันธ์) ลงในช่องบทบาทของมันเอง ไม่ใช่ยัดลงในช่องชื่อเพลง

1. โครงสร้างสามชั้น: release / recording / work

ก่อนจะพูดถึงตัวอักษร ต้องแยกชั้นข้อมูลให้ออกก่อน เพราะความผิดพลาดที่แพงที่สุดในวงการนี้เกือบทั้งหมดคือ "ข้อเท็จจริงที่ถูก แต่กรอกผิดชั้น"

• Release (ผลิตภัณฑ์) — อัลบั้ม ซิงเกิล หรือ EP หนึ่งชุด มีรหัสประจำตัวคือ UPC/EAN
• Recording (การบันทึกเสียง) — แต่ละแทร็ก มีรหัสประจำตัวคือ ISRC
• Work (งานประพันธ์) — ตัวเพลงในฐานะบทประพันธ์ มีรหัสประจำตัวคือ ISWC และเป็นชั้นที่เงินฝั่ง publishing วิ่งผ่าน

การส่งข้อมูลไปยังร้านค้าใช้มาตรฐานกลางคือ DDEX ERN (Electronic Release Notification Message Suite)

รายละเอียดรหัสที่ต้องจำให้แม่น ISRC มี 12 อักขระ = 2 ตัวประเทศ + 3 ตัวผู้ลงทะเบียน + 2 ตัวปีอ้างอิง + 5 ตัวลำดับ ขีดกลางเป็นแค่ธรรมเนียมการแสดงผล ไม่ใช่ส่วนหนึ่งของรหัส และ ISRC ไม่มีเลขตรวจสอบ (check digit) ส่วน UPC-A มี 12 หลัก EAN-13 มี 13 หลัก เติมศูนย์ข้างหน้า UPC-A แล้วได้ EAN-13 โดย เลขตรวจสอบไม่เปลี่ยน วิธีคิดเลขตรวจสอบ: นับจากขวาไปซ้ายก่อนถึงหลักตรวจสอบ คูณสลับ ×3 และ ×1 รวมผลแล้วเลขตรวจสอบคือจำนวนที่ทำให้ผลรวมขึ้นไปถึงพหุคูณของ 10 ตัวถัดไป

ISRC ผูกกับ การบันทึกเสียง ไม่ใช่กับเพลงและไม่ใช่กับอัลบั้ม การนำเพลงเดิมมาปล่อยซ้ำจึงไม่ต้องขอ ISRC ใหม่ และรหัสเดิมติดตัวการบันทึกเสียงนั้นไปแม้จะเปลี่ยนผู้จัดจำหน่าย แต่รีมิกซ์ เวอร์ชันตัดต่อ เวอร์ชันแสดงสด และเวอร์ชันบรรเลง (instrumental) ถือเป็นการบันทึกเสียงที่ต่างกันอย่างมีนัยสำคัญ ต้องมีรหัสของตัวเอง

กรณีรีมาสเตอร์แคบกว่าที่คนไทยเข้าใจกันมาก คู่มือ ISRC ของ IFPI (§A.10.1) ระบุว่าต้องออกรหัสใหม่ "if (and only if) the processes applied to a recording during re-mastering involve the application of creative input to the recording itself" และระบุยกเว้นไว้ชัดเจนว่า การปรับระดับเสียงเฉย ๆ การทำ EQ หรือคอมเพรสชันแบบคงที่ การลดนอยส์ การลบเสียงคลิก การแก้ความเร็วหรือพิตช์ การเปลี่ยนอัตราสุ่ม และการทำ dither ไม่ ทำให้ต้องออกรหัสใหม่ — "A new ISRC shall not be assigned in the context of essentially invariant or technological adjustment processes." ดังนั้นอย่าเขียนว่า "รีมาสเตอร์ต้องมี ISRC ใหม่เสมอ" เพราะไม่จริง ข้อควรระวังเชิงปฏิบัติที่พูดได้อย่างปลอดภัยคือ ถ้าเวอร์ชันรีมาสเตอร์ถูกขายเป็นแทร็กแยกวางคู่กับต้นฉบับ มันคือสินค้าคนละชิ้นและต้องมีรหัสของตัวเอง

ถ้าคุณยังตอบไม่ได้ว่าข้อมูลชิ้นนี้อยู่ชั้นไหน คุณยังกรอกมันไม่ถูก

2. ช่องข้อมูลที่มีอยู่จริง และแต่ละช่องควบคุมอะไร

Primary artist (ศิลปินหลัก) — ช่องนี้ช่องเดียวที่ตัดสินว่าแทร็กจะไปอยู่หน้าศิลปินคนไหน และใครสะสมยอดผู้ฟัง ผู้ติดตาม และประวัติเชิงอัลกอริทึม แนวทางสาธารณะของ Spotify ระบุตรง ๆ ว่า "List each artist's name in a separate field."

Featured artist (ศิลปินรับเชิญ) — เป็น บทบาท บนการบันทึกเสียงเดียวกัน ให้เครดิตและเชื่อมไปหน้าศิลปินรับเชิญโดยไม่ยกให้เป็นศิลปินหลัก คู่มือของ Apple กำหนดให้ระบุที่ระดับแทร็กด้วยบทบาท Featuring หรือ With "not as Primary"

Remixer (ผู้รีมิกซ์) — เป็นบทบาทเช่นกัน Apple: "Remix tracks...must list the original artist as Primary with the remixer assigned the remixer role." การกรอกผู้รีมิกซ์เป็นศิลปินหลักคือวิธีที่หน้าศิลปินโดนกลบด้วยรีมิกซ์ของคนอื่น

ผู้ประพันธ์ทำนอง (composer) และผู้ประพันธ์คำร้อง (lyricist) — อธิบาย work ไม่ใช่ recording และเป็นช่องที่ค่าลิขสิทธิ์ฝั่งเผยแพร่ถูกสาวกลับมาหา (ดูหัวข้อ 9)

Producer (โปรดิวเซอร์) — เป็นเครดิต ไม่ใช่หน้าศิลปิน และไม่ใช่ช่องทางรับเงินฝั่งการบันทึกเสียง

Version / subtitle — วงเล็บที่ใช้แยกการบันทึกเสียงสองชุดที่ชื่อเดียวกัน (หัวข้อ 8)

Explicit flag — เป็นค่า boolean ไม่ใช่คำ 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: "you shouldn't add it to your track title." และห้ามทางกลับด้วย — อย่าพิมพ์ "Clean" หรือ "ฉบับไม่มีคำหยาบ" ลงในชื่อเพลง

ภาษาของงาน (สิ่งที่ร้อง) กับ ภาษาของชื่อเรื่อง (ภาษาและอักษรของสตริงชื่อ) เป็นคนละช่องและต่างกันได้จริง เพลงบรรเลงปี่พาทย์ที่ตั้งชื่อเป็นภาษาไทยไม่มีภาษาของเนื้อร้อง แต่มีภาษาของชื่อเรื่องเป็นภาษาไทย — และช่อง "ภาษาของชื่อเรื่อง" คือช่องที่บอกร้านค้าว่าจะเรียงลำดับ จัดทำดัชนี และเรนเดอร์สตริงนี้อย่างไร สำหรับงานอักษรไทย นี่คือหนึ่งในช่องที่มีผลมากที่สุดและถูกละเลยมากที่สุด

P-line = ปี + เจ้าของ การบันทึกเสียง โดยปีคือปีที่การบันทึกเสียงนั้นเผยแพร่ครั้งแรก ไม่ใช่ปีที่คุณอัปโหลด C-line = ปี + เจ้าของ ปกและอาร์ตเวิร์ก สองอันนี้ไม่ใช่อันเดียวกันและถูกคัดลอกทับกันเป็นประจำ

Release date คือวันที่สินค้าชิ้นนี้ขึ้นขาย ส่วน original release date คือวันที่การบันทึกเสียงนี้เผยแพร่ครั้งแรกที่ไหนก็ตาม การเอาเทปลูกทุ่งปี 2530 มาลงใหม่แล้วกรอก original release date เป็นปีนี้ เท่ากับบอกทุกระบบปลายทางว่ามันเป็นของใหม่ — ซึ่งทำลายทั้งการจัดหมวดหมู่และความน่าเชื่อถือของแคตตาล็อกเก่า

3. หัวใจของปัญหา: ภาษาไทยไม่มีช่องว่างระหว่างคำ

นี่คือข้อเท็จจริงเชิงโครงสร้างที่ทำให้เมทาดาทาภาษาไทยต่างจากทุกอย่างที่คู่มือฝรั่งเขียนไว้ ภาษาไทยเขียนติดกันเป็นพืด ช่องว่างในภาษาไทยเป็นตัวคั่น วลีหรือประโยค ไม่ใช่ตัวคั่นคำ ผลคือ ระบบใดก็ตามที่ต้องรู้ว่า "คำ" เริ่มตรงไหนจบตรงไหน — ระบบค้นหา ระบบตัดข้อความ ระบบขึ้นบรรทัดใหม่ ระบบไฮไลต์คำ — ต้องเดาเอาทั้งหมด

Unicode พูดเรื่องนี้ไว้ตรง ๆ ใน Unicode Standard Annex #29 (Text Segmentation):

"reliable detection of word boundaries in languages such as Thai, Lao, Chinese, or Japanese requires the use of dictionary lookup or other mechanisms, analogous to English hyphenation."

และในภาคผนวกเดียวกัน เมื่ออธิบายกลุ่มอักษรที่ต้องใช้ "South East Asian style of context analysis" ซึ่งรวมภาษาไทยไว้ด้วย:

"For scripts that use the South East Asian style of context analysis, neither the default word boundaries nor the default line breaks are adequate. Both need tailoring. The reason is that line breaks should only occur at word boundaries, but there's no demarcation of words. Scripts in this group include Thai, Myanmar, Khmer, and others; they can be identified by having letters with line break class SA."

ประโยคสุดท้ายนั้นคือคำอธิบายทางเทคนิคของอาการที่ศิลปินไทยเจอทุกวันโดยไม่มีใครบอกว่าทำไม

3.1 ทำไมร้านค้าอาจ "หาชื่อเพลงคุณไม่เจอ"

ระบบค้นหาส่วนใหญ่ทำงานบนโทเคน (token) ไม่ใช่บนสตริงดิบ ถ้าเอนจินตัดคำของร้านค้าตัดชื่อเพลงคุณคนละแบบกับที่ผู้ฟังพิมพ์ ผลลัพธ์คือ "ไม่พบ" ทั้งที่ทั้งสองฝั่งสะกดเหมือนกันเป๊ะ

ผมทดสอบด้วย PyThaiNLP 5.3.7 (ตรวจสอบเมื่อ 2026-09-08) เปรียบเทียบเอนจินตัดคำสองตัวที่ใช้กันแพร่หลาย คือ newmm (พจนานุกรม + maximal matching แบบ n-gram) กับ longest (จับคำยาวที่สุดก่อน) บนสตริงเดียวกัน:

สามตัวอย่างนี้เป็นผลจริงจากการรัน ไม่ใช่ตัวอย่างสมมติ สังเกตว่า ค่ำคืนนี้ — ชื่อเพลงที่ฟังดูธรรมดามาก — ให้โทเคนคนละชุดในสองเอนจิน ถ้าดัชนีของร้านค้าเก็บ ค่ำคืน ไว้ แต่ผู้ฟังพิมพ์ ค่ำ แล้วระบบไม่ทำ partial matching ก็จบ และคุณไม่มีทางรู้ว่าปลายทางแต่ละแห่งใช้พจนานุกรมรุ่นไหน

สิ่งที่ทำได้จริง อย่าตั้งชื่อเพลงที่ขอบเขตคำกำกวมถ้าเลี่ยงได้ ให้ค้นชื่อเพลงตัวเองในร้านค้าจริงหลังปล่อยแล้ว ๒–๓ วัน ด้วยคำค้นที่ผู้ฟังจะพิมพ์จริง ไม่ใช่ด้วยชื่อเต็ม และถ้าชื่อเพลงมีคำทับศัพท์หรือคำเฉพาะ ให้แน่ใจว่าคุณกรอกช่อง "ภาษาของชื่อเรื่อง" เป็นภาษาไทย เพื่อให้ปลายทางที่แยกพจนานุกรมตามภาษาเลือกตัวตัดคำภาษาไทยแทนที่จะปล่อยให้ตัวตัดคำเริ่มต้นมองสตริงทั้งก้อนเป็นโทเคนเดียว

3.2 การตัดข้อความ (truncation) ที่ตัดกลางคำ

ร้านค้าและวิดเจ็ตทุกแห่งตัดชื่อยาวให้พอดีช่อง สำหรับภาษาอังกฤษ การตัดที่ช่องว่างเป็นเรื่องง่าย สำหรับภาษาไทยไม่มีช่องว่างให้ตัด ระบบส่วนใหญ่จึงตัดที่จำนวนอักขระ หรือดีหน่อยก็ตัดที่ขอบ grapheme cluster ผลคือชื่อเพลงถูกหั่นกลางคำเป็นปกติ

แย่กว่านั้นคือขอบ grapheme cluster ของภาษาไทยมีกับดักของมันเอง ผมตรวจสอบกับแฟ้ม GraphemeBreakProperty.txt ของ UCD ฉบับล่าสุด (ตรวจสอบ 2026-09-08) พบว่า:

• U+0E33 SARA AM (ำ) มีค่า Grapheme_Cluster_Break = SpacingMark แปลว่าภายใต้ extended grapheme cluster มันเกาะติดกับพยัญชนะข้างหน้า — UAX #29 ยกตัวอย่างไว้เองว่า กำ (U+0E01 + U+0E33) คือหนึ่ง extended grapheme cluster
• แต่ในตารางเดียวกัน UAX #29 ระบุว่าภายใต้ legacy grapheme cluster ำ เพียงตัวเดียวคือหนึ่งคลัสเตอร์ — ระบบเก่าที่ยังใช้กฎ legacy จึงตัด ำ ออกจากพยัญชนะได้
• สระหน้า เ แ โ ใ ไ (U+0E40–U+0E44) ไม่ปรากฏใน GraphemeBreakProperty.txt เลย แปลว่าค่าเป็น Other — สระหน้าแต่ละตัวคือ grapheme cluster ของตัวเอง

ข้อสุดท้ายคือสาเหตุที่คุณเห็นชื่ออัลบั้มลงท้ายด้วยสระลอย ๆ เช่น รักเธอไม่มีวันเ… ตัวตัดข้อความที่ "ฉลาดพอ" ที่จะไม่หั่นกลาง grapheme cluster ยังตัดสระหน้าออกจากพยัญชนะที่มันควรอ่านทีหลังได้อยู่ดี เพราะในเชิงข้อมูลสระหน้าเป็นตัวอักษรอิสระ ไม่ใช่เครื่องหมายประกอบ — เพลง เก็บเป็น U+0E40 U+0E1E U+0E25 U+0E07 คือ "สระเอ, พอ, ลอ, งอ" ตามลำดับที่พิมพ์ ไม่ใช่ตามลำดับที่ออกเสียง

อีกเรื่องที่ควรรู้ไว้เวลาเจอข้อจำกัดความยาว: สวัสดี มี 6 code point แต่กิน 18 ไบต์ ใน UTF-8 (อักษรไทยใช้ 3 ไบต์ต่อ code point) ถ้าปลายทางจำกัด "255 ตัวอักษร" คุณต้องรู้ว่านับเป็น code point หรือเป็นไบต์ เพราะสองอย่างนี้ต่างกันสามเท่าสำหรับข้อความไทยล้วน และระบบเก่าบางระบบยังจำกัดเป็นไบต์อยู่

3.3 ช่องว่างที่แทรกเข้าไป "ให้อ่านง่าย" คือสตริงคนละตัวถาวร

นี่คือความผิดพลาดที่พบบ่อยที่สุดและแก้ยากที่สุดในงานไทย ทีมงานหรือผู้จัดจำหน่ายเห็นชื่อยาว ๆ ติดกันแล้วรู้สึกว่าอ่านยาก จึงเติมช่องว่างเข้าไป — ค่ำคืนนี้ กลายเป็น ค่ำ คืนนี้

ในเชิงข้อมูล นี่คือสตริงคนละตัว ตลอดไป ระบบจับคู่ตัวตนของศิลปิน ดัชนีค้นหา และการเปรียบเทียบสตริงทุกชนิดมองว่ามันไม่เท่ากัน ถ้าอัลบั้มแรกใช้ชื่อศิลปินแบบไม่มีช่องว่างและอัลบั้มที่สองมีช่องว่าง คุณจะได้หน้าศิลปินสองหน้า และไม่มีอะไรบนหน้าจอบอกว่าเกิดอะไรขึ้น เพราะช่องว่างเดียวในภาษาไทยดูเหมือน "การจัดหน้า" มากกว่า "การสะกด"

กฎ: ช่องว่างในเมทาดาทาภาษาไทยเป็นการตัดสินใจเชิงบรรณาธิการที่ทำครั้งเดียวแล้วห้ามเปลี่ยน ถ้าชื่อวงคือ วงพิณแคนอีสาน ก็ต้องเป็น วงพิณแคนอีสาน ทุกรีลีส ห้ามมี วง พิณแคนอีสาน หรือ วงพิณ แคนอีสาน ปนเข้ามาแม้ครั้งเดียว และตรวจช่องว่างซ้อน ช่องว่างท้ายสตริง กับ non-breaking space (U+00A0) ที่มักติดมาจากการคัดลอกจากเอกสาร Word หรือ Google Docs

4. สระกับวรรณยุกต์: ลำดับในสายไบต์ที่ตามองไม่เห็น และ NFC ไม่ช่วย

นี่คือหัวใจทางเทคนิคของเอกสารนี้ และเป็นข้อเท็จจริงที่แทบไม่มีเอกสารภาษาไทยฉบับไหนอธิบายไว้

พยางค์ไทยหนึ่งพยางค์ซ้อนกันได้ถึงสามชั้น: พยัญชนะฐาน + สระบนหรือสระล่าง + วรรณยุกต์ ในหน่วยความจำ ทั้งสามตัวเป็น code point แยกกันเรียงต่อกัน คำถามคือ ลำดับระหว่างสระกับวรรณยุกต์บังคับหรือไม่ — คำตอบคือ ไม่บังคับโดย Unicode และไม่บังคับโดยการเรนเดอร์

4.1 ผลการตรวจสอบจริง

ผมตรวจสอบด้วย Python 3.11.15 โมดูล unicodedata (UCD เวอร์ชัน 14.0.0) เมื่อวันที่ 2026-09-08 ผลที่ได้:

ค่า Canonical_Combining_Class (ccc) ของเครื่องหมายไทย

ทำไมค่าเหล่านี้ถึงสำคัญ UAX #15 (Unicode Normalization Forms) อธิบายกลไก Canonical Ordering Algorithm ไว้ว่า:

"Most characters (including all non-combining marks) have a Canonical_Combining_Class value of zero, and are unaffected by the Canonical Ordering Algorithm. Such characters are referred to by a special term, starter. Only the subset of combining marks which have non-zero Canonical_Combining_Class property values are subject to potential reordering by the Canonical Ordering Algorithm."

แปลว่า อักขระที่มี ccc = 0 เป็น "starter" และทำหน้าที่เป็น กำแพงกั้นการจัดลำดับ อักขระที่อยู่คนละฝั่งของ starter จะไม่ถูกสลับที่กันเด็ดขาด

ทีนี้ดูผลลัพธ์จริง:

กรณีสระบน (ccc = 0) — ไม่มีอะไรแก้ให้เลย

ก + ่ + ี   =  U+0E01 U+0E48 U+0E35
ก + ี + ่   =  U+0E01 U+0E35 U+0E48

NFC   → ไม่เปลี่ยนทั้งคู่
NFD   → ไม่เปลี่ยนทั้งคู่
NFKC  → ไม่เปลี่ยนทั้งคู่
NFKD  → ไม่เปลี่ยนทั้งคู่
เท่ากันหลัง NFC ?  →  False

กรณีสระล่าง (ccc = 103) — normalize แล้วมาบรรจบกัน

ก + ่ + ุ   =  U+0E01 U+0E48 U+0E38
NFC / NFD   →  U+0E01 U+0E38 U+0E48      (สลับที่ให้)

ก + ุ + ่   =  U+0E01 U+0E38 U+0E48
NFC / NFD   →  U+0E01 U+0E38 U+0E48      (คงเดิม)
เท่ากันหลัง NFC ?  →  True

ความไม่สมมาตรนี้คือประเด็นทั้งหมด สระล่างกับวรรณยุกต์มี ccc ไม่เป็นศูนย์ทั้งคู่ (103 กับ 107) จึงถูกเรียงใหม่ให้อัตโนมัติและสองลำดับมาบรรจบกัน ส่วนสระบนมี ccc = 0 เป็น starter จึงกั้นวรรณยุกต์ไว้คนละฝั่ง และสองลำดับนั้นแยกกันตลอดไป ไม่ว่าคุณจะ normalize ด้วยฟอร์มไหน

4.2 สิ่งนี้แปลว่าอะไรในทางปฏิบัติ

ก่ี (พิมพ์วรรณยุกต์ก่อนสระ) กับ กี่ (พิมพ์สระก่อนวรรณยุกต์) เป็นสตริงคนละตัว ในฟอนต์และเอนจินเรนเดอร์จำนวนมากทั้งสองแสดงผลออกมาใกล้เคียงหรือเหมือนกันจนแยกไม่ออกด้วยตาเปล่า — บางเอนจินวางเครื่องหมายเหลื่อมกันเล็กน้อย บางเอนจินวางทับกันพอดี และในขนาดตัวอักษรของหน้าเว็บร้านค้าปกติ ไม่มีใครสังเกตเห็น

ลำดับที่ถูกต้องตามหลักการเรียงพิมพ์ไทยคือ พยัญชนะ → สระ → วรรณยุกต์ แต่ Unicode ไม่บังคับ และแป้นพิมพ์ ระบบ IME แอปคาราโอเกะ ไฟล์เนื้อเพลง และการคัดลอกจาก PDF เก่า ๆ ผลิตลำดับสลับออกมาได้ทั้งนั้น เมื่อคุณคัดลอกชื่อเพลงจากไฟล์เนื้อร้องที่ใครสักคนพิมพ์ไว้เมื่อสิบปีก่อน คุณอาจกำลังวางสตริงที่ลำดับสลับลงในช่องชื่อเพลง โดยที่มันดูถูกต้องสมบูรณ์

ผลตามมา: หน้าศิลปินแยกเป็นสอง ค้นหาไม่เจอ การจับคู่งานประพันธ์กับการบันทึกเสียงล้มเหลว และไม่มีใครเห็นสาเหตุ

4.3 วินัยที่ต้องใช้

1. NFC ไม่ใช่ตัวทำความสะอาด ทำ NFC ทุกครั้งก่อนส่งข้อมูล เพราะมันแก้กรณีสระล่างให้ แต่อย่าเข้าใจผิดว่ามันแก้กรณีสระบนให้ — มันไม่แก้ และนี่คือกรณีที่พบบ่อยกว่ามาก (สระ ิ ี ึ ื ั เจอบ่อยกว่า ุ ู มาก)
2. ต้องตรวจลำดับด้วยกฎที่คุณเขียนเอง กฎง่าย ๆ ที่ใช้ได้: ถ้าพบวรรณยุกต์ (U+0E48–U+0E4B) หรือ ์ (U+0E4C) ตามหลังพยัญชนะทันที และตัวถัดไปเป็นสระบน (U+0E31, U+0E34–U+0E37, U+0E47) ให้ตั้งธงว่าลำดับผิด ตรวจแบบนี้ได้ด้วยสคริปต์สามบรรทัด และมันจะจับสิ่งที่สายตามนุษย์จับไม่ได้
3. ห้ามพิมพ์ชื่อใหม่ เก็บสตริงมาตรฐานไว้ในไฟล์ .txt แล้ววางทุกครั้ง ทุกฟิลด์ ทุกรีลีส ตลอดไป
4. อย่าใส่วรรณยุกต์ซ้อนสองตัวหรือใส่ ์ กับวรรณยุกต์บนพยัญชนะเดียวกันโดยไม่ตั้งใจ ระบบตรวจสอบของปลายทางบางแห่งปฏิเสธ บางแห่งไม่ปฏิเสธ ซึ่งแย่กว่า

เว็บไซต์ mazufa.com มีเครื่องมือตรวจเมทาดาทาแบบใช้ฟรีที่ทำงานบนเครื่องของคุณเองทั้งหมดและไม่อัปโหลดอะไรออกไป ซึ่งตรวจจับกรณีที่มองไม่เห็นเหล่านี้ได้ — ลำดับสระกับวรรณยุกต์สลับ สระอำที่ถูกแยกร่าง เลขไทยปนเลขอารบิก และสตริงที่ยังไม่เป็น NFC

5. สระอำ (U+0E33) — ตัวอักษรที่ NFKC ผ่าออกเป็นสองซีก

สระอำเป็นกรณีพิเศษที่ควรรู้แยกต่างหาก ผลการตรวจสอบ (Python 3.11.15, UCD 14.0.0, 2026-09-08):

ำ  U+0E33  THAI CHARACTER SARA AM
   General_Category      = Lo      (เป็น "ตัวอักษร" ไม่ใช่ combining mark)
   Canonical_Combining_Class = 0
   Decomposition_Mapping = <compat> U+0E4D U+0E32
   Grapheme_Cluster_Break = SpacingMark

จุดสำคัญคือคำว่า <compat> — สระอำมี compatibility decomposition ไม่ใช่ canonical decomposition ผลที่ตามมาต่างกันคนละเรื่อง:

นำ            = U+0E19 U+0E33
  NFC   → U+0E19 U+0E33            (ไม่เปลี่ยน)
  NFD   → U+0E19 U+0E33            (ไม่เปลี่ยน)
  NFKC  → U+0E19 U+0E4D U+0E32     (เปลี่ยน! กลายเป็น นิคหิต + สระอา)
  NFKD  → U+0E19 U+0E4D U+0E32     (เปลี่ยน!)

ค่ำ           = U+0E04 U+0E48 U+0E33          (3 code point)
  NFKC  → U+0E04 U+0E48 U+0E4D U+0E32        (4 code point)

และเมื่อ NFKC แยกมันออกไปแล้ว มันไม่ประกอบกลับ เพราะ Unicode ไม่ recompose ตัวที่มี compatibility decomposition สตริงที่ผ่าน NFKC จึงเสียหายแบบทางเดียว

ในหน้าจอ นำ กับ นํา (นิคหิต + สระอา) อาจดูเกือบเหมือนกันในฟอนต์หลายตัว แต่เป็นสตริงคนละตัวยาวไม่เท่ากัน UAX #15 เตือนเรื่องนี้ไว้ตรง ๆ:

"Normalization Forms KC and KD must not be blindly applied to arbitrary text. Because they erase many formatting distinctions, they will prevent round-trip conversion to and from many legacy character sets, and unless supplanted by formatting markup, they may remove distinctions that are important to the semantics of the text."

กฎสำหรับงานไทย: normalize เป็น NFC เท่านั้น ห้ามใช้ NFKC หรือ NFKD กับเมทาดาทาภาษาไทยเด็ดขาด และถ้าคุณรับไฟล์ CSV มาจากผู้จัดจำหน่ายหรือสตูดิโอ ให้ตรวจว่ามี U+0E4D ตามด้วย U+0E32 หลุดมาหรือไม่ — ถ้ามี แปลว่ามีใครสักคนในสายงานรัน NFKC ทับข้อมูลของคุณ

6. เลขไทย ๐๑๒๓ กับเลขอารบิก 0123

ภาษาไทยมีชุดตัวเลขของตัวเองคือ ๐๑๒๓๔๕๖๗๘๙ (U+0E50–U+0E59) ใช้ในเอกสารราชการ ป้ายวัด และงานที่ต้องการโทนคลาสสิก รวมถึงปกอัลบั้มลูกกรุงและปี่พาทย์จำนวนไม่น้อย

สิ่งที่คนเข้าใจผิดคือ คิดว่า normalize แล้วมันจะกลายเป็นเลขอารบิกเอง ไม่จริง ผลตรวจสอบ:

๕  U+0E55  THAI DIGIT FIVE
   General_Category      = Nd
   Numeric value         = 5
   Decomposition_Mapping = (ว่าง — ไม่มีเลย)
   NFKC("๒๕๖๘")  →  "๒๕๖๘"     ← ไม่เปลี่ยนแม้แต่นิดเดียว

เปรียบเทียบกับตัวเลขที่ NFKC แปลง ให้จริง:

５  U+FF15  FULLWIDTH DIGIT FIVE      decomp = <wide> 0035   →  NFKC = "5"
⁵  U+2075  SUPERSCRIPT FIVE           decomp = <super> 0035  →  NFKC = "5"

ความต่างคือ เลขเต็มความกว้างและเลขยกกำลังมี compatibility decomposition ไปหา ASCII ส่วน เลขไทยไม่มี decomposition เลย มันเป็นอักขระอิสระเต็มตัว เช่นเดียวกับเลขอารบิก-อินดิก ٥ (U+0665) และเลขเปอร์เซีย ۵ (U+06F5) — ทั้งสามชุดนี้ไม่มีฟอร์มการ normalize ใดแปลงเป็น ASCII ให้

ผลในทางปฏิบัติ: ผู้ฟังที่พิมพ์ ชุดที่ 2 จะไม่เจอผลงานที่ตั้งชื่อว่า ชุดที่ ๒ เว้นแต่ชั้นค้นหาของร้านค้านั้นจะทำ digit folding เอง ซึ่งไม่มีปลายทางไหนรับประกัน และคุณตรวจสอบไม่ได้ด้วย

กฎ: เลือกชุดตัวเลขชุดเดียวสำหรับทั้งแคตตาล็อก และสำหรับฟิลด์ที่เครื่องอ่าน (เลขชุด เลขภาค หมายเลขแทร็ก) ให้ใช้ ASCII เสมอ ถ้าเลขไทยเป็นส่วนหนึ่งของงานศิลป์จริง ๆ ให้เก็บไว้บนปก ไม่ใช่ในฟิลด์ข้อความ และห้ามปนสองชุดในสตริงเดียวกันเด็ดขาด — เพลงชุดที่ ๒ Vol. 3 คือหายนะทั้งต่อการค้นหาและต่อการเรียงลำดับ

7. การถอดเป็นอักษรโรมัน: RTGS กับความจริงที่ศิลปินใช้กันอยู่

ศิลปินไทยทุกคนมีชื่อสองชื่อในระบบของโลก — ชื่อภาษาไทย และชื่อโรมัน และทั้งสองชื่อต้องมีค่าเดียวตายตัว

7.1 RTGS คืออะไร และมันทิ้งอะไรไป

ระบบถอดอักษรไทยเป็นอักษรโรมันแบบถ่ายเสียงของราชบัณฑิตยสถาน (Royal Thai General System of Transcription, RTGS) ฉบับปี 2542/1999 คือระบบทางการ รายงานของ UNGEGN Working Group on Romanization Systems ระบุว่า "A revised version of the system was officially endorsed by the government of Thailand in 2000. This was approved at the Eighth United Nations Conference for the Standardization of Geographical Names in Berlin, 2002 (resolution VIII/13)."

แต่เอกสารฉบับเดียวกันระบุข้อจำกัดไว้ตรง ๆ สองข้อ ซึ่งเป็นหัวใจของปัญหาเมทาดาทา:

"Tone marks (◌่, ◌้, ◌๊ and ◌๋) and diacritical marks including the silencing mark (◌์) and the vowel shortening mark (◌็), are completely ignored."

"The romanization system is not reversible to its original script form."

พูดให้ตรง: RTGS ทิ้งวรรณยุกต์ทั้งหมด และไม่แยกสระสั้นสระยาวในหลายกรณี ผลคือชื่อไทยที่ต่างกันชัดเจนในภาษาไทยจะถอดออกมาเป็นสตริงโรมันเดียวกัน ก้อง กอง และ ก่อง ล้วนกลายเป็น kong ในระบบที่ไม่มีเครื่องหมายกำกับ ในเชิงเมทาดาทา นี่แปลว่าศิลปินสามคนกลายเป็นกุญแจเดียวกัน ซึ่งเป็นความล้มเหลวคนละทิศกับกรณีสระ-วรรณยุกต์ในหัวข้อ 4 แต่แพงพอกัน

7.2 ความจริงคือแทบไม่มีใครใช้ RTGS

ศิลปินไทยเขียนชื่อโรมันของตัวเองตามความเคยชิน ตามหนังสือเดินทาง หรือตามที่ดูดีบนปก ผลคือชื่อเดียวมีได้หลายรูป:

ทุกรูปแบบมีเหตุผลรองรับ และทุกรูปแบบคือ ศิลปินคนละคน สำหรับระบบจับคู่ตัวตน สิ่งที่เกิดขึ้นจริงคือ รีลีสภาษาไทยไปรวมกันที่หน้าหนึ่ง รีลีสที่ตั้งชื่อโรมันกระจายไปอีกสองสามหน้า ศิลปินรู้สึกว่า "ยอดสตรีมน้อยกว่าที่ควร" แต่หาสาเหตุไม่เจอ เพราะแต่ละหน้าดูปกติดีเมื่อดูทีละหน้า

7.3 วินัยการเลือก

เลือกตามลำดับความสำคัญนี้:

1. รูปที่ศิลปินใช้อยู่แล้วในที่สาธารณะ — ชื่อผู้ใช้โซเชียล ชื่อโดเมน ชื่อบนปกที่พิมพ์ไปแล้ว ความสม่ำเสมอกับร่องรอยที่มีอยู่สำคัญกว่าความถูกต้องทางภาษาศาสตร์
2. ถ้ายังไม่มี ให้ใช้รูปที่อยู่บนรีลีสที่ใหญ่ที่สุดที่มีอยู่
3. ถ้ายังไม่มีอีก ให้ใช้รูปที่ผู้ฟังในตลาดเป้าหมายจะพิมพ์จริง — รูปที่พบบ่อยชนะรูปที่ถูกต้องตามตำรา RTGS ที่ไม่มีใครพิมพ์
4. ตัดสินใจครั้งเดียวสำหรับทุกไดกราฟที่กำกวม: ph หรือ p, th หรือ t, kh หรือ k, or หรือ o, ae หรือ ae/e แล้วใช้แบบนั้นทั้งแคตตาล็อก

อย่าใช้ RTGS แบบมีเครื่องหมายกำกับวรรณยุกต์ในฟิลด์เมทาดาทา เพราะไม่มีใครพิมพ์ตามและมันทำให้ค้นไม่เจอ

และที่สำคัญที่สุด: อย่าเอาชื่อโรมันไปใส่ในช่องชื่อหลัก ถ้ากลุ่มผู้ฟังของคุณค้นหาด้วยภาษาไทย โมเดลข้อมูลที่ถูกต้องคือ ชื่อภาษาไทยอยู่ในฟิลด์หลัก ชื่อโรมันอยู่ในฟิลด์ localization หรือฟิลด์ phonetic ซึ่งเป็นแบบเดียวกับที่ 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." ถ้าผู้จัดจำหน่ายของคุณไม่เปิดฟิลด์เหล่านี้ ให้เลือกอักษรที่ผู้ฟังของคุณค้นหาจริง แล้วยึดไว้อย่างนั้น

ชื่อโรมันคือชื่อศิลปินชื่อที่สอง และศิลปินที่ยังไม่ได้เลือกมัน ก็เท่ากับได้เลือกไว้แล้วหลายชื่อ

8. ธรรมเนียมชื่อคนไทย: ชื่อเล่น นามสกุลยาว และคำนำหน้า

ประเทศไทยมีธรรมเนียมการเรียกชื่อที่ไม่ตรงกับสมมติฐานของระบบเมทาดาทาสากลเลย และเรื่องนี้สร้างปัญหาจริงในทุกรีลีส

8.1 ชื่อเล่นคือชื่อที่คนรู้จักจริง

คนไทยแทบทุกคนมีชื่อเล่นพยางค์เดียวหรือสองพยางค์ และในวงการเพลง ชื่อเล่นคือชื่อที่ผู้ฟังรู้จัก ค้นหา และพูดถึง ไม่ใช่ชื่อจริง ศิลปินลูกทุ่งที่ทุกคนเรียกว่า แคน อาจมีชื่อจริงว่า วัฒนพงษ์ ซึ่งไม่มีใครพิมพ์ในช่องค้นหา

รูปแบบที่ใช้กันแพร่หลายและปลอดภัยที่สุดคือ ชื่อเล่น + ชื่อจริง เช่น แคน วัฒนพงษ์ เพราะครอบคลุมทั้งคำค้นที่ผู้ฟังใช้และความเป็นทางการที่จำเป็นในเอกสาร แต่ ต้องตัดสินใจครั้งเดียว ถ้ารีลีสแรกใช้ แคน วัฒนพงษ์ รีลีสที่สองห้ามใช้ แคน เฉย ๆ และห้ามใช้ วัฒนพงษ์ ศรีบุญเรืองวัฒนา ทั้งสามคือศิลปินสามคนในสายตาระบบ

ข้อควรระวัง: ช่องว่างระหว่างชื่อเล่นกับชื่อจริงเป็นช่องว่างเดียวเสมอ และมันเป็นส่วนหนึ่งของกุญแจ (ดูหัวข้อ 3.3)

8.2 นามสกุลไทยยาวผิดปกติ และนั่นเป็นปัญหาทางเทคนิค

นามสกุลไทยจำนวนมากยาวมาก — ศรีบุญเรืองวัฒนา, ณัฐวุฒิพงศ์พันธุ์, จันทร์ประเสริฐศิลป์ เป็นความยาวปกติ ไม่ใช่กรณีพิเศษ นามสกุลเดียวอาจกิน 15–20 code point คือ 45–60 ไบต์ใน UTF-8 เมื่อรวมกับชื่อจริงและชื่อเล่นแล้ววางในช่อง composer ที่จำกัดความยาว ระบบปลายทางบางแห่งตัดทิ้ง — และชื่อผู้ประพันธ์ที่ถูกตัดครึ่งจะจับคู่กับทะเบียนงานประพันธ์ไม่ได้ ซึ่งแปลว่าเงินฝั่ง publishing ค้าง

ตรวจความยาวของชื่อผู้ประพันธ์ทุกคนก่อนส่ง ทั้งเป็น code point และเป็นไบต์ และถ้าปลายทางตัด ให้ใช้ชื่อในรูปที่ตรงกับทะเบียนขององค์กรจัดเก็บ ไม่ใช่รูปที่คุณเห็นสวยกว่า

8.3 คำนำหน้าและยศ — ไม่ควรอยู่ในช่องศิลปิน

ภาษาไทยมีคำนำหน้าและยศจำนวนมากที่ปรากฏบนเอกสารและบนปกแผ่นเสียงเก่า:

• คำนำหน้าทั่วไป: นาย, นาง, นางสาว
• คำนำหน้าทางวิชาการ/เกียรติยศ: ดร., ศ., รศ., ผศ., ครู
• ยศทหารและตำรวจ: พ.ต.ท., ร.ต.อ., พล.อ., จ.ส.อ.
• ฐานันดรศักดิ์: ม.ล., ม.ร.ว., ม.จ.

สิ่งเหล่านี้ไม่ควรอยู่ในช่อง primary artist เหตุผลเป็นเชิงเทคนิคล้วน ๆ: คำนำหน้าเปลี่ยนได้ตามกาลเวลา (ยศเลื่อน ตำแหน่งทางวิชาการเปลี่ยน) แต่กุญแจจับคู่ตัวตนต้องนิ่ง ศิลปินที่ปล่อยอัลบั้มปี 2564 ในชื่อ ร.ต.อ. สมชาย... แล้วปล่อยอัลบั้มปี 2568 ในชื่อ พ.ต.ท. สมชาย... จะได้หน้าศิลปินสองหน้าทันที และไม่มีทางย้อนกลับได้ง่าย ๆ

นอกจากนี้จุดในตัวย่อ (พ.ต.ท.) ยังเป็นอักขระที่ระบบตรวจสอบบางแห่งจัดว่าเป็น "เครื่องหมายวรรคตอนเกิน" และเป็นแหล่งของสตริงที่ต่างกันเพราะจุดหายไปหนึ่งจุด

ข้อยกเว้นเดียวที่สมเหตุสมผลคือ ครู ในกรณีที่คำนี้เป็นส่วนหนึ่งของชื่อในวงการที่ผู้ฟังใช้เรียกจริงมาหลายสิบปี เช่นครูเพลงลูกทุ่งที่ทุกคนเรียกว่า ครู + ชื่อ จนกลายเป็นชื่อเดียวกัน ถ้าเป็นแบบนั้น ให้ถือว่า ครู เป็นส่วนหนึ่งของสตริงมาตรฐาน และใส่ทุกครั้งเหมือนกันทุกรีลีส ส่วนคำนำหน้าและยศอื่นทั้งหมด ให้ไปอยู่ในบันทึกภายในหรือในเครดิตบนปก ไม่ใช่ในฟิลด์

9. ศิลปินรับเชิญ: ทำไมช่องชื่อเพลงเป็นที่ผิด

ความผิดพลาดที่สร้างความเสียหายมากที่สุดในการจัดจำหน่ายอิสระคือ การพิมพ์ ชื่อเพลง ft. ศิลปิน ข ลงในช่อง ชื่อเพลง แล้วปล่อยช่องบทบาทศิลปินรับเชิญว่างไว้

ช่องชื่อเพลงเป็นสตริงสำหรับแสดงผล มันไม่แบกตัวตนใด ๆ ผลคือศิลปินรับเชิญไม่ได้ลิงก์เครดิต ไม่ปรากฏบนหน้าตัวเอง ไม่มีเส้นทางให้ผู้ฟังของเขาเดินกลับมาหาเพลงคุณ และไม่มีอะไรเข้าหน้าสถิติของเขาเลย ขณะที่ร้านค้าอาจถือว่า ft. ศิลปิน ข เป็นส่วนหนึ่งของชื่อเพลงถาวร แล้วยังสร้างข้อความแสดงผลของตัวเองซ้อนเข้าไปอีกชั้น กลายเป็น ชื่อเพลง ft. ศิลปิน ข (feat. ศิลปิน ข) ซึ่งเป็นลายเซ็นของงานที่ส่งแบบไม่รู้เรื่อง

ร้านค้าพูดเรื่องนี้ไว้ชัด 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 แนะนำให้ให้เครดิตศิลปินรับเชิญ "at the Artist role level and not add this data to the track or album release title"

กรณีที่สัญญาบังคับให้ต้องมีในชื่อจริง ๆ ธรรมเนียมตรงกันทุกฝ่าย Music Biz ระบุว่า feat. และ with "when included in the title are generally lowercase and in English" ส่วน Apple: "Formatting of 'feat.' and 'with' must be lowercase, in English, not localized, and in parentheses or brackets."

คำว่า "not localized" สำคัญมากสำหรับงานไทย — ห้ามแปล feat. เป็นภาษาไทย อย่าเขียน (ร่วมกับ...), (รับเชิญ...), (ฟีท....) หรือ (ft....) แบบทับศัพท์ไทยลงในช่องชื่อเพลง feat. เป็นโทเคนที่เครื่องอ่าน ไม่ใช่คำในภาษา

โครงสร้างที่ถูกต้อง: ช่องชื่อเพลงบรรจุชื่อเพลงเท่านั้น และศิลปินแต่ละคนอยู่ในช่องบทบาทของตัวเอง แล้วปล่อยให้ร้านค้าสร้างข้อความแสดงผลรวมถึง (feat. X) ที่คุณอยากได้ ขึ้นมาจากบทบาทที่คุณกรอก

บทบาทคือตัวตน ชื่อเรื่องคือการแสดงผล การเอาตัวตนไปใส่ในช่องแสดงผลทำลายทั้งตัวตนและการแสดงผลพร้อมกัน

10. เวอร์ชันและชื่อรอง (version / subtitle)

ช่องเวอร์ชันมีไว้เพื่อแยกการบันทึกเสียงสองชุดที่ชื่อเดียวกัน นั่นคืองานทั้งหมดของมัน และเป็นเกณฑ์ตัดสินว่าควรกรอกหรือไม่ ถ้าเพลงนี้มีเวอร์ชันเดียวในรีลีสนี้ ให้เว้นว่าง

คำศัพท์ที่ใช้ได้นิ่ง ๆ คือ Radio Edit, Extended Mix, Live, Acoustic, Instrumental, Single Version, Alternate Take, Demo, Remastered และรีมิกซ์ที่ตั้งชื่อว่า ชื่อศิลปิน 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." เรื่องเครื่องหมาย Music Biz กำหนดให้ใช้วงเล็บกลมก่อน แล้วใช้วงเล็บเหลี่ยมสำหรับรายละเอียดเพิ่มเติมชั้นถัดไป

คำเวอร์ชันควรเป็นภาษาอังกฤษ ไม่ใช่ภาษาไทย เหตุผลเดียวกับ feat. — มันเป็นโทเคนที่ระบบปลายทางรู้จัก ไม่ใช่คำบรรยาย อย่าเขียน (บรรเลง) แทน (Instrumental) หรือ (แสดงสด) แทน (Live) ถ้าคุณอยากให้ผู้ฟังไทยเข้าใจ นั่นเป็นงานของชั้นแสดงผลของร้านค้า ไม่ใช่ของฟิลด์

"Radio Edit" ไม่ใช่คำเรียกฉบับตัดคำหยาบ Music Biz สงวนคำนี้ไว้สำหรับเวอร์ชันที่เตรียมสำหรับออกอากาศจริง และให้ใช้ "Edited Version" สำหรับฉบับที่ตัดเนื้อหา — Radio Edit คือการตัดที่ ความยาว ส่วน Edited Version คือการตัดที่ เนื้อหา

"Original Mix" ไม่ปลอดภัยเสมอไป และตรงนี้ร้านค้าต่างกันจริง คู่มือของ Apple ห้ามไว้ตรง ๆ: "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" โดยระบุคำที่ห้ามไว้รวมถึง "Exclusive, Limited Edition, Album Version, Original Mix, Tone, Alert Tone...Dolby Atmos, lossless, high-resolution audio" ขณะที่เอกสารสาธารณะของ Spotify ไม่มีกฎที่ระบุชื่อ "Original Mix" ไว้เฉพาะ มีเพียงหลักทั่วไปว่าชื่อเรื่องไม่ควรมีข้อมูลเพิ่มเติม สรุปให้ตรงกับสิ่งที่ตรวจสอบได้: Apple ระบุห้ามไว้ในเอกสารของตน ส่วนบริการอื่นไม่ได้เผยแพร่กฎที่กล่าวถึงคำนี้ไม่ว่าทางใด และการปฏิบัติจริงต่างกันไปตามร้านค้าและตามระบบตรวจสอบล่วงหน้าของผู้จัดจำหน่ายแต่ละราย

และไม่ว่ากรณีใด ถ้ามีช่องเวอร์ชัน ให้กรอกในช่องนั้น อย่าพิมพ์เวอร์ชันลงในชื่อเพลงเอง มิฉะนั้นร้านค้าที่สร้างข้อความแสดงผลของตัวเองจะได้ ชื่อเพลง (Live) (Live)

11. เครดิตผู้ประพันธ์ MCT และราคาของคำว่า "เพลงพื้นบ้าน"

สิทธิในการบันทึกเสียงกับสิทธิในงานประพันธ์เป็นคนละสิทธิ มีสายรายได้แยกกัน ผู้จัดจำหน่ายเก็บฝั่งการบันทึกเสียง ส่วนฝั่งงานประพันธ์ — ค่าลิขสิทธิ์การทำซ้ำและการเผยแพร่ต่อสาธารณะ — ถูกสาวกลับผ่านช่อง ผู้ประพันธ์ทำนอง และ ผู้ประพันธ์คำร้อง กับทะเบียนที่ตามมา

ช่องเหล่านี้คือจุดอ่อนที่สุดของงานอิสระ ด้วยเหตุผลเชิงโครงสร้าง: มันไม่ปรากฏบนหน้าร้านค้า ไม่มีอะไรในประสบการณ์การฟังบอกคุณว่ามันผิด รีลีสที่มีช่องผู้ประพันธ์ว่างเปล่าดูสมบูรณ์แบบและสตรีมได้ปกติ ขณะที่ค่าลิขสิทธิ์ฝั่งเผยแพร่ค้างอยู่โดยไม่มีใครรับ

ค่าลิขสิทธิ์ฝั่งการบันทึกเสียงพังแบบมีเสียงดัง ฝั่งงานประพันธ์พังแบบเงียบสนิท หน้าศิลปินที่แตกเห็นได้ภายในวันเดียว แต่งานประพันธ์ที่จับคู่ไม่ได้อาจเงียบอยู่หลายปี

11.1 ภูมิทัศน์การจัดเก็บในประเทศไทย

องค์กรจัดเก็บฝั่งผู้ประพันธ์ที่เป็นสมาชิกเต็มของ CISAC ในประเทศไทยคือ Music Copyright (Thailand) Ltd. (MCT) เว็บไซต์ของ MCT ระบุว่าเป็น "the only composer organization in Thailand which has been recognized as a full member of the International Confederation of Societies of Authors and Composers (CISAC)" และระบุขอบเขตงานว่า "represents for Public Performance rights in musical work created by composers & authors, both local and international repertoires"

นอกจากนี้ในประเทศไทยยังมีองค์กรจัดเก็บอื่น ๆ ที่ดูแลสิทธิฝั่งผู้ผลิตสิ่งบันทึกเสียงและสิทธิข้างเคียง ซึ่งเป็นคนละชั้นกับสิทธิของผู้ประพันธ์

สิ่งที่ผมยืนยันไม่ได้และจะไม่กล่าวอ้าง: ขั้นตอนภายในของการจับคู่งานประพันธ์ เกณฑ์และหลักฐานที่ใช้ในการพิจารณาข้อพิพาทเรื่องส่วนแบ่ง และกรอบเวลาการจ่ายจริง — ข้อมูลเหล่านี้ไม่ได้ถูกเผยแพร่ในรูปที่ตรวจสอบได้ ใครที่บอกคุณเป็นตัวเลขแน่นอน กำลังบอกสิ่งที่เขาไม่ได้อ่านมาจากเอกสารสาธารณะ

11.2 กฎที่ใช้ได้ทันที

• ช่องผู้ประพันธ์ใช้ชื่อจริงตามกฎหมาย ไม่ใช่ชื่อในวงการ องค์กรจัดเก็บจับคู่จากชื่อที่จดทะเบียนไว้ ดีเจแคน ไม่ใช่ผู้ประพันธ์ คนที่อยู่หลังชื่อนั้นต่างหากที่เป็น
• ต้องระบุผู้ประพันธ์ทุกคน แม้คนที่เขียนแค่บรรทัดเดียว ผู้ประพันธ์ที่หายไปไม่ใช่เครดิตที่ขาด แต่คือส่วนแบ่งที่จับคู่ไม่ได้
• ส่วนแบ่งต้องรวมเป็น 100% และต้องตกลงเป็นลายลักษณ์อักษรก่อนปล่อยเพลง เมทาดาทาแค่แสดงข้อตกลง ถ้าไม่มีข้อตกลง มันคือการเดาที่จะกลายเป็นข้อพิพาทภายหลัง
• รีมิกซ์ไม่เปลี่ยนงานประพันธ์ ผู้ประพันธ์เดิมยังเป็นผู้ประพันธ์ เว้นแต่รีมิกซ์นั้นเพิ่มงานประพันธ์ใหม่เข้าไป ซึ่งเป็นเรื่องที่ต้องเจรจาส่วนแบ่ง ไม่ใช่เรื่องที่สมมติเอาเอง

11.3 ต้นทุนของการกรอกว่า "เพลงพื้นบ้าน"

นี่คือความเสียหายที่เกิดกับแคตตาล็อกไทยเป็นประจำ และเป็นข้อที่คนไทยควรรู้มากที่สุดในหัวข้อนี้

เพลงลูกทุ่ง และ หมอลำ จำนวนมหาศาลมีครูเพลงที่มีตัวตน มีชื่อ มีปีที่แต่ง และมีทายาทที่ยังมีชีวิตอยู่ แต่เมื่อวงรุ่นใหม่นำมาบันทึกเสียงใหม่ คนกรอกฟอร์มมักเลือกทางที่ง่ายที่สุด คือกรอกช่องผู้ประพันธ์ว่า เพลงพื้นบ้าน, Traditional, ไม่ทราบ หรือ Public Domain

ผลที่ตามมามีสองชั้น ชั้นแรก: ค่าลิขสิทธิ์ฝั่งงานประพันธ์ของเพลงนั้นจะไม่ถูกจัดสรรให้ครูเพลงหรือทายาท เพราะไม่มีชื่อให้จับคู่ ชั้นที่สอง ซึ่งร้ายกว่า: ข้อมูลนี้ถูกคัดลอกต่อไปยังฐานข้อมูลปลายทางหลายสิบแห่ง และเมื่อมีการบันทึกเสียงชุดถัดไปในอนาคต คนกรอกฟอร์มคนต่อไปจะเห็นว่า "ในระบบระบุว่าเป็นเพลงพื้นบ้าน" แล้วกรอกตามกันไป — ความผิดพลาดหนึ่งครั้งกลายเป็นบรรทัดฐาน

แคตตาล็อกลูกทุ่งและหมอลำคือเหยื่อประจำ ด้วยเหตุผลง่าย ๆ ว่าเพลงจำนวนมากอยู่ในช่วงที่เอกสารต้นฉบับอยู่ในกล่องกระดาษของค่ายเก่าหรือของครอบครัวครูเพลง ไม่ได้อยู่ในฐานข้อมูลออนไลน์ที่ค้นง่าย ความยากในการค้นหาไม่ได้แปลว่างานนั้นไม่มีผู้ประพันธ์

กฎที่ควรยึด: กรอก Traditional เฉพาะเมื่อคุณค้นแล้วจริง ๆ และเชื่อได้อย่างมีเหตุผลว่าไม่มีผู้ประพันธ์ที่ระบุตัวได้ ไม่ใช่เมื่อคุณยังไม่ได้ค้น และจำไว้เสมอว่า การเรียบเรียงงานที่หมดอายุความคุ้มครองแล้วยังมีผู้ประพันธ์ คือผู้เรียบเรียง — วงปี่พาทย์ที่เรียบเรียงเพลงเถาขึ้นใหม่ หรือวงที่เรียบเรียงเพลงลูกทุ่งเก่าให้เป็นเวอร์ชันวงดนตรีสมัยใหม่ มีสิทธิในงานเรียบเรียงนั้น การกรอก เพลงพื้นบ้าน เฉย ๆ คือการสละสิทธิ์นั้นทิ้งไปด้วย

สำหรับงานดนตรีไทยเดิม การระบุเครื่องดนตรีในเครดิตให้ถูกต้อง — ระนาดเอก, ฆ้องวง, ซออู้, ขลุ่ย สำหรับวงปี่พาทย์และเครื่องสาย และ แคน, พิณ สำหรับหมอลำและลูกทุ่งอีสาน — ไม่ได้มีผลต่อการจ่ายเงินโดยตรง แต่มีผลต่อการจัดหมวดหมู่และการค้นพบ และเป็นหลักฐานประกอบเวลาต้องยืนยันว่าการบันทึกเสียงนี้เป็นเวอร์ชันที่ต่างจากต้นฉบับอย่างมีนัยสำคัญ (ซึ่งย้อนกลับไปเรื่อง ISRC ในหัวข้อ 1)

12. อะไรที่ทำให้รีลีสถูกปฏิเสธ และวิธีตัดปัญหาล่วงหน้า

เรียงตามความถี่ที่พบในงานภาษาไทย:

1. ชื่อศิลปินอยู่ในช่องชื่อเพลง — ft., feat., ร่วมกับ, หรือชื่อผู้รีมิกซ์ ขณะที่ช่องบทบาทว่าง (หัวข้อ 9)
2. คำว่า Explicit หรือ Clean ในชื่อ — (Explicit), (ฉบับเซ็นเซอร์), (Clean) ใช้ flag เท่านั้น
3. ข้อความโปรโมทหรือคำบรรยายในชื่อ — Exclusive, Limited Edition, Album Version, Original Mix, เวอร์ชันพิเศษ หรือคำอ้างรูปแบบไฟล์เช่น Dolby Atmos, lossless ซึ่ง Apple ระบุห้ามไว้ทั้งชุด
4. การใช้ตัวพิมพ์ผิดกฎในส่วนที่เป็นอักษรละติน — พิมพ์ใหญ่ทั้งหมด พิมพ์เล็กทั้งหมด หรือสลับมั่ว เว้นแต่เป็นเจตนาทางศิลปะที่ใช้สม่ำเสมอ Music Biz กำหนดกฎ title case ไว้ รวมถึงรายการคำที่ให้พิมพ์เล็ก ("a, an, and, as, but, for, from, nor, of, or, so, the, to, yet" และคำบุพบทที่มีสี่ตัวอักษรหรือน้อยกว่า)
5. เมทาดาทาไม่ตรงกับปก — ชื่อเพลง ชื่อศิลปิน และเวอร์ชันบนอาร์ตเวิร์กต้องตรงกับฟิลด์ทุกตัวอักษร ซึ่งสำหรับงานไทยหมายถึงตรงกันในระดับช่องว่างและลำดับวรรณยุกต์ด้วย
6. ช่องภาษาผิดหรือว่าง โดยเฉพาะ "ภาษาของชื่อเรื่อง" ในรีลีสที่ชื่อเป็นภาษาไทย
7. ไม่มีผู้ประพันธ์ทำนองหรือคำร้อง ซึ่งปลายทางบางแห่งปฏิเสธทันที
8. อักขระต้องห้าม — อีโมจิ สัญลักษณ์ตกแต่ง ช่องว่างซ้อน อักขระที่มองไม่เห็น รวมถึง non-breaking space (U+00A0) ที่ติดมาจากการคัดลอก
9. รหัสผิด — ISRC ที่ใช้ซ้ำกับการบันทึกเสียงที่ต่างกันจริง หรือ UPC ที่เลขตรวจสอบไม่ผ่าน
10. ชื่อศิลปินไม่ตรงกับแคตตาล็อกเดิม — ซึ่งมักจะ ไม่ ถูกปฏิเสธเลย และนั่นคือเหตุผลที่มันเป็นข้อที่แพงที่สุดในรายการนี้

12.1 รายการตรวจก่อนส่ง (ฉบับภาษาไทย)

• [ ] วางสตริงชื่อศิลปินจากไฟล์มาตรฐาน ไม่พิมพ์ใหม่
• [ ] ตรวจว่าไม่มีช่องว่างเกิน ช่องว่างท้ายสตริง หรือ U+00A0
• [ ] ทำ NFC (ไม่ใช่ NFKC) กับทุกฟิลด์
• [ ] ตรวจว่าไม่มี U+0E4D ตามด้วย U+0E32 หลุดมาแทนที่ ำ
• [ ] ตรวจลำดับสระบน–วรรณยุกต์ด้วยสคริปต์ ไม่ใช่ด้วยสายตา
• [ ] ตรวจว่าชุดตัวเลขเป็นชุดเดียวทั้งรีลีส และฟิลด์ที่เครื่องอ่านใช้ ASCII
• [ ] ตรวจว่าชื่อโรมันตรงกับที่เคยใช้ทุกครั้งที่ผ่านมา
• [ ] ช่องชื่อเพลงมีแค่ชื่อเพลง ไม่มีชื่อคน ไม่มีคำบรรยาย
• [ ] ทุกบทบาทมีช่องของมัน และทุกช่องมีบทบาทที่ถูกต้อง
• [ ] feat. และคำเวอร์ชันเป็นภาษาอังกฤษตัวพิมพ์เล็ก ไม่แปลเป็นไทย
• [ ] ผู้ประพันธ์ทุกคนใช้ชื่อจริง ส่วนแบ่งรวม 100% และไม่มีคำว่า เพลงพื้นบ้าน ที่ยังไม่ได้ค้น
• [ ] คำนำหน้าและยศไม่อยู่ในช่องศิลปิน
• [ ] ตั้งค่าภาษาของเนื้อร้องและภาษาของชื่อเรื่องครบทั้งสองช่อง
• [ ] P-line กับ C-line ไม่ใช่ค่าเดียวกันโดยไม่ตั้งใจ
• [ ] ถ้าไม่ใช่การเผยแพร่ครั้งแรก ตั้ง original release date ให้ถูก
• [ ] เทียบปกกับฟิลด์ทีละอักขระ

การถูกปฏิเสธเป็นเรื่องถูก ความผิดพลาดที่ผ่านระบบตรวจสอบไปได้ต่างหากที่แพง

13. สรุป

• ข้อมูลถูกจัดเก็บสามชั้น — release, recording, work — และความผิดพลาดที่แพงที่สุดคือข้อเท็จจริงที่ถูกแต่กรอกผิดชั้น ชื่อศิลปินคือกุญแจ ไม่ใช่ป้ายชื่อ บทบาทคือตัวตน ชื่อเรื่องคือการแสดงผล
• ภาษาไทยไม่มีช่องว่างระหว่างคำ ระบบค้นหา ระบบตัดข้อความ และระบบขึ้นบรรทัดทุกตัวจึงเดาขอบเขตคำด้วยพจนานุกรม — ซึ่งแปลว่าคุณควบคุมไม่ได้ และช่องว่างเดียวที่ใครสักคนเติมเข้าไป "ให้อ่านง่าย" คือสตริงคนละตัวถาวร
• สระบน (ccc = 0) เป็น starter จึงกั้นวรรณยุกต์ (ccc = 107) ไว้ การ normalize ทุกฟอร์มไม่แก้ลำดับสระบน–วรรณยุกต์ที่สลับกัน ขณะที่สระล่าง (ccc = 103) แก้ให้ — ความไม่สมมาตรนี้ตรวจสอบแล้วและแทบไม่มีเอกสารไหนบอก
• สระอำมี compatibility decomposition ดังนั้น ห้ามใช้ NFKC/NFKD กับเมทาดาทาไทย และเลขไทยไม่มี decomposition เลย NFKC ไม่แปลงให้เป็น ASCII
• RTGS ทิ้งวรรณยุกต์ทั้งหมดและไม่ย้อนกลับ ชื่อไทยหลายชื่อจึงถอดเป็นโรมันตรงกัน เลือกรูปเดียวแล้วยึดตลอดไป และให้ชื่อไทยอยู่ในฟิลด์หลัก ชื่อโรมันอยู่ในฟิลด์รอง
• ชื่อเล่นคือชื่อที่ผู้ฟังค้นหา นามสกุลไทยยาวจนถูกตัดในฟิลด์ที่จำกัดความยาว และคำนำหน้ากับยศไม่ควรอยู่ในช่องศิลปินเพราะมันเปลี่ยนได้ แต่กุญแจต้องนิ่ง
• ช่องผู้ประพันธ์คือที่ที่เงินฝั่งเผยแพร่ถูกสาวกลับ และมันพังโดยไม่มีอาการ การกรอก เพลงพื้นบ้าน ทับครูเพลงที่มีชื่อจริงคือความเสียหายที่ถูกคัดลอกต่อไปเรื่อย ๆ และแคตตาล็อกลูกทุ่งกับหมอลำคือเหยื่อประจำ

Mazufa จัดจำหน่ายโดยไม่มีค่าใช้จ่าย (ไม่มีค่าอัปโหลด ไม่มีค่าสมาชิกรายปี ไม่มีค่าธรรมเนียมต่อรีลีส) หักเพียง 5% ของค่าลิขสิทธิ์ที่ได้รับ และใบสมัครที่สมบูรณ์ทุกใบผ่านการตรวจโดยมนุษย์

แหล่งอ้างอิง

• Unicode Standard Annex #29, Unicode Text Segmentation — https://www.unicode.org/reports/tr29/
• Unicode Standard Annex #15, Unicode Normalization Forms — https://www.unicode.org/reports/tr15/
• Unicode Character Database, GraphemeBreakProperty.txt — https://www.unicode.org/Public/UCD/latest/ucd/auxiliary/GraphemeBreakProperty.txt
• Unicode Character Database (คุณสมบัติอักขระ: canonical combining class, decomposition mapping) — https://www.unicode.org/ucd/
• UNGEGN Working Group on Romanization Systems, Thai (ระบบ RTGS, มติ VIII/13 ปี 2002) — https://arhiiv.eki.ee/wgrs/rom1_th.pdf
• Music Copyright (Thailand) Ltd. (MCT) — https://www.mct.in.th/index.php?page=home&language=EN และ https://www.mct.in.th/faq.php?page=faq&language=EN
• 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
• DDEX, Standards (รวมถึง ERN) — https://ddex.net/standards/
• IFPI, International Standard Recording Code (ISRC) Handbook (§A.10.1) — https://www.ifpi.org/wp-content/uploads/2021/02/ISRC_Handbook.pdf
• PyThaiNLP 5.3.7 (ใช้ทดสอบการตัดคำ engine newmm และ longest) — https://pythainlp.org/

หมายเหตุว่าด้วยขอบเขตของสิ่งที่ตรวจสอบได้

ค่า Unicode ทุกค่าในเอกสารนี้ได้จากการรัน Python 3.11.15 โมดูล unicodedata (UCD 14.0.0) และการอ่านแฟ้ม UCD โดยตรง เมื่อวันที่ 2026-09-08 ผลการตัดคำได้จาก PyThaiNLP 5.3.7 วันเดียวกัน กฎของร้านค้าทุกข้ออ้างจากเอกสารสาธารณะของร้านค้านั้นเอง

สามเรื่องที่ศิลปินมักถูกบอกว่าเป็น "ข้อเท็จจริง" แต่ไม่มีบริการใดเผยแพร่ และเอกสารนี้จึงไม่กล่าวอ้าง: เกณฑ์และหลักฐานที่ใช้ในการรวมหน้าศิลปินที่แตกออกจากกัน, ตรรกะภายในที่ตัดสินว่ารีลีสใหม่จะเข้าไปรวมกับศิลปินเดิมหรือสร้างศิลปินใหม่, และ (นอกเหนือจากข้อห้ามที่ Apple ระบุชื่อไว้) การปฏิบัติของแต่ละร้านค้าต่อคำว่า "Original Mix"

เช่นเดียวกัน สำหรับฝั่งไทย เอกสารนี้ไม่ระบุขั้นตอนภายใน กรอบเวลาการจ่าย หรือเกณฑ์การพิจารณาข้อพิพาทขององค์กรจัดเก็บใด ๆ เพราะไม่มีเอกสารสาธารณะที่ตรวจสอบได้รองรับ และไม่มีการวัดอัตราความผิดพลาดของเมทาดาทาอักษรไทยที่ตีพิมพ์ไว้ที่ใดเท่าที่เราทราบ — ปัญหานี้พบกันทั่วไปแต่ยังไม่เคยมีใครวัด