No, the XMA files are not encrypted, they're (headerless) multichannel XMA files, so they need to be decoded as such. As you can read here, the data is interleaved:
https://devel.nuclex.org/external/svn/d ... xma2defs.hQuote:
// MULTICHANNEL AUDIO: the XMA decoder can only decode raw XMA data into either
// mono or stereo PCM data. In order to encode a 6-channel file (say), the file
// must be deinterleaved into 3 stereo streams that are encoded independently,
// producing 3 encoded XMA data streams. Then the packets in these 3 streams
// are interleaved to produce a single XMA2 file, and some information is added
// to the file so that the original 6-channel audio can be reconstructed at
// decode time. This works using the concept of an XMA stream (see above).
//
// The frames for all the streams in an XMA file are interleaved in an arbitrary
// order. To locate a frame that belongs to a given stream in a given XMA block,
// you must examine the first few packets in the block. Here (and only here) the
// packets are guaranteed to be presented in stream order, so that all frames
// beginning in packet 0 belong to stream 0 (the first stereo pair), etc.
//
// (This means that when decoding multi-stream XMA files, only entire XMA blocks
// should be submitted to the decoder; otherwise it cannot know which frames
// belong to which stream.)
//
// Once you have one frame that belongs to a given stream, you can find the next
// one by looking at the frame's 'NextFrameOffsetBits' value (which is stored in
// its first 15 bits; see XMAFRAME below). The GetXmaFrameBitPosition function
// uses this technique.
ToWAV apparently doesn't work with multichannel files but if you stick a regular XMA header to it (
http://www.mediafire.com/?gitfmumgotj ), you can pass it through ToWAV (
http://www.ctpax-x.ru/index.php?goto=fi ... 24&lang=en ) and you'll actually hear some frames of the interleaved audio.
