[Octave-bug-tracker] [bug #49927] audioread slow when extracting only part of a file

[Kai-Michael]

Follow-up Comment #13, bug #49927 (project octave):

It is at least the most obvious deficiency of audioread.
If the memory limit of 64 Bit Octave under Windows 7 Home Premium 64 Bit is
close to 570 MB, it is also the probable explanation for the read failures I
encountered initially after having read already 4000 blocks. This could
happen, when at the beginning of script execution slightly more memory is
available but gets smaller during execution e.g. through memory allocation for
graphics queues.
In the present state audioread is a nuisance. It will be more efficient (and
more work) to do direct binary reads on wav-files. Binary writing to wav files
seems to be necessary anyhow, as there is no support for writing audio data
with initially unknown size, as is e.g. the case when you are doing adaptive
resampling. You don't know the required file size before you have finished
processing, but you have to write the already processed audio blocks to disk
like a stream. After that you must update the file header. Apparently this can
only be done through direct binary writing (and learning how to handle a wav
file header).

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?49927>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/