Pembuatan feed DDEX adalah proses mengubah sebuah rilis musik beserta metadata-nya menjadi pesan XML standar yang bisa diserap platform streaming secara otomatis. Formatnya adalah ERN (Electronic Release Notification) dari DDEX, dan format ini membawa semua yang dibutuhkan DSP untuk memublikasikan sebuah rilis: judul dan artis, ISRC, referensi ke artwork dan file audio, serta teritori dan ketentuan kesepakatan yang berlaku. Membuat feed itu dengan benar adalah kunci agar musik Anda terdistribusi tanpa harus memasukkan data ulang secara manual.
Panduan ini menjelaskan isi sebuah pesan ERN, cara kerja pembuatan feed langkah demi langkah, perbedaan antara ERN 3.8.2 dan 4.3, serta cara menilai penyedia yang menanganinya untuk Anda, termasuk di mana posisi LabelGrid.
Apa itu DDEX dan mengapa penting untuk distribusi?
DDEX (Digital Data Exchange) adalah badan standar nirlaba yang berdiri pada 2006 dan menetapkan format pesan XML yang dipakai di seluruh rantai pasok musik digital. Label, distributor, DSP, penerbit musik, dan lembaga pengumpul royalti memakainya untuk bertukar data rilis, hak, dan penjualan secara otomatis, tanpa harus membangun integrasi khusus untuk setiap mitra (Tentang DDEX). Untuk distribusi, standar yang paling penting adalah ERN (Electronic Release Notification): pesan yang mengirimkan rilis baru, rujukan ke file audio dan artwork-nya, serta ketentuan komersialnya ke DSP.
LabelGrid mengirimkan rilis ke DSP dalam bentuk pesan DDEX ERN dan mendukung ERN 3.8.2, 4.3.0, 4.3.1, dan 4.3.2. LabelGrid bukan anggota DDEX, dan keanggotaan memang tidak diperlukan untuk menerapkan standarnya: siapa pun bisa melakukannya dengan lisensi implementasi DDEX yang gratis (standar DDEX). Bagian yang berat, dan yang paling tidak ingin ditangani sendiri oleh kebanyakan label, adalah membuat feed ERN yang valid serta menjaganya tetap mutakhir saat persyaratan setiap DSP terus berubah.
Apa itu feed DDEX ERN?
Feed ERN adalah dokumen XML yang mendeskripsikan satu rilis dan bagaimana rilis itu seharusnya tersedia. Pesan intinya adalah NewReleaseMessage, yang menyatukan tiga hal yang dibutuhkan DSP: aset, rilis, dan ketentuannya.
- ResourceList memuat rekaman suara beserta video atau gambar jika ada, masing-masing dengan pengenalnya (ISRC untuk track) dan detail teknisnya.
- ReleaseList adalah rilis itu sendiri: judul, artis tampil, nama label, UPC, genre, dan tanggal rilis.
- DealList menetapkan ketentuan komersial, termasuk teritori dan platform mana yang menerimanya, jadwal rilis, serta jendela pre-order jika ada.
Perusahaan rekaman dan distributor mengirim pesan-pesan ini ke DSP. DSP lalu mengurai feed tersebut dan memublikasikan rilis sesuai ketentuan kesepakatan (dokumentasi DDEX ERN). Sebuah penarikan, koreksi metadata, atau penambahan teritori baru masing-masing menjadi pesan tersendiri dalam format yang sama. Pelanggaran skema atau satu kolom wajib yang kosong sudah cukup membuat pengiriman ditolak. Itulah sebabnya validasi sama pentingnya dengan pembuatan.
Bagaimana cara kerja pembuatan feed DDEX?
Pembuatan feed mengambil data rilis Anda dan menghasilkan paket ERN yang siap diterima DSP. Alur kerja pada umumnya berjalan seperti ini:
- Kumpulkan metadata. Kolom rilis dan track, kontributor, pengenal (ISRC, UPC), teritori, dan penanda konten eksplisit.
- Tautkan asetnya. File audio yang ditranskode sesuai spesifikasi tiap DSP dan artwork yang memenuhi syarat ukuran (umumnya master persegi 3000x3000px) dilampirkan sebagai sumber.
- Validasi. Feed diperiksa terhadap skema DDEX dan profil masing-masing DSP tujuan sebelum apa pun dikirim. Baris hak cipta yang hilang, ISRC yang cacat, atau artwork yang kekecilan tertangkap di tahap ini.
- Buat XML ERN.
NewReleaseMessagedisusun dengan versi yang tepat (3.8.2 atau 4.3) untuk tujuannya. - Distribusikan. Paket dikirim ke tiap DSP dan tanda terima dikembalikan.
- Tangani pembaruan. Koreksi, penarikan, dan penambahan teritori baru dikirim sebagai pesan lanjutan yang terhubung ke rilis yang sama.
Inilah alasan pekerjaan ini tidak sepele: sekitar 99.000 track baru dikirim ke layanan streaming setiap hari pada 2024 (Laporan Akhir Tahun Luminate 2024). Tidak ada yang menulis XML dengan tangan pada volume seperti itu. LabelGrid menangani pembuatan feed DDEX dari hulu ke hilir: menghasilkan dan memvalidasi ERN terhadap profil terkini tiap DSP lalu mendistribusikannya ke semua platform utama, sehingga label dan distributor cukup mengirim rilis alih-alih membangun dan merawat mesin feed sendiri.
ERN 3.8.2 vs ERN 4.3: versi mana yang dipakai DSP?
Dua generasi ERN masih dipakai. ERN 3.8.2 tetap hidup di integrasi DSP yang sudah ada, meskipun dukungan DDEX untuk semua versi ERN 3 berakhir pada 1 Maret 2025. ERN 4.3.x adalah generasi saat ini, dan DDEX menyarankan penerapan versi terbarunya. Keduanya tidak bisa saling menggantikan. Sebuah mesin feed harus bisa berbicara dalam versi mana pun yang diharapkan setiap DSP.
| Aspek | ERN 3.8.2 | ERN 4.3.x |
|---|---|---|
| Status | Versi lama; dukungan DDEX berakhir pada 1 Maret 2025 | Versi saat ini; DDEX menyarankan penerapan versi terbaru |
| Data teritori | Blok DetailsByTerritory mengulang judul per teritori | Penggantian teritorial hanya di tempat datanya benar-benar berbeda |
| Kontributor | Artis dan penulis lagu diulang di sepanjang pesan | Didefinisikan sekali dalam PartyList, dirujuk lewat ID |
| Rilis track | Struktur rilis lengkap, dengan kolom yang berlebihan | Komposit TrackRelease yang ringan |
| Ukuran pesan | Lebih besar karena duplikasi | Lebih kecil, tanpa duplikasi |
| Audio spasial | Dukungan terbatas untuk audio imersif | Dukungan penuh untuk audio imersif, ditambahkan di 4.3 |
Intinya secara praktis: integrasi ERN 3 yang sudah ada tetap bertahan karena migrasi dari ERN 3 ke 4 berarti merombak seluruh model data teritorial, sebab ERN 4 menghapus blok DetailsByTerritory. Kemampuan yang lebih baru, termasuk dukungan penuh untuk audio imersif dan deduplikasi PartyList, membutuhkan ERN 4. Penyedia yang layak dipakai mendukung keduanya dan memilih versi yang tepat untuk tiap tujuan. LabelGrid mengirim dalam DDEX ERN 3.8.2, 4.3.0, 4.3.1, dan 4.3.2. Impor DDEX, yang memasukkan pengiriman ERN milik Anda sendiri ke LabelGrid, tersedia di paket API dan Custom Distribution.
Taruhan untuk membuat distribusi berjalan benar terus meningkat. Streaming mencapai 69,6% dari pendapatan musik rekaman global pada 2025, dengan 837 juta pelanggan berbayar (IFPI Global Music Report 2026). Feed yang ditolak atau cacat berarti kehilangan visibilitas di kanal tempat sebagian besar uang kini berputar.
Apa yang harus dicari pada layanan pembuatan feed DDEX?
Jika Anda memilih penyedia untuk membuat feed alih-alih membangun sendiri, inilah daftar periksa yang penting.
| Kriteria | Seperti apa yang baik |
|---|---|
| Beragam versi ERN | Baik 3.8.2 maupun 4.3.x, dipilih per DSP, bukan satu format untuk semua. |
| Validasi pra-distribusi | Pemeriksaan skema dan profil per DSP yang menangkap kesalahan sebelum dikirim, bukan setelah ditolak. |
| Perawatan spesifikasi | Penyedia memantau perubahan profil DSP agar feed Anda tidak diam-diam rusak. |
| Transkode audio | File dikodekan sesuai spesifikasi tiap platform sebagai bagian dari alur kerja. |
| Penarikan dan pembaruan | Koreksi, perubahan teritori, dan penarikan ditangani sebagai pesan lanjutan yang benar. |
| Akses API | Distribusi dan pelacakan status secara terprogram, agar pembuatan feed bisa berjalan di dalam sistem Anda sendiri. |
| Dukungan SOBO | Kemampuan mendistribusikan di bawah kontrak DSP Anda sendiri jika Anda memegang kesepakatan langsung. |
Cara mendistribusikan musik lewat DDEX: panduan langkah demi langkah
- Putuskan: bangun sendiri atau pakai layanan. Merawat mesin ERN dan memantau setiap perubahan profil DSP adalah pekerjaan rekayasa berkelanjutan yang nyata. Bagi sebagian besar label dan distributor, memakai penyedia adalah pilihan yang masuk akal.
- Pastikan cakupan versinya. Pastikan penyedia menghasilkan ERN 3.8.2 maupun 4.3.x dan mengarahkan versi yang tepat ke tiap DSP.
- Siapkan metadata yang bersih. ISRC dan UPC yang akurat, baris hak cipta yang benar, dan artwork yang sesuai spesifikasi. Input yang bersih adalah yang lolos validasi.
- Validasi sebelum distribusi. Jalankan feed lewat pemeriksaan skema dan per DSP. Perbaiki yang ditandai sebelum apa pun dikirim.
- Distribusikan dan konfirmasi. Kirim ke tiap DSP dan pantau tanda terimanya. Lacak platform mana saja yang sudah menerima rilis.
- Rawat katalognya. Kirim koreksi, teritori baru, dan penarikan sebagai pesan lanjutan, lalu awasi feed Anda saat spesifikasi DSP berubah.
LabelGrid cocok dengan jalur ini berkat pembuatan feed DDEX yang lengkap untuk ERN 3.8.2, 4.3.0, 4.3.1, dan 4.3.2, validasi pra-distribusi, transkode audio, hingga distribusi ke semua DSP utama. Bagi tim yang ingin menjalankannya secara terprogram, alur kerja yang sama tersedia melalui REST API LabelGrid lengkap dengan sandbox dan dokumentasi publik. LabelGrid adalah Spotify Preferred Provider dan anggota Merlin Network. LabelGrid juga menjaga feed tetap mutakhir seiring berkembangnya persyaratan platform.
Pembuatan feed DDEX: kesimpulannya
Pembuatan feed DDEX mengubah sebuah rilis menjadi pesan ERN standar, yaitu NewReleaseMessage yang membawa sumber daya, data rilis, dan ketentuan kesepakatan, yang diserap DSP secara otomatis. Dua versi yang masih dipakai adalah ERN 3.8.2 (versi lama, dukungan DDEX berakhir Maret 2025) dan 4.3.x (versi saat ini, lebih kecil, dengan dukungan penuh untuk audio imersif). Penyedia yang baik menguasai keduanya, memvalidasi sebelum distribusi, dan memantau perubahan spesifikasi DSP. Membangun mesin sendiri adalah beban perawatan yang tiada henti; bagi hampir semua orang, penyedia yang menangani feed dari pembuatan hingga distribusi, termasuk validasinya, adalah pilihan yang lebih baik. LabelGrid menangani distribusi DDEX untuk label dan distributor di seluruh empat versi ERN yang didukung, lengkap dengan akses API dan SOBO untuk katalog dengan kesepakatan langsung.
