[Eeglablist] importing events from mff files

[Delorme, Arnaud]

Dear Roy,

The datum Matlab function is only precise down to the millisecond level. The microSec bit allow to achieve close to micro second resolution - it is a custom correction that is added on top of datenum. The actual resolution is about 20 micro seconds because of the limitation of double precision numbers (hence sometimes warning messages you might see when importing MFF files that contain full micro second resolution on some events. For all practical purposes, more than millisecond precision on events is not useful (I have never seen any paper taking advantage of that).

Best wishes,

Arno

> On May 25, 2020, at 11:37 AM, Roy Cox <roycox.roycox at gmail.com> wrote:
> 
> Dear Arno,
> 
> That's very helpful and gets me close to where I need to be.
> 
> Just one small question: what's happening exactly in mff_decodetime (called from mff_importevents)? I get it's parsing the timestamp, but I don't see what the microSec bit accomplishes (though the addition appears to evaluate to zero for my test data anyway).
> 
> At any rate, many thanks for your help.
> 
> Best,
> 
> Roy 
> 
> On Wed, May 20, 2020 at 10:08 AM Delorme, Arnaud <adelorme at ucsd.edu> wrote:
> Dear Roy,
> 
> 
> > 1) As a prelude, event latencies in eeglab for continuous data are said to
> > be in sample points (
> > https://sccn.ucsd.edu/wiki/Chapter_03:_Event_Processing#Event_processing_from_the_Matlab_command_line).
> > However, when importing events using *pop_importevent*, the *latency* field
> > is required to be in seconds. So it appears that the term "latency" refers
> > to (slightly but importantly) different things in different contexts. Is
> > this correct?
> 
> The latency unit is specified in seconds (so could be milliseconds if you set it to 0.001). For MFF file, this is microSeconds. If you have samples in the file you are importing, the documentation indicate to enter NaN and then no conversion will be applied.
> 
> > 2) Turning to mff: mff event files (Events****.xml) appear to show event
> > timing in clock time. What is the origin of this clock time? More
> > importantly, can it (still) be trusted in the context of data
> > discontinuities? (As a side note, if anyone has any documentation with
> > details of the mff format, especially event timing, that would be very
> > welcome.)
> 
> The clock time down to microseconds of events is correct. When discontinuities are present, this does not affect the clock time of the events which is absolute. 
> 
> However, then the file epochs.xml will contain the segment and the function mff_import.m (not mff_importevent.m) will adjust the latencies of the events imported by mff_importevent.m based on that information to add the discontinuities for EEGLAB.
> 
> > 3) I've tried using the *mff_importevents *function from the MFFMatlabIO
> > (v3.4) plugin. While it runs, I can't be sure it's working as intended.
> > It's unclear a) what the input argument *begTime* is supposed to hold
> 
> “begTime” is the beginning time of the experiment as defined in the field “recordTime” of the file “info.xml”
> 
> > b)
> > how returned latencies are represented (seconds, sample points?),
> 
> Samples.
> 
> > c)
> > whether data discontinuities are accounted for (I suspect not since there
> > is no reference to the epochs.xml file).
> 
> No, discountinuities are only accounted for after the file is processed by mff_import.m because discontinuities are stored in another xml file “epochs.xml.”
> 
> Best wishes,
> 
> Arno
> 
> _______________________________________________
> Eeglablist page: http://sccn.ucsd.edu/eeglab/eeglabmail.html
> To unsubscribe, send an empty email to eeglablist-unsubscribe at sccn.ucsd.edu
> For digest mode, send an email with the subject "set digest mime" to eeglablist-request at sccn.ucsd.edu