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
-----------------------------------------------------------------------
Martin RATINAUD
-----------------------------------------------------------------------
On Thu, Dec 12, 2019 at 9:06 PM Jeremy Nicoll - ml sox users <jn.ml.sxu.88@xxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/sox-users
_______________________________________________ Sox-users mailing list Sox-users@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/sox-users
