Certain Arena XMI files do not loop correctly

[afritz1]

This problem was already mentioned in a comment by @psi29a regarding some XMI files from The Elder Scrolls I: Arena, but I thought I should add some more details here.

I played both OVERSNOW.XMI and SUNNYDAY.XMI on Windows 7 using wildmidi.exe version 0.4.0 with eawpats and the Timidity/Gravis config for wildmidi.cfg. Here's the Dropbox link for the XMI files.

The first XMI file in question, OVERSNOW.XMI, is incorrectly shown to be 4m 14s by WildMIDI, when it should be around 1m 24s or so. It keeps repeating the same sleigh bell instrument after the ending for about 3 minutes until it actually loops.

The second XMI file, SUNNYDAY.XMI, is shown to be 166m(!) 34s long, when it's actually only about 51s long. I haven't listened that long, but I assume it's just silence for the remaining 165 minutes.

Here is another issue related to XMI.

[chrisisonwildcode]

I'll have a look at the files later today. I'll also look into the other issue you reported.

Chris

Sent from my iPhone

On 28 Jul 2016, at 3:51 AM, Aaron notifications@github.com wrote:

This problem was already mentioned in a comment by @psi29a regarding some XMI files from The Elder Scrolls I: Arena, but I thought I should add some more details here.

I played both OVERSNOW.XMI and SUNNYDAY.XMI on Windows 7 using wildmidi.exe version 0.4.0 with eawpats and the Timidity/Gravis config for wildmidi.cfg. Here's the Dropbox link for the XMI files.

The first XMI file in question, OVERSNOW.XMI, is incorrectly shown to be 4m 14s by WildMIDI, when it should be around 1m 24s or so. It keeps repeating the same sleigh bell instrument after the ending for about 3 minutes until it actually loops.

The second XMI file, SUNNYDAY.XMI, is shown to be 166m(!) 34s long, when it's actually only about 51s long. I haven't listened that long, but I assume it's just silence for the remaining 165 minutes.

Here is another issue related to XMI.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

[chrisisonwildcode]

Working on looping tonight, my thinking is have a function that can set known looping format, such as xmi, as well as allowing for custom formats. So for instance.

WildMidi_SetLoop(int loop_option, char[4] data)

loop_option:

XMI_LOOP set loop command to xmi, data ignored
LOOP_START, data set to midi event that marks loop start.
LOOP_END, data set to midi event that marks loop ends.
LOOP_COUNT, data set to midi event that contains the number of times the loop should occur.
NO_LOOP, tells wildmidi to ignore looping instructions, data ignored

I will review our other existing formats to see if looping should be supported with those formats.

I am considering supporting looping by default in the formats that support it with the NO_LOOP being required if you don't want looping.

Comments?

[afritz1]

I'm no authority on a preferred interface for MIDI looping, though I imagine XMI_LOOP and NO_LOOP would be the most useful for my project. Maybe @kcat would have some suggestions.

In TES: Arena, the XMI music either loops infinitely, or plays a short fanfare song before switching to a looping song upon entering a city, so that's the behavior I'm most interested in.

[sezero]

I converted the xmi files into midi doing something like:
wildmidi -g 1 -x SUNNYDAY.mid SUNNYDAY.XMI

wildmidi crazily reports 133m:25s for the converted mid, however libtimidity plays it and reports 0m:47s.

As for OVERSNOW.mid (converted the same way from the xmi), libtimidity reports the same 4m:14s duration as libwildmidi.

[afritz1]

I tested some of Arena's XFM files with WildMIDI (there are XMI and XFM versions of every music file in Arena). Interestingly, the XFM versions of the two songs in question do not have any issues with looping, even though it seems the two file formats are similar from what I understand.

OVERSNOW.XFM plays for 1m 21s, and SUNNYDAY.XFM plays for 0m 48s. The durations are the same when converted to .MID format.

Here's a Dropbox link for those XFM files.

[psi29a]

Nice, good to know! Thank you!

[psi29a]

@afritz1 there have been recent fixes in wildmidi that effect how broken pats are rendered. Basically the 'fix broken pats' had an adverse effect on non-broken pats as well. Can you verify if there have been changes on your end (better, worse, same)?

[afritz1]

I built the latest commit (2e49573) with Visual Studio 2013 64-bit. Looks like it's the same (played in cmd.exe).

OVERSNOW:

• XFM: 1m 21s
• XMI: 4m 14s
• MID: 4m 14s

SUNNYDAY:

• XFM: 0m 48s
• XMI: 166m 34s
• MID: 133m 25s

It hasn't been a problem for me anymore since I've been using the .XFM versions of these files, but if this issue is eventually solved, I will happily switch back to the .XMI versions. They sound almost identical in any case.

[chrisisonwildcode]

Hmmm, will look into this and a number of others over the weekend. Promise to branch for testing by others before ending up in master this time :(

…

Sent from my iPhone

On 12 Jul 2017, at 4:36 am, Aaron ***@***.***> wrote: I built the latest commit (2e49573) with Visual Studio 2013 64-bit. Looks like it's the same (played in cmd.exe). OVERSNOW: XFM: 1m 21s XMI: 4m 14s MID: 4m 14s SUNNYDAY: XFM: 0m 48s XMI: 166m 34s MID: 133m 25s It hasn't been a problem for me anymore since I've been using the .XFM versions of these files, but if this issue is eventually solved, I will happily switch back to the .XMI versions. They sound almost identical in any case. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[psi29a]

In addition to this... there is also a problem with windows release binaries crashing while the debug binaries do not crash.
afritz1/OpenTESArena#69

@sezero Can you validate this?