search

wadpac / GGIR

Code corresponding to R package GGIR
https://wadpac.github.io/GGIR/
Apache License 2.0
99 stars 62 forks source link

Axivity AX3 wav file converted by omconvert cannot be recognized #489

Closed Minjingy closed 1 year ago

Minjingy commented 2 years ago

Describe the bug I can deal with Axivity AX3 .cwa file of one sample from UK Biobank successfully using GGIR on linux system in the server(GGIR version 2.5-4, R version 4.1.1), but after I converted it to wav file by omconvert software on Linux system, the wav format cannot be recognized regardless of linux system or windows system. I've tried using g.wavread but it didn't work out.

To Reproduce

Steps to reproduce the behavior.

  1. Sensor brand: Axivity AX3
  2. Data format: '.wav'
  3. Approximate recording duration 7 days, only 1 sample
  4. Are you using a sleep diary to guide the sleep detection: NO
  5. Copy of R command used: ①g.shell.GGIR( mode=c(1,2,3,4,5), datadir="", outputdir="", do.report=c(2,4,5), overwrite = TRUE, strategy = 1, hrs.del.start = 0, hrs.del.end = 0, maxdur = 9, includedaycrit =16, qwindow=c(0,24), bout.metric = 4, excludefirstlast = FALSE, includenightcrit = 16, def.noc.sleep = 1, outliers.only=FALSE, do.visual = TRUE, do.sibreport = TRUE, possible_nap_window = c(9,19), possible_nap_dur = c(15, 240),nap_model = "hip3yr", HASIB.algo ="vanHees2015", includedaycrit.part5 = 2/3, timewindow = c("WW"), visualreport=TRUE)
    ②g.wavread("***/1000019_acc.wav")
  6. Have you tried processing your data based on GGIR's default argument values? Does the issue you report still appear? YES

Expected behavior Axivity AX3 wav file converted by omconvert can be recognized in part 1 on linux system in the server

Screenshots When I used g.shell.GGIR in linux system, the progress stayed at part1 for 3 hours, and I stopped the progress finally image When I used g.wavread in linux system image

Then I changed to windows system, When I used g.shell.GGIR in windows system image When I used g.wavread in windows system image

Desktop (please complete the following information):

Additional context I've examed wav file produced by omconvert software, the wav file is 400MB and the exit status is 0 which means successfully converted (information file and output file written). I run the omconvert software (https://github.com/digitalinteraction/omconvert/tree/master/src/omconvert) on linux system in the server.

Minjingy commented 2 years ago

warnings in the windows system when I used g.wavread: image

vincentvanhees commented 2 years ago

Sorry to hear about your struggles with reading the .wav data.

You can continue working with the .cwa data. There is no added value of working with the .wav data. The reason some published studies worked with .wav data is because at the time GGIR was not compatible with .cwa data. I only implemented the .cwa reading functionality after those studies were done. In fact, I think the .cwa data is more reliable to work with. The g.wavread function seems very sensitive to the file header format, which has changes across OMGUI versions and datasets and the reason why you are unable to process your .wav data.

Moving forward, I see the following options:

  1. Document better the limitations of g.wavread and recommend working with .cwa => I can do this easily.
  2. Update g.wavread to better handle the variety in .wav file header formats => Involves more time and I would have to be paid for this.
  3. Deprecate the g.wavread and recommend researcher to work with .cwa data. => Not ideal for those who have worked with .wav data.
Minjingy commented 2 years ago

Dear professor van Hee, Thank you very much for your quick reply and detailed explanation in patience! That's very useful for solving my problems! I will continue to work with the .cwa data. I think maybe that's not necessary to update g.wavread if there is few people using .wav files. Actually, at the beginning, I thought that these published studies worked with .wav data converted by omconvert because there was some difference from calibration steps of GGIR and omconvert. From my perspective, maybe more improved calibration steps in the future are more significant, if converting to .wav file is not a necessary step. Thank you again, and I have the greatest respect for your unselfish contribution and consistent updates to GGIR package! Kind regards,  Minjing

------------------ 原始邮件 ------------------ 发件人: "wadpac/GGIR" @.>; 发送时间: 2022年1月19日(星期三) 下午4:38 @.>; @.**@.>; 主题: Re: [wadpac/GGIR] Axivity AX3 wav file converted by omconvert cannot be recognized (Issue #489)

Sorry to hear about your struggles with reading the .wav data.

You can continue working with the .cwa data. There is no added value of working with the .wav data. The reason some published studies worked with .wav data is because at the time GGIR was not compatible with .cwa data. I only implemented the .cwa reading functionality after those studies were done. In fact, I think the .cwa data is more reliable to work with. The g.wavread function seems very sensitive to the file header format, which has changes across OMGUI versions and datasets and the reason why you are unable to process your .wav data.

Moving forward, I see the following options:

Document better the limitations of g.wavread and recommend working with .cwa => I can do this easily.

Update g.wavread to better handle the variety in .wav file header formats => Involves more time and I would have to be paid for this.

Deprecate the g.wavread and recommend researcher to work with .cwa data. => Not ideal for those who have worked with .wav data.

— Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you authored the thread.Message ID: @.***>