USDX export: improving line breaks

[MairusuPawa]

Hello!

When exporting to the Ultrastar file format, Composer is a bit aggressive with line breaks. As suggested by the UI, line-breaks occur concurrently with the beginning of the line itself (shared timestamp); this means the lyrics will suffer from clipping in fixed-text karaoke softwares, such as Ultrastar or Vocaluxe. The issue is far less noticeable in Performous.

Clipping in Ultrastar usually occurs when the line breaks happen within 1 or 2 beats of the closest txt line. Clipping might occur either at the end of a sung line if the linebreak is too early ("bubbles" won't even register), or at the beginning (late page-break) leaving the players off-guard.

Another editor (YASS) offers to autocorrect this issue by moving line-breaks approximately half-way between song beats. If there's a large gap in the song, the break is defined closer to the previous line (ie "span 10 beats after the previous line, add line-break"). Additionally, long gaps can be defined by a starting position and an ending tag, fading out the UI.

Sample Composer output:

---

// : 4811 6 52 the // : 4820 12 49 way // : 4836 6 47 she // - 4852 // : 4852 15 44 flies // : 4867 7 43 ~ // : 4874 8 44 ~

---

Corrected output would be approximately like:

---

// : 4811 6 52 the // : 4820 12 49 way // : 4836 6 47 she // - 4844 // : 4852 15 44 flies // : 4867 7 43 ~ // : 4874 8 44 ~

---

And, again, thanks a lot for publishing Composer! :)

[tapio]

Hmm, looking at the code, the line break time stamps are actually inserted at the end of the previous line (and that code doesn't seem to have changed since the first version), here's a sample output:

: 2 6 24 When 
: 9 6 24 exporting 
: 16 6 24 to 
: 23 6 24 the 
: 29 10 23 Ultrastar 
- 39 40
: 48 6 14 file 
: 57 10 24 format, 
- 67 68
: 73 6 15 Composer 
: 79 5 24 is 
: 85 5 24 a 
: 91 5 24 bit

In fact, I noticed it also outputs another value to the line break lines, which I don't know why because format references and other songs don't have it. I wonder why your composer output sample does not have it either. In any case, I removed it in git master.

Did I understand correctly that neither immediate sleep after a line nor a sleep just before a new line is good?

[MairusuPawa]

My bad! That file had been tampered with another editor. The behavior you describe (end of previous line) is indeed the current one. This leads to early page breaks indeed, and causes clipping in songs.

You did understand correctly that a line break right after a line nor before a new line is good. Both have issues - the most noticeable one being early page breaks. Ideally, the line breaks would occur right between the lines when there are short gaps (to be defined)(arithmetic mean?), preferably at least two beats after the end of the previous line. For longer gaps, this needs to happen sooner than the arithmetic mean (something like 15 beats after the previous line and 40 beats before the new one maybe?).

[tapio]

In 92577a6fdcd6205beb402334f2f143aae446c7c6 the sleeps are now in the middle of the gaps. Could you elaborate on why it needs to be closer to the previous line with large gaps?

On a sidenote, I'm puzzled why some other software look at sleep note timings so closely. In Performous, they solely mark line breaks in lyrics. All UI fading, lyric appearing/disappearing etc. is automatically deduced by looking at the actual note timestamps, so where ever the note author (or exporter) decides to slap the sleep, the lyrics will not ambush the singer.

[MairusuPawa]

Some other softwares don't handle this nicely, either because of their age (Ultrastar) or number of maintainers (Karaokii). This might be the case of Vocaluxe too, due to legacy code - did not check as it requires .NET. These applications solely relies on the file itself.

Large gap may need to be handled differently, as the software may not know when to fade the UI and/or make it re-appear. It may also "ambush" the singer. UltrastarDX, at least, does not handle large gaps on its own, for instance.

I've found that YASS handles such file format issues rather gracefully (the "Check errors" window). I must admit I'm not keen on it when it comes to editing karaoke files, but it works great for debugging specific use cases and ensure maximum compatibility with the USDX file format. This might be useful: http://www.yass-along.com/errors.html (but out of date, ie the #ENCODING: tag is unlisted).

[MairusuPawa]

Tested, functional. Composer now produces files that won't break gameplay on other Karaoke engines (USDX, and potentially Karaokii and Vocaluxe). Thanks!