Thanks Jeremy but I still do not get what happens and I can't make it work.

So I'm a bit stuck with these generated files 25ms longer which I ca -nnot
crop for an unknown reason :-)

Does anybody know of another library I could use? Or anybody has an idea on
what I could do next :-)

Thanks a lot


-----------------------------------------------------------------------
*Martin RATINAUD*
-----------------------------------------------------------------------


On Thu, Dec 12, 2019 at 9:06 PM Jeremy Nicoll - ml sox users <
jn.ml.sxu.88@wingsandbeaks.org.uk> wrote:

> On 2019-12-12 04:18, Martin Ratinaud wrote:
> > Hi Jeremy and thanks for the quick answer (and sorry for the not very
> > precise report)
>
> OK.  First, I'm not sure if anything I say will help; I can't search for
> bugs inside sox, and I cannot repair them.  But I asked for those
> details
> because other more-knowledgeable people might also have wanted to know.
>
> Next, I use sox on Windows 8.1; I was never able to make any of its mp3
> actions work.  It would always complain that there were missing DLLs.
> (I was using pre-built binaries.)
>
> I tried asking about that here, but no-one helped.  I tried placing DLLs
> in the folder in which I have sox.exe and also in folders in PATH, and
> none of those solved the problem.
>
> If your sox needs to call lame (or use lame-enc.dlls) I wonder if there
> is any way you can identify if the right dlls are being found?
>
>
> Eventually I worked around it by installing lame.exe and its DLLs.  I
> then
> did all the initial manipulation of my recordings - .wav files - in sox
> (which seemed to work) then explicitly called lame.exe to generate .mp3
> files from it.
>
> I did all of that from scripts; none of the scripts ever eg issued
>
>    sox ...        or lame ...
>
> but instead always issued
>
>    "C:\path\tothe\versionofsox\sox.exe" ...
>
> and
>
>    "C:\path\tothe\versionoflame\lame.exe" ...
>
> so I was always certain which .exe files wre being used.  (And in future
> would be able to try newer versions of sox and compare them.)  I also
> prefer to issue commands with defaults explicitly specified, so that I
> knew where the processing parameters I wanted had come from.
>
> In my mp3 conversions, my scripts typically issued commands like
>
> "C:\Dropbox\Programs--ALL-\~open-source lame 64b-V3-99-5\lame.exe"
>     --cbr -b 128 -q 0
>     --verbose
>     --id3v2-only
>     --ta "Name of choir"
>     --tl "Name of album"
>     --tg Classical
>     --ty 2015
>     --tt "Track name"
>     --tn 11
>     "C:\Dropbox\....\20150615_S_11_xyz.wav"
>     "C:\Users\....\Album\MP3s-128\20150615_S_11_xyz.mp3"
>
> (where all of that was on one long line, but it's spread out here so
> you can see each element).
>
>
> I still think it's possible that you're not executing the command you
> think you are.  I don't now anything about Macs though.  If SOX_OPTS
> is null, are there any other mechanisms that might be interfering?  Eg
> when you issue
>
>     sox
>
> could that be aliased to something else that codes some defaults?
>
>
> Also, your    sox --version    should have produced a result that told
> you the version number, but apparently doesn't.  I wonder if the build
> is broken somehow.  Here, I get
>
> C:\>"C:\Dropbox\Programs--ALL-\~open-source sox V14-4-2\sox.exe"
> --version
> C:\Dropbox\Programs--ALL-\~open-source sox V14-4-2\sox.exe:      SoX
> v14.4.2
>
> ... and note it shows "SoX v14.4.2".
>
>
> I also wondered if the "soxi" you are executing really is the same
> executable
> as your "sox"?   They are meant to be copies of the same file, with
> different
> names...
>
>
>
> Have you tried the command on other files?  Does converting a .wav to
> .mp3
> always produce a longer file, or only sometimes, or only with one file?
>
>
> In several instances you show commands where the input file is described
> as
> 16-bit, but the output as 24-bit... and then soxi says the created file
> is
> really 16-bit.
>
> I wonder if the info message that describes an output file as 24-bit is
> really just telling you what you've asked for, rather than what will be
> generated?  (Or, sox is internally processsing the input file to create
> a 24-bit one, and only at the final stage when lame gets involved does
> the resolution drop?)
>
>
> I am puzzled by the statement that sox is using mp3 encoding defaults
>
>   sox INFO mp3: using MP3 encoding defaults
>
> because I couldn't find anything in the sox documentation that says what
> they are.  Maybe those are lame defaults?
>
> But that precedes the info that it's creating a 24-bit output file which
> suggests that "24 bit output" is defined somewhere as a default.  I
> wonder
> where?
>
>
> It's also odd that if sox really was trying to produce a 24-bit output
> file
> it doesn't produce the warning that you got later.  That is, when you
> had
>
>   sox -V3 vocals.wav -b 24 vocals-V3.mp3
>
> it produced a WARN message saying
>
>   sox WARN formats: mp3 can't encode to 24-bit
>
> but on your earlier calls of sox, with no -V parameter, sox is meant to
> have defaulted to -V2 and produced errors and warnings.
>
> So either it really was trying to produce 24-bit audio on the earlier
> uses,
> but didn't produce the WARN message even though it is meant to, or
> earlier
> it wasn't trying to produce 24-bit files (so there was no warning) even
> though it said it was...
>
>
>
> With your trim attempt, I have no idea why it didn't work.  Your
> description
> is wrong though: it says it did remove 1147 samples, but for some reason
> failed to trim the other 397.
>
>
> I can't replicate your commands because, as I said, mp3 processing
> doesn't
> work for me with sox under W8.1.
>
> I hope someone else comes along and tries this, preferably on another
> Mac.
>
>
> --
> Jeremy Nicoll - my opinions are my own
>
>
> _______________________________________________
> Sox-users mailing list
> Sox-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/sox-users
>