On Dec 06 01:17:16, sichengwang.gatech@xxxxxxxxx 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 _______________________________________________ Sox-users mailing list Sox-users@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/sox-users
