Is where anybody who can give me some good informations about the EALayer3 mpeg from Electronic Arts ?... It seems that EA don't give any information about this codec and all informations we can get from Wiki or else are out of date, obsolete, etc...
Is this codec / compression algorithm Confidential Defense ? lol
Thanks for your support and advices ... I see that I've only one way : reverse engineering because
ffmpeg is great but can't master this kind of compression
No matter as soon as I find something interesting, I give you feedback.
I've been looking at this a bit tonight, someone had sent me a sample of EA Layer 3 (I think from some C&C) called 166b084d.46410f77.03cfdd8a.96acd5f2.cdata. I notice that it has the same kind of layout as EA's packed XMA thing, where it stores short frames/packets. Unfortunately there's nothing resembling a standard MPEG-1 audio header there, so I'm having to poke around at random.
Pretty confident about the overall stream layout:
0x00-0x03: total frame size (including header, thus offset to next frame, if this is the last frame high bit is set)
0x04-0x07: samples in this frame (for layer 3 the first frame has a low count due to the decoder latency and the last frame has a high count due I guess to the same thing, all the frame in between have either 1152 or 2304 samples so one or two complete MPEG-1 frames).
I don't know how many of the following bytes are part of the header or which are the beginning of the MPEG frame body:
0x08: 00
0x09: 0xd4 or 0xd6 (in my sample file its d4: 1652 d6: 1435, very roughly an 8:7 ratio)
0x0A: a small byte value, never goes about 0x4e
Looking at the frame sizes, there is never a single frame (that is, a frame in this stream layout containing only 1 MPEG frame, distinguishable by the sample count, and 2304 sample ones are quite rare) that is > 0x417 bytes (though several at exactly that). If we assume that this contains MPEG-1 Layer III, this corresponds almost exactly to 44100 Hz at 320kbps, which has a frame size of 0x414 (0x415 with padding which would be used about 90% of the time). If they are encoding at 320kbps and getting rid of the padding, thus enabling them to get vbr performance without a vbr decoder, this would make sense.
8 bytes of each frame are occupied by stuff we know to be only stream framing material (the frame size and sample count), which leaves 0x40F bytes for the MPEG payload in the largest chunks. Assuming a fixed MPEG header (4 bytes) is slapped on each frame as it comes across, this would put the largest total MPEG frame at 0x413 bytes, still short of the proper size. If more than 8 bytes are stream framing then we come up even shorter. I haven't been able to put together anything that generates a valid stream yet. It may be that there's some deeper modifications, or I have to use the d4/d6 for different joint stereo modes, or some such. I also haven't been able to spot where the second frame begins in the 2304-sample packets.
I've got a copy of the MPEG-1 Layer III standard so I'll try to get a feel for it from that angle, and I'll keep poking at it, but I thought I'd post my progress so far to help anyone else who wants a crack at it.
Interesting, here the d4/d6 I was looking at is instead c4/c6, and at a much different ratio (2098:5330). The "small byte value" goes up to 0x58. Otherwise seems the same. Good to have more to chew on, in any case.
Hm, interesting to hear about sox, did it have some special support or was it just MP3? Or does it come in through ffmpeg? I'm hoping that all I'll have to do is reframe this data.
