by
lmh » Wed Aug 21, 2019 10:56 am
The problem probably isn't the rate of collection of spectra, it's more likely to be that Xcalibur piles up all its spectra in one file. The original poster mentioned how the chromatograms appear in QualBrowser before using a scan filter. This suggests that (s)he is using a system that produces MS2 and MS data. As a result the file might contain
MS 200-2000
MS2 on precursor ion 943.1
MS 200-2000
MS2 on precursor ion 451.1
MS 200-2000
MS2 on precursor ion 943.1
... etc.
Since the TIC for the full MS 200-2000 is much greater than the TIC from an MS2 spectrum, if you merely plot the TIC for all scans irrespective of what they actually are, you get a chromatogram that bounces up and down, high for the MS, low for the MS2, but the high-points follow a general peak-shaped envelope. QualBrowser has scan filters that allow it to pick out just the MS spectra, and create a TIC from them, which is then the right shape. Better format-converters and software can understand what's going on, and select the right spectra. Naïve software will assume all spectra are equal, and get confused.
It's also unfortunate that manufacturers don't tend to be very outward-thinking in their raw data formats. The problem for 3rd-party software is that it might work now, but there is always the chance that next week Thermo will release something new that creates files that aren't handled properly by the 3rd-party software, and suddenly as a user you've got a whole lot of trouble - at the very least you have to wait a few months while 3rd-party developer catches up, or at worst you're faced with a choice of trying to back-track on your instrument software (and oh look! when we reinstall the previous version it won't recognise the firmware on all the instrument modules, and the engineer has gone off with the firmware upgrade disks...), or losing the data-handling pathway. If you need 3rd party software, I think it's really important to batter the original manufacturer until they provide a means of conversion that actually works. But even then, life isn't simple. Open formats by definition have to cope with whatever data-set the mass spec produces, so there is still a possibility of misunderstandings between how the manufacturer thinks their data should be packaged into mzXML, and how the 3rd-party software expects it to be packaged.
By the way, I'm stupid: if at all possible, abandon net cdf and use mzXML or mzData, and the problem will go away. I'd bet a chocolate bar on that, and I'm not a betting person generally.
Sorry to write at length. File formats are a touchy subject for me.