The Score Knows How Long the Song Will Be
A twenty-run replication retracts a style-prompt finding published three days earlier, confirms that a YuE2 score predicts its rendered length within 2%, and shows a score edit moving one 13-second passage and nothing else.
TL;DR — The symbolic score predicts the rendered song's length to within 2%%, which means you can check a generation in twenty seconds instead of two minutes — and a finding I published three days ago about style-prompt length turned out to be noise from a sample of two.
I have been running YuE2 locally on one RTX 5080 and writing down what I learn. This is the second batch: forty-nine generations across ten experiments, all on the project's own Python runtime. Two things I believed turned out to be wrong, three turned out to be solid, and two levers I expected to matter did nothing at all.
The score tells you the song's length before you render it
The runtime's inspection tool reports a nominal_duration_seconds for any score. I compared that number to the actual audio for sixteen songs:
| Song | Score says | Audio is | Error |
|---|---|---|---|
| 01_ko_kongkong | 107.8 s | 105.6 s | −2%% |
| 02_ko_kungjjak | 139.7 s | 139.5 s | −0%% |
| 05_en_ping_pop | 127.3 s | 126.8 s | −0%% |
| t5_s1 | 156.4 s | 155.8 s | −0%% |
Sixteen out of sixteen inside 2%%. The renderer plays the score; it does not decide anything about duration.
That changes the workflow. Planning a score takes about twenty seconds; rendering the audio takes about two minutes. So you plan first, read the predicted length, and only pay for the render if the score is long enough. I have folded this into a small candidate picker: generate four plans, throw away the short ones before they cost anything, render the survivors, and drop any take whose transcript comes back empty.
Editing one passage changes only that passage
This is the capability I had not tested at all. I took a finished song, opened its exported score, raised thirty-two notes in the final chorus, and resubmitted the edited file as the composition.
The result is exact. Of 276 vocal notes, 32 changed — the ones I touched, at positions 214 through 245, which fall between 2:05 and 2:18 in a 2:36 song. I separated the vocal from both renders and measured the pitch:
| Window | Original | Edited | Difference |
|---|---|---|---|
| 2:05–2:18 (edited) | 417 Hz | 463 Hz | +1.8 semitones |
| 1:40–2:00 | 415 Hz | 415 Hz | 0.0 |
| 0:00–1:00 | 415 Hz | 415 Hz | 0.0 |
The control windows match to the hertz. I intended a clean +2 and got +1.8 because my own transposition script misread some pitches — the native notation propagates an accidental across octaves by letter name, a rule the documentation warns about explicitly, and my reader did not implement it. The editing feature worked; my tool was wrong.
Why my cover attempt failed
I had been covering released songs the wrong way: feeding a score that still carried its chord symbols while telling the model to treat it as melody only. Fixed that, stripped the chords properly, and ran it again. It still failed — but now the reason is measurable.
| Cover source | Notes in melody | Syllables I supplied | Notes per syllable | Lyric fidelity |
|---|---|---|---|---|
| Song A | 643 | 185 | 3.5 | 5%% |
| Song B | 440 | 185 | 2.4 | 14%% |
I gave it Korean lyrics. The transcript comes back as English-sounding nonsense — "Come on, wing go go" — because a real pop melody is far denser than my lyric sheet, and the model fills what the words cannot reach. The rule I found earlier holds: keep notes per syllable between about 1.0 and 1.3. A cover needs a lyric written to the original's syllable count, not a lyric borrowed from elsewhere.
The finding I am retracting
Three days ago I wrote that a long prose style prompt beat the compact comma-separated form the documentation recommends — 47%% lyric fidelity against 25%%. That was one pair of runs. I redid it properly: four prompt lengths, five seeds each, twenty generations, everything else fixed.
| Style prompt | Lyric fidelity (5 seeds) | Mean | Song length |
|---|---|---|---|
| 20 words | 32 · 34 · 39 · 43 · 65 | 42.6% | 128.0 s |
| 40 words | 20 · 33 · 42 · 47 · 65 | 41.4% | 136.8 s |
| 80 words | 26 · 39 · 46 · 49 · 84 | 48.8% | 145.0 s |
| 160 words | 26 · 39 · 49 · 61 · 78 | 50.6% | 138.8 s |
The spread between the four means is 9.2 points. The average standard deviation inside each group is 17.9. The noise is twice the signal. Style-prompt length has no effect I can demonstrate, and my earlier claim was a coin flip I mistook for a result.
Song length does drift upward from 20 to 80 words, but the within-group spread there is 9 to 19 seconds, so I am not claiming that either.
Two levers that turned out not to be levers
The decoder. YuE2 ships two: one for listening, one that the published benchmark used. I decoded the same cached latents through both — no regeneration, so the music is identical and only the decoder differs. Band energy differs by at most 0.4 percentage points, dynamics match to one decimal, waveform correlation is 0.954 to 0.991. The benchmark being measured on the other decoder does not change how you should read your own results.
Score validity. I ran all eighteen of my scores through the project's own validator. Eighteen passed. A structural concern I raised earlier — about compressed multi-bar rests carrying a chord — is not something the validator objects to, and I had overstated it.
FAQ
How do I stop wasting renders on songs that come out too short?
Plan the score first and read its nominal duration. Across sixteen songs that number predicted the final audio length to within 2%%, and planning costs about twenty seconds against two minutes for a full render.
Can I change one section of a finished YuE2 song without redoing the rest?
Yes. Export the score, edit the notes you want, and resubmit it as the composition. In a controlled test, 32 of 276 notes changed, the edited window moved up 1.8 semitones, and two control windows measured identical to the hertz.
Does a longer, more detailed style prompt produce better results?
Not measurably. Across twenty runs at four prompt lengths, the spread between group means was 9.2 points of lyric fidelity while the standard deviation within each group was 17.9. Any single comparison is dominated by seed variance.
Why does a cover ignore the lyrics I give it?
Almost certainly because the source melody has more notes than your lyric has syllables. A released pop melody measured 643 notes against the 185 syllables supplied — 3.5 notes each — and lyric fidelity collapsed to 5%%.
Is it worth switching YuE2 decoders?
No. On identical latents the two decoders differ by at most 0.4 percentage points of band energy, with waveform correlation above 0.95.
Sources: YuE2 repository, generation docs, ABC editing reference, benchmark results.
Image: Klaus-Dieter Keller, Galton box, Public domain, via Wikimedia Commons.
← Back to all posts