Back to the main page.
Bug 1512 - read_nex_event sample + 1 missing
| Status | ASSIGNED |
| Reported | 2012-06-11 07:49:00 +0200 |
| Modified | 2016-09-13 14:57:52 +0200 |
| Product: | FieldTrip |
| Component: | fileio |
| Version: | unspecified |
| Hardware: | PC |
| Operating System: | All |
| Importance: | P3 normal |
| Assigned to: | Martin Vinck |
| URL: | |
| Tags: | |
| Depends on: | |
| Blocks: | |
| See also: | http://bugzilla.fieldtriptoolbox.org/show_bug.cgi?id=2093 |
Martin Vinck - 2012-06-11 07:49:18 +0200
read_nex_event does the following: dum = fread(fid,hdr.varheader(mrkvarnum).cnt,'int32'); timestamp = dum; dum = dum ./(hdr.filheader.frequency./smpfrq); mrk.tim = round(dum); I think, this should be mrk.tim = round(dum+1); as the current definition would allow for a sample number of zero
Jörn M. Horschig - 2012-06-11 09:23:41 +0200
in that case I would rather use floor instead of round + 1, just to make it exactly rounding up (e.g. if dum would be 0.5, floor would result in 1, round(dum+1) would result in 2)
Robert Oostenveld - 2012-06-11 09:33:24 +0200
(In reply to comment #0) I think you are right about the +1 for the sample, but am not sure whether you should not also first subtract -1 from the timestamp. Say the data for this channel is acquired at 40kHz (equal to the system sampling rate), then timestamps equals samples, right? In that case sample = round(timestamp ./(hdr.filheader.frequency./smpfrq) + 1); results in sample = timestamp+1; which is incorrect. Regarding the comment of Jorn: the timestamp can be in-between two samples, and then you want it to to round to the nearest sample. Maybe as thought experiment: what about a sampling rate of 20kHz (half the system sampling rate), or 10kHz? You can draw the 10kHz case as follows |----|----|----|----|----|----| where each - is a timestamp point and each | is a boundary between two samples. So you get 4 timestamp points per sample, or stated differently: each sample is 4 timestamps wide.