Re: Sox multiple output file trim

On Dec 06 01:17:16, [email protected] wrote:
>  I've been playing around with some amazing effects in Sox. Right now I
> concatenated many short files sequentially to create a long audio. (I'm
> going to do something with this long audio, but due to the issue I'm going
> to describe, I leave the long audio untouched for now). Afterwards I wish
> to split the long audio into smaller segments with the same duration my
> short files (like disassembling the long audio into its original short
> pieces) . I expect to get the same short audios back.

Why do you need/want to concatenate them and then cut it again?

>  It seems the following line of code in the manual does the thing closest
> to what I wish:
> sox song.wav ringtone%1n.wav trim 0 30 : newfile : trim 0 30

Only if all the lengths are 30 seconds.

> Here is my code:
> $ sox 440a0101.wav 440a0102.wav 440a0103.wav tmp.wav
> $ soxi 440a010[1-3].wav -D

That's not an actual sox line; use script(1).

> 5.538938
> 5.773500
> 6.409750

> $ soxi 440a010[1-3].wav -DT
> 17.722188

> $ soxi tmp.wav -D
> 17.722188

> $ sox tmp.wav out%2n.wav trim 0 5.538938 : newfile : trim 0 5.773500  
> $ soxi out0[1-2].wav -D
> 5.538938
> 5.773500

> $ cmp 440a0101.wav out01.wav
> $ cmp 440a0102.wav out02.wav
> 440a0102.wav out02.wav differ: byte 45, line 1

That would be right after the WAV header,
which I believe is 44 bytes in usual cases.
So they differ in the first sample already.

> Upon closer inspection, I found that out02.wav is shifted by something like
> 1000 samples from 440a0102.wav.

How exactly did you find out?

> The last file could not be trimmed successfully as well, since the output
> will be shorter than the original. I suspect the buffer has something to do
> with it.

Yes, it's probably the buffering.
How exactly does the behavior change
if you change --buffer and/or --input-buffer?

> I don't think it is the way I'm specifying the time, is it.

5.538938 is 5.538938, nothing wrong with that.

> I also tried to specify it with sample count:
> swang423@cw4:~/tmp>$ sox tmp.wav out%2n.wav trim 0s 88623s : newfile : trim
> 0s 92376s
> but the results are the same.

How many samples does out02.wav contain then?

> My sox is sox: SoX v14.3.2

The latest SoX is 14.4.2, released three years ago?
Please try also with that. But I think you are right
and it's the buffering, which probably has not changed.


> BTW I ended up doing
> sox tmp.wav out02.wav trim 5.538938 5.773500
> which works out fine. But I need to do this a dozen of times.
> I still think the "multiple output" seems more elegant.

If the lengths are different, you need to specify all of them anyway:

  $ sox tmp.wav out%2n.wav trim 0 5.538938 : newfile : trim 0 5.773500

vs

  $ sox tmp.wav out1.wav trim 0.000000 5.538938
  $ sox tmp.wav out2.wav trim 5.538938 5.773500


Jan


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot