Need a unique gift idea?
A Pastebin account makes a great Christmas gift
SHARE
TWEET

Untitled

a guest Feb 28th, 2011 227 Never
Upgrade to PRO!
ENDING IN00days00hours00mins00secs
 
  1. .SSEQ looping. Many people have been wondering what the heck to do to make their songs loop. Well, I may have found the answer.  Today, I was looking at an information consolidation on the .SSEQ file type, and I found out that it showed where "jumping" or "looping" occurs. So I cracked open HxD and modified a .SSEQ file. I started out small, editing the loop point of one track as opposed to all of them (the first track to be precise), and I found that the jump was located near (but not at) the end of the track for the normal wild pokemon encounter/battle (oddly this does not apply for version two of the encounter; it's at the very end for all of them to my knowledge). The file, as you may know or not know, is SEQ_BGM_VS_NORAPOKE.SSEQ, and the "jump (with count)" for the first track is 94 1D 02 00 FF (note: in VGMTrans, "jumps" highlighted yellow and starting with 95 are actually "calls"). I concluded that the "FF" was the end byte (as in, it was the byte that marked the end of the call command). In addition, 94 was what initiated the jump/loop command in the first place. What's self it the 1D 02 00. Well, I found out this is actually the offset in the .SSEQ file in little-endian (or refersed hex if you prefer) that marks the offset where the track will jump to for that one track. So, the offset would actually be 00 02 1D. 21D, as I found out, was the beginning of a volume change in the song, but after a program change (or instrument change). I assumed it was put there because the tracks instruments shift before the volume of the overall track shifts. So, I looked for a similar value to this, and I found that 3FB started a volume change, and was also after a program/instrument change. Therefore, I changed the string of text from 94 1D 02 00 FF to 94 FB 03 00 FF. The end result? When the music hit its loop point, the first track, noticeably, shifted to a later part of the track (it ended up looping to a point ahead of the other tracks). So, I have successfully edited a loop. I am unsure if my findings were previously recorded or tested on a Pok√©mon game, but in any case I hope for this to be helpful to any composers out there.
  2.  
  3. Now something I didn't figure out that is crucial to making this work correctly... Track offsets. I don't know how these work at all, but I hope someone here does. Apparently, the track offset is 93 01 5F 07 00 for the first offset of the first track in SEQ_BGM_VS_NORAPOKE.SSEQ. 93 is the command for pointing out the track, 01 is the track's number in hex form (obviously), and 5F 07 00 is the tracks offset. In what? I have no clue. I assumed little-endian at first but 75F isn't anywhere NEAR the beginning of the track! The track's actual beginning, according to VGMTrans, is suppose to be 51, but the way it got that calculation dumbfounds me. I looked into the source code, but no dice. See if you can decipher this:
  4.  
  5. while (b == 0x93)        //Track/Channel assignment and pointer.  Channel # is irrelevant
  6.         {
  7.             TrkPtrs->AddSimpleItem(offset, 5, L"Track Pointer");
  8.             ULONG trkOffset = GetByte(offset+2) + (GetByte(offset+3)<<8) +
  9.                                 (GetByte(offset+4)<<16) + dwOffset + 0x1C;
  10.             NDSTrack* newTrack = new NDSTrack(this, trkOffset);
  11.             aTracks.push_back(newTrack);
  12.             //newTrack->
  13.             offset += 5;
  14.             b = GetByte(offset);
  15.         }
  16.  
  17. If you can understand what that means in C++ you win a cookie and my respect, because if you can't reconfigure the track pointers, you can't add the loop points. At all. I asked my friend JTE for help but this is all he could tell me...
  18.  
  19. [QUOTE]I'm assuming b is an unsigned char, it reads hexadecimal 93, ... it adds the offset to something called TrkPtrs which I assume is a list of track pointers... the trkOffset is the three bytes after the 0x93 plus the dwOffset and static 0x1C.. it uses that offset to read it into an NDSTrack structure and pushes that into the list of tracks, then continues happily on its way reading the next track pointer...[/QUOTE]
  20.  
  21. Personally that didn't help me at all, but if it helps you guys, please leave a response. I'm sure you'd help not only clueless me, but any other composers wishing to put in loops.
  22.  
  23. Regards,
  24.      -Chimera
RAW Paste Data
We use cookies for various purposes including analytics. By continuing to use Pastebin, you agree to our use of cookies as described in the Cookies Policy. OK, I Understand
 
Top