sox-users@lists.sourceforge.net unofficial mirror
 help / color / mirror / code / Atom feed
From: Martin Ratinaud <martinratinaud@gmail.com>
To: sox-users@lists.sourceforge.net
Subject: Re: Wav to Mp3 leads to an mp3 file that has a longer duration
Date: Mon, 16 Dec 2019 09:10:18 +0400	[thread overview]
Message-ID: <CAKy7tYi_1nF4xH_2_ZmNdRKEzB1cMqmHobigW4xGaWS0WMYfuw@mail.gmail.com> (raw)
In-Reply-To: <ddfec8d454f10eda5fe71d8caeb3c605@wingsandbeaks.org.uk>


[-- Attachment #1.1: Type: text/plain, Size: 6022 bytes --]

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
>

[-- Attachment #1.2: Type: text/html, Size: 7744 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]



[-- Attachment #3: Type: text/plain, Size: 158 bytes --]

_______________________________________________
Sox-users mailing list
Sox-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-users

  reply	other threads:[~2019-12-16  5:11 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
2019-12-16  5:10       ` Martin Ratinaud [this message]
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=CAKy7tYi_1nF4xH_2_ZmNdRKEzB1cMqmHobigW4xGaWS0WMYfuw@mail.gmail.com \
    --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).