#275 Different output length from trim if source is AIFF file
sox, at least with the trim effect, appears to get the output length incorrect depending on the input file format. It's a weird one.
I have two audio files, identical other than that one is in WAV format, the other is AIFF. One was generated from the other, converted by sox:
$ soxi original_file.*
Input File : 'original_file.aif'
Channels : 2
Sample Rate : 48000
Precision : 16-bit
Duration : 00:04:57.61 = 14285513 samples ~ 22321.1 CDDA sectors
File Size : 59.4M
Bit Rate : 1.60M
Sample Encoding: 16-bit Signed Integer PCM
Input File : 'original_file.wav'
Channels : 2
Sample Rate : 48000
Precision : 16-bit
Duration : 00:04:57.61 = 14285513 samples ~ 22321.1 CDDA sectors
File Size : 57.1M
Bit Rate : 1.54M
Sample Encoding: 16-bit Signed Integer PCM
I have an example where I want to cut the first 20 seconds off the input file, and keep the rest of the file. If I do that with the WAV file as the source, it works as expected, and soxi shows the output file to indeed be 20s shorter than the input file:
$ sox -V -V 'original_file.wav' -t wav - trim 0:20.0 >out-from-wav.wav
sox: SoX v14.3.2
time: Dec 27 2011 21:41:34
issue: Ubuntu
uname: Linux ludmilla 4.5.5 #1 SMP Thu May 19 11:25:47 CST 2016 x86_64
gcc: 4.6.2
arch: 1288 48 88 L OMP
sox INFO formats: detected file format type `wav'
sox DBUG wav: WAV Chunk fmt
sox DBUG wav: WAV Chunk data
sox DBUG wav: Reading Wave file: Microsoft PCM format, 2 channels, 48000 samp/sec
sox DBUG wav: 192000 byte/sec, 4 block align, 16 bits/samp, 57142052 data bytes
sox DBUG wav: 14285513 Samps/chans
Input File : 'original_file.wav'
Channels : 2
Sample Rate : 48000
Precision : 16-bit
Duration : 00:04:57.61 = 14285513 samples ~ 22321.1 CDDA sectors
File Size : 57.1M
Bit Rate : 1.54M
Sample Encoding: 16-bit Signed Integer PCM
Endian Type : little
Reverse Nibbles: no
Reverse Bits : no
sox DBUG wav: Writing Wave file: Microsoft PCM format, 2 channels, 48000 samp/sec
sox DBUG wav: 192000 byte/sec, 4 block align, 16 bits/samp
Output File : '-' (wav)
Channels : 2
Sample Rate : 48000
Precision : 16-bit
Sample Encoding: 16-bit Signed Integer PCM
Endian Type : little
Reverse Nibbles: no
Reverse Bits : no
Comment : 'Processed by SoX'
sox DBUG trim: start at 960000s, length 0
sox INFO sox: effects chain: input 48000Hz 2 channels 16 bits (multi)
sox INFO sox: effects chain: trim 48000Hz 2 channels 16 bits (multi)
sox INFO sox: effects chain: output 48000Hz 2 channels 16 bits (multi)
sox DBUG sox: optimize_trim successful
sox DBUG wav: Finished writing Wave file, 53302052 data bytes 13325513 samples
$ soxi out-from-wav.wav
Input File : 'out-from-wav.wav'
Channels : 2
Sample Rate : 48000
Precision : 16-bit
Duration : 00:04:37.61 = 13325513 samples ~ 20821.1 CDDA sectors
File Size : 53.3M
Bit Rate : 1.54M
Sample Encoding: 16-bit Signed Integer PCM
However, if I do exactly the same thing with the AIFF file as the source:
$ sox -V -V 'original_file.aif' -t wav - trim 0:20.0 >out-from-aif.wav
sox: SoX v14.3.2
time: Dec 27 2011 21:41:34
issue: Ubuntu
uname: Linux ludmilla 4.5.5 #1 SMP Thu May 19 11:25:47 CST 2016 x86_64
gcc: 4.6.2
arch: 1288 48 88 L OMP
sox INFO formats: detected file format type aiff'
sox DBUG aiff: AIFFstartread: ignoringID3 ' chunk
sox DBUG aiff: AIFFstartread: ignoring `' chunk
sox INFO aiff: Unity MIDI Note: 0
sox INFO aiff: Low MIDI Note: 0
sox INFO aiff: High MIDI Note: 0
Input File : 'original_file.aif'
Channels : 2
Sample Rate : 48000
Precision : 16-bit
Duration : 00:04:57.61 = 14285513 samples ~ 22321.1 CDDA sectors
File Size : 59.4M
Bit Rate : 1.60M
Sample Encoding: 16-bit Signed Integer PCM
Endian Type : big
Reverse Nibbles: no
Reverse Bits : no
sox DBUG wav: Writing Wave file: Microsoft PCM format, 2 channels, 48000 samp/sec
sox DBUG wav: 192000 byte/sec, 4 block align, 16 bits/samp
Output File : '-' (wav)
Channels : 2
Sample Rate : 48000
Precision : 16-bit
Sample Encoding: 16-bit Signed Integer PCM
Endian Type : little
Reverse Nibbles: no
Reverse Bits : no
Comment : 'Processed by SoX'
sox DBUG trim: start at 960000s, length 0
sox INFO sox: effects chain: input 48000Hz 2 channels 16 bits (multi)
sox INFO sox: effects chain: trim 48000Hz 2 channels 16 bits (multi)
sox INFO sox: effects chain: output 48000Hz 2 channels 16 bits (multi)
sox DBUG sox: optimize_trim successful
sox DBUG wav: Finished writing Wave file, 55579828 data bytes 13894957 samples
$ soxi out-from-aif.wav
Input File : 'out-from-aif.wav'
Channels : 2
Sample Rate : 48000
Precision : 16-bit
Duration : 00:04:49.48 = 13894957 samples ~ 21710.9 CDDA sectors
File Size : 55.6M
Bit Rate : 1.54M
Sample Encoding: 16-bit Signed Integer PCM
... the output file is 12s longer than expected. Usually, this space is filled with silence, but I have also seen at least one case where it was apparently random hash/binary garbage.
This happens with the version of sox in Ubuntu trusty, but also with the 14.4.2 release built from source.
I do not know if this also happens when output is not to a pipe; I discovered this because I am using the sox trim effect as a piped input file from another sox process.
I have also ran into this, and even when using a simple 24-bit, 44.1khz wav file. I tried taking a longer file, and concatenating them together with trim as an output effect, and 99% of the time the length is correct, but in some cases, I can see that the proper trim length is set, but upon output, it's a few milliseconds longer. This causes issue with file-swapping since they aren't the same length (I'm using this to generate watermarked files that can later be swapped in audio/video programs with the real thing after auditioning and deciding upon the track).
The input file length is 321.176463 seconds, so I can even manually type the command to trim to 321.176463 seconds, but the output file will always be 321.227007 seconds. Is there some factor influencing that? I'm not sure how the underlying architecture works to know where the problem may lie.
I can't reproduce this behaviour. Are you still seeing it?
I'm not actively working on a project that uses SoX anymore unfortunately.
Last edit: Martin Guy 2025-11-23
Unable to reproduce. Closing.
https://codeberg.org/sox_ng/sox_ng/issues/695
If you're still with us, Charles and Trevor, do you remember what CPU/OS this happened on in case it's a little-endian/big-endian problem or similar?
I'm still here :) . It was on Linux (Ubuntu) with its standard x86-64 kernel, so nothing exotic.