*UPDATE* Apparently the only one coming in erroneous (in Perl) is the transformation matrix... the array of 16 doubles.

What type of system is the data being written on? (And what type of system are you unpacking it on?)

My guess is that they are different types. Whilst the 'N' format will ensure that an integer packed on a big-endian system will be correctly unpacked on a little-endian box, there is no such guarentee for the 'd' (or 'f') formats. From perlfunc:pack:

    f   A single-precision float in the native format.
    d   A double-precision float in the native format.
[download]

Even if both source and destination use the same floating point representation, the physical layout of the bytes that make up that representation will vary with endianess.

If this assumption is correct, then the very minimum you would need to do is to re-order the bytes to compensate. This can be done by unpacking your doubles to 8-byte strings and using reverse or similar methods to re-order the bytes before using unpack to decode them. But that will only work if they both use the same basic FP representation.

You'll need to find out what FP reps are used at both ends before progressing.

See Re: Value packed as 'D', how to unpack not using 'D'? and Re: graphic a segy file for related problems.