sox-users@lists.sourceforge.net unofficial mirror
 help / color / mirror / code / Atom feed
* Sox multiple output file trim
@ 2017-12-06  6:17 Sicheng Wang
  2018-02-10 20:08 ` Jan Stary
  0 siblings, 1 reply; 2+ messages in thread
From: Sicheng Wang @ 2017-12-06  6:17 UTC (permalink / raw)
  To: sox-users


[-- Attachment #1.1: Type: text/plain, Size: 2607 bytes --]

Hi all,

 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.

 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

Here is my code:

swang423@cw4:~/tmp>$ sox 440a0101.wav 440a0102.wav 440a0103.wav tmp.wav
             #concat
swang423@cw4:~/tmp>$ soxi 440a010[1-3].wav -D
                                        #Get wav dur
5.538938
5.773500
6.409750
swang423@cw4:~/tmp>$ soxi 440a010[1-3].wav -DT
                                       #Get Total dur
17.722188
swang423@cw4:~/tmp>$ soxi tmp.wav -D
                                               #Long dur; match is good
17.722188
swang423@cw4:~/tmp>$ sox tmp.wav out%2n.wav trim 0 5.538938 : newfile :
trim 0 5.773500     #Trim to get the first 2 file
swang423@cw4:~/tmp>$ soxi out0[1-2].wav -D
                                              #Check dur match; match is
good
5.538938
5.773500
swang423@cw4:~/tmp>$ cmp 440a0101.wav out01.wav
                                       #The first files areidentical
swang423@cw4:~/tmp>$ cmp 440a0102.wav out02.wav
                                       #The second files are not
440a0102.wav out02.wav differ: byte 45, line 1

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

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. But I could always use the "reverse-trim-reverse" trick for the
last file.

I don't think it is the way I'm specifying the time, is it. 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.

My sox is sox: SoX v14.3.2 running on
swang423@cw4:~/tmp>$ uname -a
Linux cw4 3.8.0-44-generic #66~precise1-Ubuntu SMP Tue Jul 15 04:01:04 UTC
2014 x86_64 x86_64 x86_64 GNU/Linux

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.

Thanks.
Sicheng

[-- Attachment #1.2: Type: text/html, Size: 3854 bytes --]

[-- Attachment #2: Type: text/plain, Size: 202 bytes --]

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

[-- Attachment #3: Type: text/plain, Size: 158 bytes --]

_______________________________________________
Sox-users mailing list
Sox-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-users

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Sox multiple output file trim
  2017-12-06  6:17 Sox multiple output file trim Sicheng Wang
@ 2018-02-10 20:08 ` Jan Stary
  0 siblings, 0 replies; 2+ messages in thread
From: Jan Stary @ 2018-02-10 20:08 UTC (permalink / raw)
  To: sox-users

On Dec 06 01:17:16, sichengwang.gatech@gmail.com 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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-users

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2018-02-10 20:08 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-12-06  6:17 Sox multiple output file trim Sicheng Wang
2018-02-10 20:08 ` Jan Stary

Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/sox.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).