From: Dave (dfisher_at_pophost.com)
Date: 2002-03-03 06:30:14
On Sun, 3 Mar 2002 14:32:42 +1000, John Morrison wrote:
>> The samples (and perhaps any other time-dependant data) on the other
>> hand, can be stored in a very simple file format, where data from
>> different "channels" are interleaved.
>Yes I agree. I'd like to see what the other programs store their data as
>first though.
BioGraph stores each channel in a separate file, named channel.<no> where <no>
is the number of the channel. When I did a cursory look at the hexdumps the
other day, it looked like there was a header (probably with time stamp, sample
rate, sync info, etc.) and that the data itself was some kind of 2-byte
encoding of the single percison floating point data numbers (or something else
entirely, I'm not sure). About the only reason I figure they did that was to
reduce the disk storage requirement.
Each session is stored in its own directory, which is named s<yy><mm><dd>.<seq>
where <yy> is two digit year, <mm> = two digit month, <dd> is two digit day,
and <seq> is a three digit sequence number since you will probably run multiple
sessions per day.
There are also two other files: session.epc and session.inf in the directory.
"session.epc" seems to be the raw dump of packets from the encoder itself.
"session.inf" appears to be a file with user entered data on the session
(notes, name of client, etc.).
And lastly, there is an fft.<no> file for every channel of EEG data.
Here is an example listing. (Don't let the actual time stamps on the files
throw you off, I had to move them and the time stamps were changed, thus they
no longer match the directory name, which records the yymmdd date of the
recording.)
Each session represents a 11-14 minute recording session.
Directory of D:\BIOGRA~2\Data\adf001\s020107.000
02/16/2002 06:05p <DIR> .
02/16/2002 06:05p <DIR> ..
02/16/2002 06:01p 328,320 channel.1
02/16/2002 06:01p 328,320 channel.2
02/16/2002 06:01p 41,082 channel.5
02/16/2002 06:01p 41,082 channel.6
02/28/2002 04:04p 327,984 fft.1
02/28/2002 04:04p 327,984 fft.2
02/28/2002 04:04p 625,216 session.epc
02/28/2002 04:04p 22,607 session.inf
Directory of D:\BIOGRA~2\Data\adf001\s020107.001
02/16/2002 06:05p <DIR> .
02/16/2002 06:05p <DIR> ..
02/25/2002 10:56a 405,696 channel.1
02/25/2002 10:56a 405,696 channel.2
02/25/2002 10:56a 50,754 channel.5
02/25/2002 10:56a 50,754 channel.6
02/28/2002 04:09p 405,424 fft.1
02/28/2002 04:09p 405,424 fft.2
02/28/2002 04:09p 772,836 session.epc
02/28/2002 04:09p 22,607 session.inf
>Make it compatible (Or have a converter) and it makes life a whole lot
>easier to share data.
>
>Could be as simple as
> [Date][Time] - Sample started
> [Length] - MAYBE - would make it easy to fast forward to end or anywhere in
>between.
> [Number of Channels]
> [Channel 1 type] - EEG/EMG/ECG/GSR/ETC
You would also need to include the sampling rate. For this reason, I am
attracted to the file structure used by BioGraph simply because you avoid the
difficulty in trying to interleave one or more channels with differing sample
rates. For example, the ProComp encoder generates 256 samples/sec of EEG data,
but only 32 samples/sec for the other modalities (GSR, EMG, etc.).
The downside is that you are dealing with multiple files instead of one. What
I did for Jim-P's program was combine "channel.1" and "channel.2" into one raw
file so that BWView could read it, storing channel 1 and 2 as couplets of
single percision floating point values in the new file.
I don't have a strong sense of the best course of action right now. I do
recall that there are some standard file formats for this purpose, also. I'll
look for them and post what I find tomorrow.
Oh, and Andreas (welcome to the software discussion :). While it is true that
a database would afford more flexibility in terms of what we can store, it also
introduces more complexity right now (especially since we are going to be
coding across platforms). 'Course, there are probably several open source
database projects that might make this feasible. But, for now, I feel this is
a later-date issue since the real-time data would not be stored in such a way.
Dave.
This archive was generated by hypermail 2.1.4 : 2002-07-27 12:28:39 BST