On Dec 10, 3:40 am, [EMAIL PROTECTED] wrote:
> Mario M. Mueller napisa³(a):
>
> > Personally I would expect simple counts (since other seismic formats don't
> > even think of using floats because most digitizers deliver counts). But I
> > was told that there are floats inside.
>
> > But if I assume counts I get some reasonable numbers out of the file.
>
> I looked at the data and it seems to be 24-bit big-endian integers.
Agreed. The first byte is only 0x00 or 0xFF. Where the first byte is
0x00, the 2nd byte is only 0 or 1. Where the first byte is 0xFF, the
second byte is only 0xFE or 0xFF. The 3rd byte is more-or-less
uniformly distributed. In other words, I see no indications that the
data is other than 24-bit big-endian twos-complement integers. The
actual range of the sample needs only 10 bits.
*If* it is floating point, it's either unnormalised or a weird format
or both.
> I even plotted it and the graph looks quite reasonable (though I have no
> expertise in seismic data at all).
Same here.
>
> > But I'm experiencing some strange jumps in the data (seismic data is mostly
> > quite smooth at 40 Hz sampling rate). I think I did some mistake in the
> > byte order...
>
> Probably. In your code sample, when you pad it to 32-bits, why are you
> inserting every third byte, instead of the most significant one? Maybe
> the following will work:
>
> if sign:
> s = struct.unpack('>i','%c%c%c%c' % (chr(0xFF),s0,s1,s2))[0]
> else:
> s = struct.unpack('>i','%c%c%c%c' % (chr(0x00),s0,s1,s2))[0]
>
s/Probably/Definitely/
s/Maybe/Definitely/
:-)
Cheers,
John
--
http://mail.python.org/mailman/listinfo/python-list
