293-refactor-signal-read-and-write

[jonbarker68]

Refactoring of audio input and output

Similar functions for reading and writing audio files were previously defined at several points in the library. These have all been replaced by a single pair of functions in utils/file_io that are better documented and provide consistent behaviour.

[codecov[bot]]

Codecov Report

Merging #294 (ad28e85) into main (36236aa) will increase coverage by 0.42%. The diff coverage is 98.14%.

@@            Coverage Diff             @@
##             main     #294      +/-   ##
==========================================
+ Coverage   92.63%   93.05%   +0.42%     
==========================================
  Files          40       40              
  Lines        3774     3744      -30     
==========================================
- Hits         3496     3484      -12     
+ Misses        278      260      -18     

Impacted Files	Coverage Δ
clarity/data/scene_renderer_cec1.py	88.00% <87.50%> (+5.46%)	:arrow_up:
clarity/enhancer/gha/gha_interface.py	97.36% <100.00%> (+3.49%)	:arrow_up:
clarity/evaluator/msbg/msbg_utils.py	96.59% <100.00%> (+1.56%)	:arrow_up:
clarity/utils/file_io.py	100.00% <100.00%> (ø)
clarity/utils/signal_processing.py	100.00% <100.00%> (ø)

... and 3 files with indirect coverage changes

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

[jonbarker68]

@groadabike - I had initially wanted to store multichannel signals as shape [n_channel, n_samples] as this makes it easier to iterate over channels i.e. 'for channel in signal:' but soundfile (which is widely used) uses the opposite convention, so I think transpose on read and write would confuse people. Iterating over channels is still easy enough with 'for channel in signal.T:'