Back to the main page.

Bug 2068 - Brainvision problems

Reported 2013-03-18 16:46:00 +0100
Modified 2019-08-10 12:03:28 +0200
Product: FieldTrip
Component: fileio
Version: unspecified
Hardware: PC
Operating System: Windows
Importance: P3 normal
Assigned to: Jim Herring
Depends on:
See also:

Vladimir Litvak - 2013-03-18 16:46:39 +0100

Created attachment 439 Data plot Hi, Here is what I got on SPM list. You might want to get data example directly from the user. Vladimir ---------- Forwarded message ---------- From: Christoph Hofstetter <> Date: Mon, Mar 18, 2013 at 3:03 PM Subject: [SPM] EEG convert for BrainVision format erroneous? To: Dear SPM EEG and FieldTrip developers, I have noticed that from version SPM8 5236 on the conversion of BrainVision files gives weird results for me. The data set I am using are from intracranial recordings which I converted into BrainVision format using cartool. I used the convert (epoch, define trials) routine in SPM8 4667 and it worked well. However, when using the same approach in SPM8 5236 the results are different and many trials have very high peaks (see file attached). After looking a bit into this issue I found that replacing the following SPM8 5236 functions from the SPM8 4667 brought back the same results as using pure SPM8 4667: spm8_4667\external\fieldtrip\fileio\ft_read_data.m spm8_4667\external\fieldtrip\fileio\private\read_brainvision_vmrk.m spm8_4667\external\fieldtrip\fileio\private\read_brainvision_eeg.m spm8_4667\external\fieldtrip\fileio\private\read_brainvision_pos.m spm8_4667\external\fieldtrip\fileio\private\read_brainvision_vhdr.m It seems the problem is rather with FieldTrip than SPM, nevertheless I felt like sharing this with you. Please let me know if using the "old" fileio FieldTrip functions could be problematic. Many thanks in advance for any comments on how to best deal with this. Best regards, Christoph

Jim Herring - 2013-06-13 12:11:52 +0200

This bug is possibly related to bug2153. If all channels are read-in at once and the binary format of the source file is not 'uint16' the offsets are off by one-half of the intended offset. It could be that this has happened here as well and wrong segments are read-in. The problem should not have occurred when specific channels are read-in as opposed to reading-in all channels. I'll send Christoph an e-mail to check whether this is the same problem as in bug2153

Jim Herring - 2013-08-02 09:08:35 +0200

I have not heard back from Christoph so I'll assume this bug is related to bug2153 and I'll therefore mark this as a duplicate. *** This bug has been marked as a duplicate of bug 2153 ***

Robert Oostenveld - 2019-08-10 12:03:28 +0200

This closes a whole series of bugs that have been resolved (either FIXED/WONTFIX/INVALID) for quite some time. If you disagree, please file a new issue describing the issue on