Home › Datasets › Music Generation Prompting
AI Music & Audio PackHow to Fine-Tune an LLM for AI Music Generation Prompting
Writing structured prompts for AI music generation — genre and mood language, song-structure scaffolding, vocal style control, and platform-specific dialects across Suno, Lyria 3, and Stable Audio 3.
- 658 instruction-response pairs
- Format JSONL
- Pack AI Music & Audio
- Dataset $39 one-time
$39 for the dataset. Training is priced separately by model, starting at $47.
What can this kind of fine-tuning teach an LLM?
A general-purpose model may already know some of this subject. Fine-tuning serves a different purpose: it repeatedly demonstrates the kinds of requests, response patterns, terminology, decisions and workflows you want the model to handle more consistently.
For Music Generation Prompting, the dataset focuses on writing structured prompts for ai music generation — genre and mood language, song-structure scaffolding, vocal style control, and platform-specific dialects across suno, lyria 3, and stable audio 3. Fine-tuning shapes recurring model behavior; it does not turn the model into a live database or guarantee correctness on every new case.
What training data should cover
Useful supervised fine-tuning data should resemble the work you expect the model to perform. This Rebiha dataset's domain definition is organized around 17 coverage areas:
- writing genre and mood language that actually steers a music model's style rather than being ignored; scaffolding a full verse-chorus-verse-chorus-bridge-chorus structure explicitly since models default to loose, incoherent form; writing tempo, key, and instrumentation specifications a model will respect; controlling vocal style — gender, tone, delivery, genre-appropriate phrasing — through prompt language; writing an instrumental-only prompt that avoids accidental vocal generation
- adapting one musical concept's prompt across Suno's natural-language style versus Stable Audio 3's parameter-driven style; writing a prompt that references a production era or sonic aesthetic without naming a copyrighted artist or song; troubleshooting a generation that ignores the requested tempo or time signature; writing prompts for a short looping track versus a full structured song; specifying instrumentation layering — which instruments enter and exit at which structural point
- writing a prompt for image-to-music or mood-board-to-music generation where supported; diagnosing why a generated track's energy doesn't build the way the prompt intended; writing prompts for background/ambient tracks meant to sit under dialogue or narration; explaining the trade-off between a transformer-based model's structural coherence and a diffusion-based model's textural richness; writing a prompt for a specific runtime length and structuring the arrangement to fit it
- iterating a generic, ignored prompt into one with enough specific constraint to work; writing prompts that avoid common AI-music artifacts like phasing, muddy low-end, or robotic vocal timing
How Rebiha prepared the training material
This page contains 658 instruction-response pairs from the existing Rebiha dataset. Its domain definition was designed around the coverage areas above so the training material spans multiple realistic tasks rather than one narrow prompt pattern.
Rebiha's broader dataset workflow uses structured quality review to help identify problems such as contradictions, unsupported claims, unsupported assumptions, calculation errors and other weak training examples. You can inspect real examples on this page before deciding whether the dataset fits your model and use case.
What is in this dataset
658 instruction-response pairs covering writing structured prompts for ai music generation — genre and mood language, song-structure scaffolding, vocal style control, and platform-specific dialects across suno, lyria 3, and stable audio 3. Each pair is a realistic instruction with a full written response, in the JSONL format used for supervised fine-tuning. No synthetic filler, no duplicated rows.
Example pairs
Real rows from the dataset, shown in full.
When I write something like 'upbeat pop song with happy vibes' in Suno, I just get generic slop. How do I write genre and mood language that actually steers the model instead of getting ignored?
The core problem: vague adjectives like 'upbeat' and 'happy' are so statistically common in training data that they barely move the model. You need to trade generic mood words for genre-specific vocabulary, era references, and production descriptors that narrow the distribution. Three techniques that actually steer: 1. **Anchor genre with a subgenre + era + production lineage.** 'Pop' is a blender. '1980s synth-pop with gated reverb drums, glassy Juno pads, and a chorused fretless bass' is a coordinate in latent space the model can hit. 2. **Replace mood adjectives with sonic consequences.** Instead of 'happy', write the texture that produces happiness: 'bright major-key piano stabs, ascending vocal hook, handclaps on the backbeat.' Mood is an effect; describe the cause. 3. **Stack three to five genre tags, not one.** Models respond well to a narrow overlap: 'dream pop + shoegaze + slowcore' lands somewhere specific; 'pop' lands everywhere. Example Suno prompt: ``` [Genre: 90s trip-hop, dark downtempo, Bristol sound] [Mood: nocturnal, smoky, restrained tension — not aggressive] [Production: dusty vinyl crackle, deep sub-bass, sparse breakbeat, Rhodes chords, muted trumpet] [Tempo: 85 BPM] [Vocals: breathy female, close-mic'd, half-spoken delivery] ``` Note the mood line still exists but is qualified ('restrained tension — not aggressive') so the model knows what to avoid. Negative framing helps when a mood word is ambiguous. If the model keeps drifting bright, add an explicit contrast: 'minor key throughout, no uplifting resolution.'
My Suno generations always come out as a loose blob — it never gives me a real verse-chorus-verse structure. How do I force a proper song form?
This is the single biggest weakness of diffusion/transformer audio models: they optimize for local plausibility, not global form. Without scaffolding they default to 'vibe for 2 minutes.' You have to impose the architecture yourself. Use bracketed structural tags as section markers, in order, and keep them terse and conventional. Suno and Lyria both parse these as section boundaries: ``` [Intro: 4 bars, filtered pad, no drums] [Verse 1: sparse, bass + soft kick] [Pre-Chorus: build, add toms, rising synth] [Chorus: full arrangement, wide stereo, hook vocal] [Verse 2: same as verse 1, add subtle strings] [Chorus] [Bridge: strip back to piano + vocal, key change up a step] [Final Chorus: double-tracked vocals, add octave lead] [Outro: fade on the pad] ``` Key rules that make scaffolding actually hold: - **Name every section explicitly, in order.** Don't write 'verse and chorus' — write them as discrete lines. - **Describe the arrangement delta per section.** The model needs to know *how* the chorus differs from the verse (fuller? louder? higher vocal?). 'Chorus: same as verse' produces a flat song. - **Cap your section count.** Six to nine sections is the sweet spot for a 2–3 minute generation. More than that and the model starts merging them. - **Repeat the chorus tag verbatim.** Consistent labels ('[Chorus]' every time, not '[Big Chorus]' once) help the model recognize it as the same section returning. For Stable Audio 3, which is less tag-native, express the same scaffold in prose: 'A 2:30 pop song in strict verse-chorus form: intro, verse, pre-chorus, chorus, verse, chorus, bridge, final chorus, outro — each chorus returns the same melodic hook.' The structure must be stated as a formal constraint, not implied.
How specific can I get about tempo, key, and instruments before the model just ignores me? I want to actually control these.
Tempo, key, and instrumentation are three of the *most* respected prompt dimensions — but only when written in the model's expected notation. Loose phrasing gets ignored; precise phrasing gets followed. **Tempo.** Always give a BPM number *and* a feel word, because the model uses the feel word to interpret the number: - Weak: 'fast tempo' - Strong: '124 BPM, driving four-on-the-floor' - Also strong: 'slow, dragging half-time feel at 70 BPM' **Key and mode.** State the root and the mode explicitly. 'Sad key' does nothing; 'F minor, natural minor, no borrowed chords' pins it. For modal color, name the mode: Dorian, Phrygian, Lydian. If you want a key change, say where: 'modulates to G major for the final chorus.' **Instrumentation.** List instruments by name *and* by role/register, and cap the list. Five to eight instruments is controllable; twenty turns to mush. Give each one a job: ``` [Key: F# minor, natural minor] [Tempo: 92 BPM, half-time backbeat] [Instrumentation: - Deep sub-bass (root notes only, no fills) - Rhodes electric piano (mids, chord stabs on the off-beat) - Brushed kit (soft snare on 3, no crash cymbals) - Muted trumpet (sparse counter-melody, verse only) ] ``` Two more rules: (1) If you name an instrument, give it a behavior — 'brushed kit, no crash cymbals' beats just 'drums.' (2) Avoid contradictory specs; '92 BPM half-time' plus 'fast punk energy' will make the model average them into something incoherent. Everything in the prompt should point the same direction.
Who this is for
Builders who want their fine-tuned model to reliably perform this specific capability, as part of a broader assistant or agent.
Which models this works with
The dataset is plain JSONL, so it works with any instruction-tuned open model. On Rebiha you can train it directly on:
- Qwen — Qwen3.8, Qwen3.6, Qwen3.5, Qwen3, Qwen2.5, Qwen2.5-Coder
- Granite — Granite 4.1 (3B, 8B, 30B)
- OLMo — OLMo 3, OLMo 3.1
- GLM — GLM-4
- Gemma, Phi, DeepSeek, Mistral, and Llama families
Training uses LoRA, or QLoRA on a 4-bit base for larger models. Your base model's weights are never modified — training produces a separate adapter.
How it works
- Pick this dataset and a base model.
- Rebiha runs the job on a managed GPU. You set up nothing.
- Download your model: a ready-to-run GGUF, plus developer assets (adapter, tokenizer, configs).
Fine-tuning or RAG?
Use RAG when the model needs facts that change — your prices, your documents, today's inventory. Use fine-tuning when you want consistent behavior and structure without prompting for it every time. This dataset teaches the shape of this capability, not facts to look up.
How managed fine-tuning works
- Inspect the dataset examples and choose a compatible base model.
- Rebiha runs the training job on managed GPU infrastructure using LoRA or QLoRA as appropriate.
- Download portable model assets for your own workflow, including the available ready-to-run and developer outputs for the selected training path.
Fine-tuning or RAG?
Use fine-tuning when the objective is recurring behavior: response structure, domain patterns, terminology, workflow, or how the model approaches a class of requests. Use RAG when answers depend on changing or proprietary facts that should be retrieved at request time. The two approaches can also work together.
Know what goes in. Own what comes out.
You can inspect real examples before training, choose the model you want to adapt, and keep portable model assets when training is complete.
Related datasets
- General Instruction Following — 978 pairs
- Multi-Turn Conversation — 466 pairs
- Rewriting & Editing — 854 pairs
- Summarization — 781 pairs