VGMTrans SSEQ cannot extract certain songs about vgmtrans HOT 5 CLOSED

So here's the bug!

Spirit Tracks overworld theme uses 0x94 jump at the very beginning of each track, to jump to the relevant song section.

SeqTrack::AddLoopForever interprets it as a loop point end, and immediately bails out in both READMODE_ADD_TO_UI and READMODE_FIND_DELTA_LENGTH.

Because READMODE_ADD_TO_UI breaks, the hex dump terminates early.

Because READMODE_FIND_DELTA_LENGTH breaks, deltaLength is set to zero and the subsequent READMODE_CONVERT_TO_MIDI stopTime is zero, causing the MIDI conversion to terminate immediately.

The correct way to detect loops is to keep a set of which byte ranges you have already processed, and abort when you reenter a visited range.

That method won't abort incorrectly whenever the song jumps to an unvisited area.

One awful hack to sorta-kinda workaround the second (only) issue is to increase ConversionOptions::numSequenceLoops. However, this is absolutely not the correct fix. Guessing the number of non-jump loops to follow is not the correct fix. Correctly recognizing jumps vs loops is.

from vgmtrans.

The commit above improves the situation, probably. Can you test it and give a feedback here?

from vgmtrans.

It plays back properly now.
VGMTrans preview has missing/bad notes, the MIDI export is fine.
Both contain neither the intro nor the first-part repeat. I believe it may be a CPU-based jump.

from vgmtrans.

I think so too. (I haven't verify the details, though)

If those missing notes are caused by a CPU-based branch, I want to going to close this issue. If you have an opinion on a CPU-based branch, you can write it on issue #19.

from vgmtrans.

I checked the SSEQ hex dump: Each track has a leading unvisited segment (intro skipped by jump), and a later unvisited segment (skipped part A-A loop). Is it possible to modify SSEQ ripping to add custom rip from offset?

OH, it uses SSEQ if-else statements!

from vgmtrans.