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
