Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

writecnt failure with non-zero start position #1

Open
arnodelorme opened this issue Dec 3, 2019 · 1 comment
Open

writecnt failure with non-zero start position #1

arnodelorme opened this issue Dec 3, 2019 · 1 comment

Comments

@arnodelorme
Copy link
Collaborator

arnodelorme commented Dec 3, 2019

Hi Arno,

I'll give it more thought, but I haven't been able to come up with a clean fix for this particular bug. In the meantime, it might be a good idea to simply disable or hard code the non-functional inputs. I can do the latter if you'd like and pass it along. At least then the function will work for what I would guess is 98%+ of usage scenarios ... if anyone but me uses this function at all anymore ;).

Let me know your thoughts and I'll do what I can.

Best,
-Chris
[reply] [−]Comment 2Arnaud Delorme 2014-02-19 14:35:50 PST
Hi Chris,

would you mind to try to fix the function as you have done for the other issue you have reported.
Let us know when you think everything is fine and we can help with testing.
Thanks,

Arno
[reply] [−]DescriptionChris Bishop 2014-01-15 11:48:12 PST
Hello again,

While using writecnt, I discovered that several of its optional inputs that change the start position of data writing result in errors.

With the commands below ...

% FILE IN AND OUT
IN=fullfile('C:\Users\cwbishop\Downloads', 'projq_G4_257_6day4.cnt');
OUT=fullfile('C:\Users\cwbishop\Downloads', 'TEST.cnt');

% Load CNT file
cnt=loadcnt(IN);

% Call writecnt
writecnt(OUT, cnt, 't1', 50, 'lddur', 1, 'dataformat', 'int32');

The resulting CNT file is completely invalid. This is due to an error with fseek in line 374 and a similar error in line 397. Fseek fails when attempting to move the pointer position beyond the end of file. Consequently, the event table begins in an improper location (the beginning of the file) and overwrites header and data information. The result is an unusable data file.

Unfortunately, this is not I don't possess the expertise to fix it at present without a significant rewrite of the function. Even then, I am not confident I know how to allow a non-zero start position (sample1 or t1) without writing a bunch of dummy bytes to file ... and that approach will almost certainly cause lots of problems downstream.

I don't expect a fix any time in the near future (or ever, really) since it does not seem that writecnt is used by any mission critical EEGLAB functions. Instead, my hope is to record the bug for posterity.

I will likely have to reorganize the function for my needs and would be happy to upload what I come up with if you feel this would be helpful to others.

Best,
-Chris

@arnodelorme
Copy link
Collaborator Author

arnodelorme commented Dec 3, 2019

We do not have the resources to look into that issue. If someone is motivated (and even want to maintain that repository) let us know.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant