Problem decoding AAX (Nier DLC) by dag at 9:39 AM EDT on June 3, 2010
Hi, could you guys look into this AAX? It sounds mostly fine but inserts annoying noises every few seconds.
http://www.sendspace.com/file/bgs4ha
The quickbms .cpk script created incorrect files (split too soon or too late) but this one should be ok though I had to rip it manually... maybe CRI tweaked the headers somehow? Regular Nier AAXs sound perfect.
I don't know, it's really weird... looking at the data, it all seems to be valid ADX, it just gets really loud at spurts. It may be an error in the source data. Do you know if this track is actually used in-game? By the way, you might try my latest experimental utf_tab tools 0.7b1, they don't handle directories like aluigi's cpk scripts but maybe you'll have better luck with extraction.
edited 10:40 AM EDT June 3, 2010
Also, are these files compressed? This might indicate a bug in decompression.
I haven't played Nier's DLC but in Youtube videos they sound ok (there are 5 aax all with the same problem, if you need more samples).
I'm not sure if it's compressed, maybe that's the problem with unpacking and stuff. There is a big .cpk and inside another bgm.cpk. I located the AAXs in the data and since the file size in the AAX header seemed ok I thought I extracted it properly.
The talest cpk_unpack has the same problem as the script unfortunately (the files' sizes are the same, but the bytes differ; neither is ok though).
Here is the first few MB of the main .cpk and also the bgm.cpk (I could try to upload the whole thing if it helps but it's +300mb).
I retract my comment that the data looks valid, it rather looks like the stream gets out of sync. This reminds me of a bizarre issue from this thread, where text mode was being used and screwing up the stream. There are valid frames at 0x2AB84 and 0x2AB96, but the next one at 0x2ABA8 doesn't look right. It appears that the next valid header is just a bit further on, at 0x2ABB0, much closer than it should be, and things look good for a while after that. I don't see anything obvious to suggest just what the trouble is, though.
How confident are you that the CPK was originally extracted correctly? If there are random bytes thrown in or missing it would also explain why the extraction tools are missing the contents.
[edit] The last valid looking frame in the series starting at 0x2ABB0 is at 0x2CB9C. After that things get weird, starting at 0x2CBB4 there are 0x18 byte structures starting with 0x8000F3B7 and counting up from there. The last one is at 0x2DB8C, with 0x8000F460, mostly zeroes. This is just before the first good ADX frame at 0x2DBAE. My interpretation is that someone's overreading or overwriting a buffer and that this junk is from RAM.
FUUUUU *facepalm* Turns out the program I was using to extract files from the DLC (pirs/live container) was outputting crap, so the CPK was altered. Used another program and voila, regular CPKs and all. Oh boy I suck.
Sorry for the trouble, really. The least I can do is offer the music: http://www.sendspace.com/file/9ihtd1 (should be complete)