Thanks Peter,
I'm aware of the frame/chunk granularity at the end, I'm talking about serious truncation, e.g. 30min input wav, with a 4 minute MP3. Without the "norm" argument, everything reliably processes as expected.
Cheers,
Scott
On 18 Jun. 2021, at 1:54 am, "Peter P." < peterparker@xxxxxxxxxxxx> wrote:
Hi Scott,
encountered a similar thing and was told that the file length of mp3
files has a lower resolution as it stores data in chunks. If your .wav
is a bit longer than the mp3 but not long enough to fill up another
chunk at the end this might get discarded. Don't quote me on this, just
remembering something I asked here years ago...
* Scott Temby <scottt@xxxxxxxxxxxxxxx> [2021-06-17 16:03]:
Hi,
When using "sox.exe *<source_file>.wav* -C 192.01
*<destination_file>.mp3* norm"
I've found the output is occasionally truncated (shorter duration than the
input, but matches up to that point).
I've tried this on a few systems, and while the fault is intermittent (not
linked to any particular input file or condition), it does repeatedly occur
(a few times in a "batch"). Immediately re-processing the same input files
often yields success, or at least, failures on different files. I've also
tried -C 192.2 to see if that was the issue, and it is not. removing "norm"
solves the problem, and I can reliably encode thousands of files without
truncation.
Hopefully there's an easy fix, if not, at least you are now aware of the
issue.
Regards,
Scott
Sox-users mailing list
Sox-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/sox-users
Sox-users mailing list
Sox-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/sox-users
|
_______________________________________________
Sox-users mailing list
Sox-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/sox-users
