Also, note that the same version of mscovert that Matt recommends is included in TPP version 4.3.1.
-Natalie On Sep 10, 2009, at 7:20 PM, Matt Chambers wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
