Hi Ali,
Thanks for sending the parameters section of your X! Tandem results.
I see the problem now. Your parameters include:
note type=input label=refine, modification mass57@c/note
note type=input label=residue, modification mass57.021...@c/
note
As it turns out,
Mascot2XML is often problematic, since it tries to figure out scan
descriptions from a variety of formats that have then been passed through
Mascot - it's an ever shifting landscape. It appears you've hit on a new
variant. If you want to send me a small sample I can see about tweaking the
code
I expect you'll find the difference between those computers is that they
have different (or no) versions of the mass spec vendor's software
installed. The mzwiff program depends on the vendors DLLs to read their
secret file format, and probably wants to see a certain version of that DLL.
On Thu,
And by the way, the AAA string that you see is just the
encoding for an empty scan (as you've already seen, peaksCount will be
0 for these scans.)
On Sep 10, 2009, at 10:45 AM, Brian Pratt wrote:
I expect you'll find the difference between those computers is that
they have
Hi,
I'm running a lot of database searches on a large number of mzXML
files. Because of this, I need to conserve space on my computer. My
understanding of the software is that Database Search generates a
folder of out/dta files, which is converted to a PepXML file. The
PepXML file is then used
Thanks for the information.
The real problem is that a single computer generates working-mzXML files for
some wiff files but not-working files for other wiff files.
(not only on different computers).
For the empty scans, the working-mzxml file generated on a different
computer (for the same wiff
Were all the wiff files acquired with the same version of Analyst? If
not, that's probably the issue.
I recommend trying msconvert which reads WIFFs with a different API from
mzWiff: instead of depending on the myriad of different Analyst
versions, it uses the unified DLLs from Protein Pilot
