Bug in library generation Mike S  2019-07-15


I noticed that while building a spectral library from MaxQuant search results (v. and from Thermo Q Exactive HF raw files, the spectrum extracted by Skyline is off by one. For instance, MaxQuant matched scan number 28055 to a specific peptide, yet in the process of extracting the spectra from the raw file to build the library, it tried to match the spectrum with scan number 28056 instead (which obviously has no fragment ion matches). I double-checked that the match to the correct spectrum is very good with ProteinProspector and that my fragment ion matching tolerances are okay. It is quite evident that the wrong spectra are being extract based on the fragment ions themselves not matching.


Brendan MacLean responded:  2019-07-16

Hi Mike,
Thanks for pointing this out! After years of waiting for support from MaxQuant we decided this release to pull matched DDA spectra directly from the associated raw data files, rather than the msms.txt files, which many people had pointed out contain MS/MS spectra which have been "charge-state deconvoluted", which means all peaks that match charge 2 and higher fragments are mapped back to charge 1 and summed with the peak at that m/z. Not great for using the peak intensities to rank fragment ions and calculate dotp values between library and measured intensities.

However, as you have pointed out, it looks like there is an off-by-one in the code that determines the raw spectrum to use. Sure wish someone had noticed earlier, since this has been in Skyline-daily (our beta release) for a while. But, glad you noticed so quickly after I released Skyline 19.1. We will get a fix out in a patch soon.

In the meantime, you can simply move your raw data away to where Skyline can't find it. Then Skyline should show a message asking if you want to use embedded spectra (i.e. the spectra in the msms.txt file - as it did in version 4.2 and earlier). Once you accept that option you should be back to the (admittedly deconvoluted) spectra Skyline was using before version 19.1 was released.

Again, thanks for your very thorough inspection of this new feature and for alerting us to this issue.