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

(Possible) long record name limitation #163

Open
inuritdino opened this issue Oct 4, 2018 · 0 comments
Open

(Possible) long record name limitation #163

inuritdino opened this issue Oct 4, 2018 · 0 comments

Comments

@inuritdino
Copy link
Contributor

Long record names are not parsed properly by ecgpuwave resulting in failed annotations. I have discovered the issue on the PhysioNet ECGRDVQ database, where the record names have a form XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX.<dat/hea> that is also prepended by the path name of ecgrdvq/raw/10[01-22].

To reproduce:

run ecgpuwave on the 1st record in the ecgrdvq database by:

ecgpuwave('ecgrdvq/raw/1001/00ed2097-cd14-4f03-ab33-853da5be5550','ann')

The resulting annotation file is ecgrdvq/raw/1001/00ed2097-cd14-4?.ann. Note the question mark ? in the file name. So, the full file name without the extension and ? is 32 symbols long. (The non-Matlab (Unix-based) version of ecgpuwave returns a similar result.)

I have discovered that the original ecgpuwave implementation (Fortran code, found at
https://www.physionet.org/physiotools/ecgpuwave/src/ecgpuwave-1.3.3/ecgpuwave.f, ver. 1.3.3) has the line (92):

      character*32 arg, f, fname, desc, units

which seems to be limiting the length of a record name. Simple change to:

      character*64 arg, f, fname, desc, units

solves the problem.

P.S. I do not know where to file the issue, as it seems being an issue
for ecgpuwave not the toolbox itself. However, there is no issue
tracking system for the original Fortran code of ecgpuwave.

Additionally, I could not find any similar issue on other or even the same database, although it seems to be quite easily discoverable (no one annotating ECGRDVQ database ever?).

Another solution would be to rename all the files in this particular database (>5000 records), which is quite unreasonable in this case.


GNU Octave, version 3.8.2 on x86_64-redhat-linux-gnu

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