Back to the main page.
Bug 2907 - read_eep_trg.mex* behave differently that read_eep_trg.m on files with magic number "RIFF"
| Status | CLOSED FIXED |
| Reported | 2015-06-11 14:53:00 +0200 |
| Modified | 2019-08-10 12:33:35 +0200 |
| Product: | FieldTrip |
| Component: | external |
| Version: | unspecified |
| Hardware: | All |
| Operating System: | All |
| Importance: | P5 critical |
| Assigned to: | Thomas Hartmann |
| URL: | |
| Tags: | |
| Depends on: | |
| Blocks: | |
| See also: |
Thomas Hartmann - 2015-06-11 14:53:05 +0200
line 683ff: if filetype_check_header(filename, 'RIFF') scaler = 1000; % for 32-bit files from ASAlab triggers are in miliseconds elseif filetype_check_header(filename, 'RF64'); scaler = 1; % for 64-bit files from ASAlab triggers are in seconds end this fails for my cnt files (recorded with ASA). mine have a 'RIFF' magic number but the triggers are in seconds.... is there any other way to detect this, maybe? best, thomas
Thomas Hartmann - 2015-06-11 15:46:58 +0200
ok, the problem is actually not in the ft_read_event function as it works fine on 32bit machines. the problem is the compiled read_eep_trg.mex* functions as they seem to do the scaling themselve.......
Robert Oostenveld - 2015-06-11 19:29:50 +0200
Hi Thomas, Please discuss with Daniel and Sarang (CC). Robert
Thomas Hartmann - 2015-06-12 11:20:47 +0200
hey guys! so, what's the advantage of the mex file anyway? i cannot imagine that the speedup would be really significant.... and for me, just deleting the mex file solved the bug for me....
Daniel Wong - 2015-06-12 13:30:53 +0200
(In reply to Thomas Hartmann from comment #3) It was part of the mex package that was recently compiled in order to provide RF64 compatibility. We can discard the read_eep_trig.mex* files if the .m file works fine for both RIFF and RF64 formats. D
Thomas Hartmann - 2015-06-12 14:45:12 +0200
(In reply to Daniel Wong from comment #4) do you have one of these RF64 files lying around? my system produces the RIFF versions.... i think, we would only need to take a look at the trg files... best, thomas
Daniel Wong - 2015-06-15 16:11:11 +0200
(In reply to Thomas Hartmann from comment #5) Just sent one to your unitn account. D
Sarang Dalal - 2015-11-23 21:39:31 +0100
Hi everybody, it seemed the mex file for read_eep_trg implements different code than the m-file. As far as I see, the trigger latencies are in full seconds for both data formats. In addition, it seems the final quantity that we desire (the trigger latency in samples) is already contained in the trigger file as well, so we might as well just use that. I have therefore replaced line 697: event(i).sample = round((trg(i).time/scaler) * hdr.Fs) + 1; % convert from ms to samples event(i).value = trg(i).code; with: event(i).sample = trg(i).offset; event(i).value = trg(i).type; Note that the m-file will produce an offset in *bytes* rather than in samples. I also changed "code" (string) to "type" (numerical), according to the expectation that event codes are always numbers. (This was also the previous behavior before using the new eeprobe code to read ANT data.) The "scaler" code preceding this section is then no longer necessary, and I have removed it. @Robert, I would recommend disabling the corresponding m-file (external/eeprobe/read_eeg_trg.m) since it does not produce the expected output. Cheers, Sarang
Sarang Dalal - 2015-11-23 21:41:32 +0100
@Robert, I would recommend disabling the corresponding m-file (external/eeprobe/read_eeg_trg.m) since it does not produce the expected output. It seems I do not have write permission to do this myself. @Thomas, this now works for both new and old ANT data from Konstanz; perhaps you should double-check with your own data when you get a chance.
Robert Oostenveld - 2015-11-30 14:50:17 +0100
I have disabled the m-file by renaming it 188-252> svn commit Adding read_eep_trg.bak Deleting read_eep_trg.m Committed revision 10952.
Sarang Dalal - 2016-07-22 18:00:04 +0200
*** Bug 3166 has been marked as a duplicate of this bug. ***