Well, getting to the point, has anyone attempted or figured out the looping headers designed for .XWB/.XSB set files?
In any case... it will be .XWB files that are primarily examined for this. The files in this rip contains the loop information, which works based on trial & error with the Sound Test menu.
It seems to be an offset away (towards the end of the file) of 0x00000004 from the Sample Rate region. Loop information starts around here. At this moment, I'm examining the loop end portions... which seems weird going by how most loop headers are handled. Side note, the sample rate of the .XWB doesn't seem to be consistent with the unxwb.exe process, to which I have no idea if it's rounded in the process or there is some form of additional calculation involved.
Side note, it seems to be Little Endian byte order.
Anyways... this is assumption for now, but from trial and error, it does not seem to follow the typical loop information, which is:
•Loop Start Position + Loop End Position
Instead, I'm assuming it follows this:
•Loop Start Position + Remaining Sample Length's Cutoff Position (or Loop Length)
When adjusting the Loop Length region... these were some of the results I encountered:
•If the smallest byte position has a hex value of 0x00 (with the remaining bytes of this string being 0x00; in example, 00000000)... the song will have no "Remaining Sample Length's Cutoff Position," and the audio will loop accordingly from Loop Start Position until EOF.
•If the smallest byte position has a hex value of 0x01 ~ 0x7F (with the remaining bytes of this string being 0x00; in example, 7F000000)... then the game would freeze, and audio stops abruptly once it reaches the loop start position.
•If the smallest byte position has a hex value of 0x01 ~ 0x7F (with the remaining bytes of this string being 0x01 ~ 0xFF; in example, 7F010000)... then the game would play out just fine. However, there is absolutely no difference from having the first byte being 0x01 ~ 0x7F, since the test of hearing the looped "bzz-like" waveform did not change. In other words, in terms of hex, this implies that the smallest byte of this offset region goes up in increments of 0x80.
•If the smallest byte position has a hex value of 0x80 (with the remaining bytes of this string being any value)... then the game should play fine with the loop, regardless if the remaining bytes of this string is 0x00. In the case where the string value is 80000000, then a "bzz-like" loop should take place.
Based from this information... loop region information is as followed:
TLDR: For .pos/.logg/loop creations... a nifty script would be appreciated. The idea is to identify both the loop start position and the loop length. From there, add the two values (Little Endian, 4-Byte string, int32/uint32) to identify the loop end position. (.pos files, by default via in_vgmstream, follows Little Endian Byte Order, 4-Byte string... where the first string represents loop start position, and the second string represents loop end position)
Resources for XWB Loop Information (WIP)
EDIT: I'm guessing unxwb.exe leaves unnecessary junk data at EOF? Loop plays perfectly fine, but there is unnecessary sample data at the end. Even trial & error of increasing loop length acts up in-game, proving that there is unnecessary data at EOF. Most files seem to have junk data of 128 (decimal) samples at EOF.
edited 8:48 AM EST November 24, 2016