Problem Flac | Sox

[d9probe]

Originally Posted by Barough

SoX Binary v14.4.2 (2024-05-23)
https://www.mediafire.com/file/gr2gh8xoh6fc3es

flac -d --force-legacy-wave-format -c src.flac | sox -V3 --ignore-length -t wav - -b16 -c2 -r44.1k out.wav


sox: SoX v14.4.2
sox FAIL formats: can't open input `-': invalid chunk ID found
f.flac: ERROR, decoded number of samples is smaller than the total number of samples set in the STREAMINFO

[LigH]

Barough only compiled and provided binaries for download. And this is not a thread to discuss issues. I would recommend to discuss your problem in a separate thread in an audio related category, and we would need a lot more information about your source file, possibly even a copy, to confirm it in the first place. I could imagine that this might only happen with a specific combination of channel layout and sample formats...

[tebasuna51]

It is not a sox problem but flac STDOUT output, I can reproduce the problem with any flac input file.

By the moment you need to do it in two steps:

flac -d -o src.wav -c src.flac
sox -V3 --ignore-length -t wav src.wav -b16 -c2 -r44.1k out.wav

Or use ffmpeg with sox resampler also:

ffmpeg -i src.flac -af aresample=44100:resampler=soxr out.wav

[LigH]

Thank your for splitting the thread.

[tebasuna51]

I found than sox accept wav files with RF64 headers then the recommended two pass method to support big files must be:

flac -d --force-rf64-format -o rf64.wav src.flac
src.flac: done

sox -V6 rf64.wav -b16 -c2 -r44.1k out.wav
sox:      SoX v14.4.2
time:     May 23 2024 21:40:13
compiler: gcc 14.1.0
arch:     1248 48 88 L OMP
sox INFO formats: detected file format type `wav'
sox DBUG wav: Found RF64 header
sox DBUG wav: Found chunk 'ds64', size 28
sox DBUG wav: Found chunk 'fmt ', size 16
sox DBUG wav: Found chunk 'data', size 4294967295

Input File     : 'rf64.wav'
Channels       : 2
Sample Rate    : 48000
Precision      : 16-bit
Duration       : 00:00:20.00 = 960000 samples ~ 1500 CDDA sectors
File Size      : 3.84M
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: PCM format, 2 channels, 44100 samp/sec
sox DBUG wav:         176400 byte/sec, 4 block align, 16 bits/samp

Output File    : 'out.wav'
Channels       : 2
Sample Rate    : 44100
Precision      : 16-bit
Duration       : 00:00:20.00 = 882000 samples = 1500 CDDA sectors
Sample Encoding: 16-bit Signed Integer PCM
Endian Type    : little
...
sox DBUG wav: Finished writing Wave file, 3528000 data bytes 882000 samples

We don't need the --ignore-length parameter for sox

[d9probe]

The same error can also be reproduced on files such as APE music
The problem is not with the flac program.
Maybe the music files are not standardized.
But the most important problem is the sox program.
The 32-bit version provided on the SF website works properly.
https://sourceforge.net/projects/sox/files/sox/14.4.2/
Maybe some patches introduced after the SF stable version caused the bug.
But I don't know what happened exactly.

[tebasuna51]

You are right that old (2015) 32 bits version work fine:

flac -d --force-rf64-format -c src.flac | sox -V6 -t wav - -b16 -c2 -r44.1k out8.wav

flac git-cfe3afca 20240516...

sox:      SoX v14.4.2
time:     Feb 22 2015 15:05:01
compiler: gcc 4.9.2 20141030 (Fedora MinGW 4.9.2-1.fc21)
arch:     1248 48 44 L OMP
sox DBUG wav: Searching for 64 73 36 34
sox DBUG wav: WAV Chunk ds64
sox DBUG wav: Found ds64 header
sox DBUG wav: Searching for 66 6d 74 20
sox DBUG wav: WAV Chunk fmt
sox DBUG wav: Searching for 64 61 74 61
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, 3840000 data bytes
sox DBUG wav:         960000 Samps/chans
...
src.flac: done
sox DBUG wav: Finished writing Wave file, 3528000 data bytes 882000 samples

Seems something related with the 'pipe' data transmisions.
The new versions also FAIL when 'pipe' from eac3to, tested longtime ago successfully.
Tested last 32 and 64 bits sox versions.

eac3to.exe src.flac stdout.wav -simple | sox.exe -V6 -t wav - -b16 -c2 -r44.1k src.flac_.wav
SoX v14.4.2
time: May 23 2024 21:10:30
compiler: gcc 14.1.0
arch: 1248 48 44 L OMP
C:\Portable\eac3to\UsEac3to\sox.exe DBUG wav: Found chunk 'fmt ', size 16
C:\Portable\eac3to\UsEac3to\sox.exe FAIL formats: can't open input `-': invalid chunk ID found

[tebasuna51]

Waiting to sources used for Barough to build the SoX Binary v14.4.2 (2024-05-23) and the changelog than improve the official v14.4.2 from 2015 I found some binaries v14.4.2 2017 and also a v14.4.3 from 2020.

Both of them work fine with the flac/eac3to 'pipe'.

[tebasuna51]

Open https://sourceforge.net/p/sox/bugs/375/

[d9probe]

Originally Posted by tebasuna51

Open https://sourceforge.net/p/sox/bugs/375/

Thank you!
Hope there will be a good result...

[martinwguy]

Hi!
NetRanger wrote to me about this to see if sox_ng suffered from the same problem, and I thought I'd summarise here for others.

Using the same command line

flac -d --force-legacy-wave-format -c src.flac | sox -V3 --ignore-length -t wav - -b16 -c2 -r44.1k out.wav

with Debian SoX (which is sox-14.4.2 with some patches) and with sox_ng-14.6.1 it produces out.wav OK.

If someone is building from sox.sf.net development branch, that is known to have more bugs than 14.4.2
In fact, sox_ng is based on the 14.4.2 release, not the development branch.

The Win binaries used in the thread in question
https://forum.doom9.org/showthread.php?p=2002181
is compiled with media-autobuild_suite (https://github.com/m-ab-s/media-autobuild_suite)

Source used for SoX in 'mabs'
SOURCE_REPO_SOX=https://git.code.sf.net/p/sox/code

Ah yes, they used the development branch then. Not good.
I've imported some ideas, improvements and fixes from there but it's not healthy. Mansr did some sterling work when he took SoX over, like adding DSD format support and is an acute DSP programmer but doesn't know about software maintenance, releases and social aspects of open source development, something I had to study somewhat to make the sox_ng project work.
See https://codeberg.org/sox_ng/sox_ng/wiki/BUGS for an idea of how many of the issues on sox.sf.net regard only the development branch: those in the first big table flagged 42b355, the May 2021 commit that a few distros picked up, not having seen a new release for 9 years, hoping to get something better.

About v14.6.1....... is it far from being officially released or?

It just happened, a few minutes ago.
https://codeberg.org/sox_ng/sox_ng/releases

Thanks for the input; if you notice any problems with it, do get in touch

M

[Z2697]

Hi @martinwguy, I was trying to use sox_ng as "drop-in" replacement of sox in media-autobuild_suite, but with no success.
There are multiple definition of 'gsm_create' conflict with libsndfile, I have no success trying to disable libgsm in sox_ng.
I then disabled libsndfile and get:

undefined reference to `lsx_stat'
undefined reference to `lsx_unlink'
undefined reference to `lsx_fopen'
undefined reference to `win32_utf16_to_utf8'

What else should I try?