We use cookies and other tools to enhance your experience on our website and to analyze our web traffic.
For more information about these cookies and the data collected, please refer to our Privacy Policy.

EEG header data(end time of recording)

5 posts
Was this reply useful? Learn more...
 
[-]
vitaliyelyashevskiy +0 points · about 6 years ago

Hello everyone, I need to extract header data from EEG files, I have found this script Read EDF Header and Signal Header it's almost suits me, but I also need end time of recording, the data is present when I'm opening file using Polyman.

First I thought that this row could help ->puts " duration_of_a_data_record: #{edf.duration_of_a_data_record}" but the result is always 1.

Could someone please give an advise how to do it?

52 posts
bio
Was this reply useful? Learn more...
 
[-]
remomueller +0 points · about 6 years ago

Hi Vitaliy,

I think what you are looking for is a combination of edf.duration_of_a_data_record which is the length (in seconds) of a single data record in the EDF. You should be able to multiply this number by edf.number_of_data_records to get the overall length (in seconds) of the recording. You can then "add" this to the edf.start_time_of_recording to get the final result.

Let me know if you need any additional clarification! Thanks!

# Returns the length of the EDF in seconds
def length_of_recording(edf)
  edf.duration_of_a_data_record * edf.number_of_data_records
end
5 posts
Was this reply useful? Learn more...
 
[-]
vitaliyelyashevskiy +0 points · about 6 years ago

I encountered on more issue with the script. In my case duration of data record is 0.125 sec (I have checked it through Polyman program) and in this case script is showing me value 0, even if I specify edf.duration_of_a_data_record*1000 to have a number in milliseconds.

Could you please help me with this

5 posts
Was this reply useful? Learn more...
 
[-]
vitaliyelyashevskiy +0 points · about 6 years ago

Please don't waste your time, I found the solution I found the edfize script and updated data type

and in HEADER_CONFIG = { duration_of_a_data_record: { size: 8, after_read: :to_f, name: 'Duration of a Data Record', units: 'second' }, }

52 posts
bio
Was this reply useful? Learn more...
 
[-]
remomueller +0 points · about 6 years ago

Hi Vitaliy, Thanks for letting me know, I may need to push a new release for that, but want to check to see if this part of the EDF specifications. Did this issue occur in one of the EDFs on the NSRR? Thanks!

5 posts
Was this reply useful? Learn more...
 
[-]
vitaliyelyashevskiy +0 points · about 6 years ago

This issue occurred not with edf on the NSRR, one of the edf's on https://www.physionet.org/

52 posts
bio
Was this reply useful? Learn more...
 
[-]
remomueller +0 points · about 6 years ago

I took a look through most of the EDF spec documentation and found the following for duration of a data record:

Q9. Do non-integer sampling frequencies (like 1/30 Hz) cause problems?

Not necessarily. Good viewers will count samples and compare these with "number of samples in a datarecord" and in this way count how many datarecords have been passed (and consequently how many "duration's of a datarecord"). Because this is all integer computation, there are no round-off errors. This is why EDF recommends the "duration of a datarecord" to be an integer number of seconds. In the 1/30 Hz example, "duration of a datarecord" and "number of samples in a datarecord" can be 30 and 1, respectively. Or 3600 and 120, respectively.

However, if a sampling frequency is 999.98Hz (for instance due to small inaccuracy of the ADC clock), 'integer EDF' would use datarecords of 50000s containing 49999 samples of each signal. Even if only one signal is in the file, there would be more than 61440 bytes in a datarecord. The official specs say that in that case the duration should be a float value less than 1s. This will inevitably cause a small round-off error in the timing. Item 10 of the programming guidelines explains that this error is negligible, even in extreme cases.

I may move your change to the code base if we find an influx in EDFs that do this.

In any case, thanks for all the information, definitely helps out the development of tools!

5 posts
Was this reply useful? Learn more...
 
[-]
vitaliyelyashevskiy +0 points · about 6 years ago

Hi Remomueller, Thank you, I assumed that, now I know for sure.