Luigi Auriemma

aluigi.org (ARCHIVE-ONLY FORUM!)
It is currently 19 Jul 2012 12:34

All times are UTC [ DST ]





Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 37 posts ]  Go to page Previous  1, 2
Author Message
 Post subject: Re: LEGO Indiana Jones 2 [XBox 360] - strange XMA format
PostPosted: 14 Dec 2009 03:42 

Joined: 14 Dec 2009 02:39
Posts: 3
Hello everyone!

I'm trying to extraxt the music from GH5,but I haven't succeded yet...

I tried everything you wrote, but nothing :S

Can anyone have a look at this XMA? http://www.megaupload.com/?d=FTPAKHUZ

It's probably a drum file that contains 4 music files (it is 8 channels I think)

If anyone could help me, I'd be so glad


Top
 Profile  
 
 
 Post subject: Re: LEGO Indiana Jones 2 [XBox 360] - strange XMA format
PostPosted: 14 Dec 2009 04:38 

Joined: 27 Nov 2009 20:34
Posts: 17
That's a normal multichannel XMA2.

xma_test music.xma -o 3e0 -r music_ch1.xma
xma_test music.xma -o be0 -r music_ch2.xma
xma_test music.xma -o 13b0 -r music_ch3.xma
xma_test music.xma -o 1be0 -r music_ch4.xma
Then add the stereo header from this post and decode with toWAV.
This little script for quickbms could help: http://www.sendspace.com/file/ohodf3

But for the future, please ask those questions via PM and don't post here.


Top
 Profile  
 
 Post subject: Re: LEGO Indiana Jones 2 [XBox 360] - strange XMA format
PostPosted: 14 Dec 2009 10:54 

Joined: 14 Dec 2009 02:39
Posts: 3
ok, thank you, and sorry for posting


Top
 Profile  
 
 Post subject: Re: LEGO Indiana Jones 2 [XBox 360] - strange XMA format
PostPosted: 14 Dec 2009 13:24 

Joined: 27 Nov 2009 20:34
Posts: 17
Gyuszi999 wrote:
Ok, thank you for your help, but I have a final question...

For now, I understand the procedure: -finding out block size, data offsets
-parsing
-rebuild header (with the one you said)
-decode with Towav

The file I've sent is decoded now,it works, I think.

But when I try to decode the next file...

First, I'm trying to find out the first offset: I open file with HEX editor, and I search "data"; the address after the closing "00" byte should be the first offset, but the parser doesn't work with that offset (maybe the block size is fidderent??)

So, please tell me the algorythm of finding out these numbers

I've read all the things you wrote, but it's still not clear for me :S

Thank you for your answer, and sorry for being such slow xD

I think these questions are important enough to be posted here!
Regarding the offset: the data starts four bytes after 'data' (which contain the size of the encoded stream)
Regarding the block size and the other offsets (anyone please correct me if I'm wrong here and I'll change the post): Well, first you'll have to find out which type of XMA file it is. To simplify the procedure, you may delete the header and save the file under another name. The end of each block normally consists of placeholders (FF bytes), the next block starts at an even offset (0x__0). The block size is the difference of the start of the succeeding and the current block. That's also the offset plus for the parser command.
For example:

data starts at 0x600 = start of first block
second block starts at 0xE00 => first block has size 0x800
third block starts at 0x1E00 => second block has size 0x1000
fourth block starts at 0x2E00 => third block has size 0x1000
fifth block starts at 0x3600 => fourth block has size 0x800 = size of first block

Now if the cycle repeats here (i.e. the following block sizes are again 0x1000, 0x1000, 0x800 and so on) the block size is the size of one complete cycle: 0x800 + 0x1000 + 0x1000 = 0x2800 (you may also consider to read this post: post8740.html#p8740. It's a bit technical but shows a simple algorithm which you can use in parts for a manual analysis). If you don't know how many channels the stream has, check out the next block (fifth). In the above example it could have a length of 0x800, so the cycle would be 800:1000:1000:800 and thus the block size would be 3000. Correct me if I' wrong: If the chunk size is always 800, the block size is 8000 (for the command line: leave out the "-b" option).
Parsing the example from above would mean the following commands for 6 channels:

xma_test example.xma -o 600 -b 2800 -r example_ch1.xma
xma_test example.xma -o E00 -b 2800 -r example_ch2.xma
xma_test example.xma -o 1E00 -b 2800 -r example_ch3.xma

or for 8 channels

xma_test example.xma -o 600 -b 3000 -r example_ch1.xma
xma_test example.xma -o E00 -b 3000 -r example_ch2.xma
xma_test example.xma -o 1E00 -b 3000 -r example_ch3.xma
xma_test example.xma -o 2E00 -b 3000 -r example_ch3.xma

respectively. Hope I could help. =)


Top
 Profile  
 
 Post subject: Re: LEGO Indiana Jones 2 [XBox 360] - strange XMA format
PostPosted: 15 Dec 2009 23:32 

Joined: 14 Dec 2009 02:39
Posts: 3
thank you for all your info

I tell you what I've found out about GH5 musix files

every track has 3 file song_1.fsb.xen,song_2.fsb.xen,song_3.fsb.xen

first, you have to make FSB-s from XEN-s (XEN->FSB) (it's a decription)

then, you have to extract the first FSB ("fsbext.exe -a song_1.fsb")

the file that comes out ("multichannel audio") is a multichannel XMA, it has 4 stereo channels in it, so you have to build 4 .XMA files from it with the parser

the block size for GH5 files is always the default, so you don't have to deal with it

you have to find out the first offset (by searching "data" in file) => parser => 1. XMA

and here's a thing that makes the whole thing easy: for GH5 files, the difference between offsets is always 0x800, so if you found the first, you know all offsets

for example: first is 0x100 => 2.: 0x900 => 3.: 0x1100 => 4.: 0x1900

so you have 4 rebuilt XMA-s => you put head at the beginning of each XMA => decode with towav => you have 4 drum tracks

song_2.fsb contains another multichannel audio (3 stereo files: leadguitar,bass,vocal mostly in this order)

you can extract them exactly the same way than the first fsb (offset-difference is still 0x800)

song_3.fsb : 2 stereo files (first is for rhythm guitar, and all other sounds in music (keyboads, sound effects), and second is for the crowd's voice (sometimes it's just silence, so it's worth to check it after extraction)

that's all I know about GH5 XMA-s, but I think it's enough :D

have a nice evening :D


Top
 Profile  
 
 Post subject: Re: LEGO Indiana Jones 2 [XBox 360] - strange XMA format
PostPosted: 16 Dec 2009 04:16 

Joined: 16 Aug 2009 19:24
Posts: 29
Location: Austin, TX
Quote:
and here's a thing that makes the whole thing easy: for GH5 files, the difference between offsets is always 0x800, so if you found the first, you know all offsets


Just fyi, this is true for any well-behaved XMA2 stream. At the beginning of any block (including the first one) there is one packet (0x800 byte chunks) from each stream, though later in the block they may be intermingled in different ways.

The block size is generally specified in the header somewhere, I like to look for a value like 00 00 30 00 or 00 01 00 00 sticking out somewhere in there. If nothing works I find it easiest to just check each multiple of 800 until the parser accepts it.


Top
 Profile  
 
 Post subject: Re: LEGO Indiana Jones 2 [XBox 360] - strange XMA format
PostPosted: 29 Dec 2009 05:10 

Joined: 27 Nov 2009 20:34
Posts: 17
hey there! I've lately encountered this XMA file here: http://www.sendspace.com/file/l95tsi
The data starts at offset 1974 and all chunks have a length of 800. Nevertheless, no block size I've tried works (the "zero frames on this packet" error). Isn't this just a normal XMA2 stream? What's with the huge chunk at the beginning? Could this be a kind of encryption?

Thanks for your help!


Top
 Profile  
 
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 37 posts ]  Go to page Previous  1, 2

All times are UTC [ DST ]


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
cron