BF:BC2 PC Res/dbx (mp3?) by pepper at 12:10 PM EST on March 1, 2010
the pc version of bf:bc2 appears to do the same method as the xbox360's xma, but with the mp3 codec. is there any way/chance of decoding this into a solid playable mp3 stream?
You're right that this is a bit different, but I don't think it's MP3 (or at least I see nothing that resembles MPEG headers). There seem to be 0x4c byte frames within the blocks, and if I assume the first value after the block size is sample count I can compute it with: (block_size - 8)/0x4c*((0x4c-0x10)*2+8) This, combined with the fact that the data looks like ADPCM past the first 0x10 bytes of a frame, which look like 8 samples of 16-bit little endian PCM, except for the really bizarre 0xC values in half of them in near-silent blocks. This could indicate a the history setup for a ridiculously high order linear predictor. As the sample count seems to take into account these samples, we probably get those samples for free. That 0xC values are a mystery, though; originally I thought they must be coefficient indexes, but in non-quiet frames we see negative numbers in these spaces. Maybe there are two channels, and one goes to 12 on silence instead of 0? I have the irritating feeling that I've seen something like this before but I can't place it yet.
i assumed mp3, mainly because the game's intro states it has licensed mp3 technology, and filestripper detects mpeg frames at different locations and bitrate values, ill see if i can get the specific hex offsets.
There seem to be at least two different types of audio here; one is the one I described above, which is characterized by a 0x14 before the samplerate. The other has 0x16 and seems to be something quite different. It looks like it has plain PCM samples but it doesn't work out at all playing it that way.
An important thing to note in these files is that the first 4 bytes of a block are the header, this gives the size of a block and some flags describing its type (in the high byte). The next 4 bytes (in an audio block, not a control block like the file metadata header) give the number of samples in the block. Much of my analysis will involve these sample counts.
In the 0x16 files, there's a bit of information to show where the PCM shows up. In BU_shg_Neostead_Reload_Out_3p_WaveDataSns_1.res: 0x0C: 44 00 06 2A 0x10: 00 00 02 40 0x14: 86 22 00 09 0x18: 01 9C The 01 9C is the number of bytes that follow that are "garbage", the rest of the bytes in the block are apparently PCM (total block size is 0x62A as given in the block header, so 0x62A-14-0x19C = 0x480 bytes or 0x240 samples, which if I understand correctly is the number of samples given in the second word of the header).
This also holds for the next block: 0x636: 44 00 06 30 0x63A: 00 00 02 40 0x63E: 82 28 00 09 0x642: 01 A2 (again 0x630-14-0x1A2 = 0x480 bytes, which again matches the 0x240 samples, and again this points right at the start of the PCM section.
Next block, though, is a different story: 0xC66: 44 00 06 36 0xC6A: 00 00 26 40 0xC6E: 01 E9 DC 77
As is the next: 0x129C: 44 00 06 16 0x12A0: 00 00 26 40 0x12A4: 00 64 DC 81
These blocks don't admit at all to the same kind of analysis.
The other 0x16 file, Explosion_XXL_Gas_LFE_01_WaveDataSns_1.res, might show more, since it has a lot of dead space at the beginning in which you can make out the headers. It may turn out to be that this format uses different encodings, able to switch between PCM and ADPCM for each block. I understand that EA has done this sort of thing before.
edited 4:09 PM EST March 1, 2010
First two blocks (Explosion_XXL) are identical: 0x0C: 44 00 04 97 0x10: 00 00 02 40 0x14: 84 8F 00 09 0x18: 00 09 AC 00 0x1C: 00 03 48 00 (and the rest is zeros)
The third block is where things get interesting: 0x93A: 44 00 00 4A 0x93E: 00 00 0D 80 0x942: 00 0B AC 00 00 03 48 00 00 00 00 0x94D: 00 0B AC 00 00 03 48 00 00 00 00 0x958: 00 0B AC 00 00 03 48 00 00 00 00 0x963: 00 0B AC 00 00 03 48 00 00 00 00 0x96E: 00 0B AC 00 00 03 48 00 00 00 00 0x979: 00 0B AC 00 00 03 48 00 00 00 00
and so on until the end of the block. Note that this is a very similar pattern to the one seen in the first block, however it is repeated 6 times and consequently there are 6x as many samples (0x240 vs. 0xD80). The first two bytes are consistently giving the number of bytes in the "subblock"; this is a method I've seen in EA's multi XMA streams, but here it seems to only be a single stream. Apart from that size specifier it seems to be showing about the same pattern. The gunk at 0x14 is confusing but I'll disregard that for now.
Now the only way it could compress down into this small space is by something like RLE. So why are the first two blocks so large compared to the third, which packs a bunch of stuff into one space? This seems to be some kind of "feature", this format is incapable of taking proper advantage of smaller block sizes on the first two frames. It's possible that this is initializing some sliding window for backreferences, I suppose, and RLE isn't actually supported. But in the other file, there's junk before the PCM. It seems to me that the zeros in this file, and the PCM in the previous file, are redundant to the actual compressed data. Which is why we see nothing like PCM after the first two blocks, and the block get much smaller. This will at least be helpful for some stages of testing...
Oh, and I don't think the .dbx files actually have audio data in them.
[edit] On reflection, it seems likely that 0x16 is the "new" EA Layer 3 after all. The header format does actually work out entirely consistently to how I'd looked at it before. The PCM is really just an oddity, then, though it occurs that it might be used to provide the first few frames that would ordinarily be discarded due to decoder latency, which might be important on wee little streams like these sfx. The silent bits at the start of Explision_XXL_Gas_LFE_01_WaveDataSns_1.res might be enough for me to figure out what crap I need to do to get these back to normal MPEG.
wow great work, if you need anything else from me, more files, etc. btw, is there anyway to donate to you/ the site? (wouldn't be too much, so dont get your hopes up, thinking around $25-$40, also not trying to pressure you with money, god this seems awkward...)
nice work hcs would be great to turn these crap ea layer 3 to normal mpeg.
donation by pepper at 2:49 PM EST on March 5, 2010
I'm completely serious about donating, I have $50 ready to go through paypal. and I don't care if my needs in this thread aren't met, this place is a wealth of info and deserves to be supported.
"The site owner won't be able to run off and spend your donation on DVDs, fine steak dinners, or anything else completely unrelated to their web hosting bill!"
i'm donating anyways, but this takes all the fun out of it!