There is no compression in this case and this is the same number that
I get with ReAdW and msconvert, I'm just having trouble figuring out
where the network encoding is coming into play in this example.
--
You received this message because you are subscribed to the Google Groups
Actually I think I figured it outin case anyone else out there is
wondering - if you have a c-style char array holding your hex value,
it will be automatically converted to the host endianess when type
casting into an integer. So then the bytes have to be reconverted
again (network to host)
Nice job on tracking that down. I'm sure there are other examples but
in TPP's src/mzXML/common directory you can look at the Base64 and
ScanConverter.cpp for code examples and some documentation on the
encoding.
-Natalie
On Fri, Feb 4, 2011 at 6:56 AM, dre shee...@gmail.com wrote:
Actually I
No data compression on the peak list?
Try running the file through mscovert, it does not use the RAMP parser
and should give a good sanity check on the mzXML file in question.
Instead of guessing at what's reasonable, I'd advise determining what
the actual value is (again, msconvert could help
Mysterious. If that's really what's going on I'd think you could make
any number of reader tools tip over, have you tried any?
On Wed, Feb 2, 2011 at 1:05 PM, dre shee...@gmail.com wrote:
The byteorder attribute in my test file is set to network.
--
You received this message because you are
