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
As a test I compared the output of both and found there is some difference between then.
I tested ADX, MP3 and AT3p and seems some samples are +-1 byte off, but Atrac3plus can be a bit more different (not really audible).
I don't know enough about audio decoding to find in the sources which one is "better" though.
Not sure if somebody noticed before so I wanted to bring it up, since I was tweaking FFmpeg support in vgmstream.
unxwb extracts the file but when I try to parse the extracted file(either with headers or not) it just doesn't work.
https://drive.google.com/open?id=0B-YcY ... zNseWRIbjA
Thanks to anyone who is willing to help!
I've downloaded the rar from the pinned thread and extracted with unrar. Everything in the \stream folder plays just fine in foobar but i've yet to find a way to play the rest (the most notable missing track being the Great Sea theme).
I have a bfsar file (some kind of soundfont type of thing, i think?) as well as a \JAudioRes folder with asn, aaf, bdt & aw files that i don't know what to do with.
Am i even on the right track here? I've spent over an hour searching the forum and google with nothing to show for it. I'd appreciate any help.
https://www.sendspace.com/file/6yxx2w
(ie.- works for others? WinXP? AT3 loop hiccups in older systems?)
Basically now enables FFmpeg in Windows for AT3/AC3/AAC/OMA/MSF/whatever support (may need some renaming, see changelog.txt), also can load ADX/HCA keys externally.
at3plusdecoder.dll isn't used and there 3 new FFmpeg DLLs (only enable common VGM formats but can be swapped with full DLLs).
foobar2000 will probably be updated after some FFmpeg issues are sorted out.
I'm thinking of adding some more stuff like XWB/XMA later and some random ideas.
Winamp can't play 5ch btw (any Winamp expert?).
This PS1 game uses .smp/.snd files for sequenced music. So if that's not a problem to you, can I ask anyone to reverse-engineer these files so that they can be played back as MIDI or PSF?
Here are the samples.