From: simon a. (B. <sim...@bb...> - 2005-12-20 16:00:45
|
On 15 Dec 2005, at 16:55, Randy Julian wrote: > Based on some recent conversations on the list (and some experience > helping others develop mzData readers and writers), I suspect we need > better definition of the base64 arrays. The last comment was: > >> ... The error is similar in each case - for example: >> Byte data array had length 56 which isn't a multiple of 8 I should point out that this error had nothing at all to do with the specification (56 is of course a multiple of 8!), just my inability to type :-) Having spent the last few days working through a load of example mzData files I thought I'd share a few observations about things I found in some files which caused problems in our application and which may pre-warn others trying to work with the format. 1) Some spectra which are part of a series do not have a time value associated with them (or any other value which would indicate their order). 2) Spectra within a time series do not always appear in time order in the mzData file 3) A single mzData file can contain more than one series at the same ms level (eg zoom scans). There isn't a nice way within the mzData format to distinguish these series. We ended up just combining them into a single series, but this looks rather odd (you get a sawtooth pattern in the chromoatogram). 4) Some spectra denoted as continuous do not provide their data in the order of increasing m/z values. This just seems wrong (although it's not against the spec), and we treat these as discontinuous spectra and throw up a warning. 5) Some spectra marked as having 64 bit precision actually only contain 32 bit precision data padded with zeros. Although not strictly incorrect, this is a bit naughty. 6) Some files have more than one spectrum, but only ever have one file per msLevel. This isn't in any way an error, but it caught us out when trying to draw chromatograms! Simon. -- Simon Andrews PhD Bioinformatics Dept. The Babraham Institute sim...@bb... +44 (0) 1223 496463 |