Author Topic: get sound file length dynamically? best practice inside bash script  (Read 2512 times)

p8rpp

  • Sr. Member
  • ****
  • Posts: 58
    • View Profile
Hi list,

I do wonder what would be the best way to insert a soundfile's length
as a parameter in a script file automatically? Is there a way to do with a CDP
program what I have so far achieved on unix using sox(i)?:
      extend zigzag 1 infile outfile 0 `soxi -D infile` 60 1

So I'd need a cdp binary that returns the length of a soundfile in seconds, and only that.
Does anyone know of such a program?

thank you all,
P

rwdobson

  • Sr. Member
  • ****
  • Posts: 73
    • View Profile
Re: get sound file length dynamically? best practice inside bash script
« Reply #1 on: June 29, 2015, 11:13:06 AM »
For historical reasons (mainly birth on the Atari ST, then the move to Windows) we have not created unix-style programs that do this; rather they provide relatively verbose reports to the console. More recently, the programs are designed very much as tools driven by Soundloom (there is a whole secondary and undocumented command line system invented by Trevor Wishart and only used by Soundloom - the various console messages output by a program have a consistent format which Soundloom reads).

Also historically, we supplied (way back in the Atari days, and also for Windows users) the sfsys library and documentation so users could write (and contribute to the system) new utilities. With the move to open source, and to the creation of this forum, we very much hope this community programming activity can be so to speak rebooted. We still have, somewhere, an extensive document I wrote many years ago detailing the use of sfsys; I would have to check if it was still part of the main distribution.

We felt, indeed, that the usual behaviour of unix tools to report nothing to the console (as stdout was used for the primary output exactly for this type of piping approach) was too obscure for users who in most cases had never used a command line before. We would not want (or now be able to) change the existing programs to reflect this way of working, but certainly new unix-style utilities can be easily written by and for those who need them.