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 3.0 (free trial version available). I've yet to find a non-corrupt WIFF file it doesn't work on. http://sourceforge.net/projects/proteowizard/files/proteowizard/1.6.0/pwiz-1.6.0-tools-windows-i386.zip/download -Matt Sunghyouk Park wrote: > 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 file) does have a non-zero peaksCount and > proper information for the particular scan. > > I want to import this mzXML file into mzmine but it reports errors for > the "corrupt peak" and refuses the import. > > Any suggestions will be appreciated. > > Sunghyouk > > > > > On Fri, Sep 11, 2009 at 2:53 AM, Natalie Tasman > <[email protected] <mailto:[email protected]>> > wrote: > > And by the way, the "AAAAAAAAAAA" 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 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, Sep 10, 2009 at 6:10 AM, Sunghyouk <[email protected] >> <mailto:[email protected]>> wrote: >> >> >> Dear mzwiff users >> >> I was trying to convert ABI4000 *.wiff format file to mzXML using >> standalone mzwiff (v. 4.3.1). >> Strangely, it works for some files, but not for others. >> For the exactly same file, it gives working and not-working mzXML >> output files in different computers. >> The problem I found so far is that the not-working mzXML file >> has the >> following: >> In just a few scans out of thousands, some scan has >> "AAAAAAAAAAA" in >> the <peaks></peaks> block >> as shown below (right above the </scan> tag below) >> >> <scan num="2857" >> msLevel="1" >> peaksCount="0" >> polarity="+" >> scanType="Q1 Scan" >> retentionTime="PT1728.74S" >> lowMz="0" >> highMz="0" >> basePeakMz="0" >> basePeakIntensity="0" >> totIonCurrent="0" > >> <peaks precision="32" >> byteOrder="network" >> contentType="m/z-int" >> compressionType="none" >> compressedLen="0" >AAAAAAAAAAA=</peaks> >> </scan> >> >> In addition, most of the parameters are set to "0" >> (peaksCount, lowMz, >> etc) >> >> Does anyone know how to fix this problem? >> >> Thanks. >> --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "spctools-discuss" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/spctools-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
