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
next prev parent 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).