sox-users@lists.sourceforge.net unofficial mirror
 help / color / mirror / code / Atom feed
From: Jeremy Nicoll - ml sox users <jn.ml.sxu.88@wingsandbeaks.org.uk>
To: sox-users@lists.sourceforge.net
Subject: Re: Wav to Mp3 leads to an mp3 file that has a longer duration
Date: Thu, 12 Dec 2019 17:05:19 +0000	[thread overview]
Message-ID: <ddfec8d454f10eda5fe71d8caeb3c605@wingsandbeaks.org.uk> (raw)
In-Reply-To: <CAKy7tYjzWfKBVozehA2HCrRk2y2aJ_FQUF_iAf3A10ZKh+C+FQ@mail.gmail.com>

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

  reply	other threads:[~2019-12-12 17:05 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-11 14:26 Wav to Mp3 leads to an mp3 file that has a longer duration Martin Ratinaud
2019-12-11 17:18 ` Jeremy Nicoll - ml sox users
2019-12-12  4:18   ` Martin Ratinaud
2019-12-12 17:05     ` Jeremy Nicoll - ml sox users [this message]
2019-12-16  5:10       ` Martin Ratinaud
2019-12-16 11:48 ` Måns Rullgård
2019-12-16 12:02   ` Martin Ratinaud
2019-12-16 13:30     ` Måns Rullgård
2019-12-16 13:36       ` Martin Ratinaud
2019-12-16 17:44         ` Måns Rullgård
2019-12-17 10:04           ` Martin Ratinaud
2019-12-17 10:50             ` Måns Rullgård
2019-12-18  4:00               ` Martin Ratinaud
2019-12-18  7:43                 ` Mikko Olkkonen
2019-12-18  9:06                   ` Martin Ratinaud
2019-12-19  9:52                     ` Mikko Olkkonen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.sourceforge.net/lists/listinfo/sox-users

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ddfec8d454f10eda5fe71d8caeb3c605@wingsandbeaks.org.uk \
    --to=sox-users@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/sox.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).