From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS6130 216.105.38.0/24 X-Spam-Status: No, score=-3.4 required=3.0 tests=AWL,BAYES_00, DKIM_ADSP_CUSTOM_MED,DKIM_INVALID,DKIM_SIGNED, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, HTML_MESSAGE,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,SPF_HELO_PASS, SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from lists.sourceforge.net (lists.sourceforge.net [216.105.38.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id B1AD41F463 for ; Mon, 16 Dec 2019 05:11:10 +0000 (UTC) Received: from [127.0.0.1] (helo=sfs-ml-1.v29.lw.sourceforge.com) by sfs-ml-1.v29.lw.sourceforge.com with esmtp (Exim 4.90_1) (envelope-from ) id 1igies-0001Vf-C6; Mon, 16 Dec 2019 05:11:02 +0000 Received: from [172.30.20.202] (helo=mx.sourceforge.net) by sfs-ml-1.v29.lw.sourceforge.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1igiej-0001U1-CV for sox-users@lists.sourceforge.net; Mon, 16 Dec 2019 05:10:53 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sourceforge.net; s=x; h=Content-Type:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Sender:Reply-To:Cc: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=r6mKu973j3/9ccpXfQGwiU+hIn312KQMfFbgldc/orA=; b=gNN9/1tNhGiD4rz8MLicmBbBm rIZN1Gd6ijNmwr4Y7xzRTk/lCTgQ5Esn6ZgaQbliFOSj+0I3FESwy2PQVOxtYe5s1yesJ99WFMWyj MtAak83xG2TD3P6kXAjDIwkNiUCJXRIBk0vslOV38MqpmvKexaINMa2uKw8+Ouf6com3Q=; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sf.net; s=x ; h=Content-Type:To:Subject:Message-ID:Date:From:In-Reply-To:References: MIME-Version:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=r6mKu973j3/9ccpXfQGwiU+hIn312KQMfFbgldc/orA=; b=Vfyi5ybFB4240vp0HD5Et/BP8t MtZUJhxBTwN7E7bVGaILwLO5k/2Ydvkb/aATShiMUCD1ibR2Ij4jJ4vfKQZwvlBXQn6xvuZoxFgBv V3Emm+pzbAi9sBqBUnvoUBUVvjzGvQjqYvUwTLEKCC7am7EPDgljOH9VuHrpCVt4cSsE=; Received: from mail-qk1-f170.google.com ([209.85.222.170]) by sfi-mx-1.v28.lw.sourceforge.com with esmtps (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92.2) id 1igieh-00CzNc-Az for sox-users@lists.sourceforge.net; Mon, 16 Dec 2019 05:10:53 +0000 Received: by mail-qk1-f170.google.com with SMTP id d71so2395613qkc.0 for ; Sun, 15 Dec 2019 21:10:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=r6mKu973j3/9ccpXfQGwiU+hIn312KQMfFbgldc/orA=; b=kkcmGdNKyr8uRlwc34v+tBVrUpkxOSUXPp+T+e2UMd0H0QDzgitwCDsylB15iIxpbO MD9JU36osgRgbOFKYyHevA410iWdTbg0oiETYSqkakIZIS827ry9+xIkrtyTRiRCL6FI JaalDwhmDBXh9gL1n3YjAnZu9aycXpdIxo515rlyWepzafGCtCKZksVhqtNNCXY7FqLu 2egFMABsRzUliGxknCZIE1TspeEcWMUkgLI0aReHaRRe5scEh4EcJzvrJ51SOnXhNdor a/sOwEiWfzod5jQW3WXjnk/6pUwb1iYnNK6CAWZWU4CKDeUCfETM0CXfO5hpt/YbCpiG MEzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=r6mKu973j3/9ccpXfQGwiU+hIn312KQMfFbgldc/orA=; b=m9ZUHkn4+XaPCgVn2PX++QxPir4yexOfKkRaLo0lbpkfxuA2hhljg7s2CEcTxOdi1t mFCT8zkT86ISdxRgAS4YuqMWtxNlBmCHB86q9mv0JeIwJo7U9ho5BcpAEEW27EXGC0xq BcSihxPNaYTZiDbieISlLwy8jclAdJBinQKxaANlf6fAwKUTSaOTe8IPH0SqTjm3xAqK bfrOaw0HODkglXVeWfg+r4exgrUGg6G/mDjQUmD3Wocm7woX3z8yqVlxmHggDFDiyacO Gs/cjAqkE9xZxVbjV5T6al4WCJTR2rQTndDctphTR8O6TzU02z4EyWh3wlIpxqaP1nMV rniA== X-Gm-Message-State: APjAAAVfABDycu7DwdpgDfd9m1nJtFudQLNrAt/ANeuJsP7E4USW0t+a Mv5ReUAmpJyejHJGfas7Nf8mqnJ95O5ldlutSUHMYTI= X-Google-Smtp-Source: APXvYqzR0is0hqO7RI6l/xw95l7is/aT16PnF2b/x9Ur+AwKWbGdatf8Q7Ktf+P6b3D4CHiQuiOpDCuz7F5wMb2U5g4= X-Received: by 2002:a37:3d8:: with SMTP id 207mr17864144qkd.335.1576473044852; Sun, 15 Dec 2019 21:10:44 -0800 (PST) MIME-Version: 1.0 References: <6b2ed34b929889fb655800973e7e030e@wingsandbeaks.org.uk> In-Reply-To: From: Martin Ratinaud Date: Mon, 16 Dec 2019 09:10:18 +0400 Message-ID: To: sox-users@lists.sourceforge.net X-Headers-End: 1igieh-00CzNc-Az Subject: Re: Wav to Mp3 leads to an mp3 file that has a longer duration X-BeenThere: sox-users@lists.sourceforge.net X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: sox-users@lists.sourceforge.net Content-Type: multipart/mixed; boundary="===============1158286649062250532==" Errors-To: sox-users-bounces@lists.sourceforge.net --===============1158286649062250532== Content-Type: multipart/alternative; boundary="000000000000d628250599cb3bf6" --000000000000d628250599cb3bf6 Content-Type: text/plain; charset="UTF-8" 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 > --000000000000d628250599cb3bf6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Jeremy but I still do not get what happens and I ca= n'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
--------------------------= ---------------------------------------------

<= /div>

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<= br> > precise report)

OK.=C2=A0 First, I'm not sure if anything I say will help; I can't = search for
bugs inside sox, and I cannot repair them.=C2=A0 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.=C2=A0 It would always complain that there were missing DLLs.<= br> (I was using pre-built binaries.)

I tried asking about that here, but no-one helped.=C2=A0 I tried placing DL= Ls
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.=C2=A0 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

=C2=A0 =C2=A0sox ...=C2=A0 =C2=A0 =C2=A0 =C2=A0 or lame ...

but instead always issued

=C2=A0 =C2=A0"C:\path\tothe\versionofsox\sox.exe" ...

and

=C2=A0 =C2=A0"C:\path\tothe\versionoflame\lame.exe" ...

so I was always certain which .exe files wre being used.=C2=A0 (And in futu= re
would be able to try newer versions of sox and compare them.)=C2=A0 I also<= br> 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"= ;
=C2=A0 =C2=A0 --cbr -b 128 -q 0
=C2=A0 =C2=A0 --verbose
=C2=A0 =C2=A0 --id3v2-only
=C2=A0 =C2=A0 --ta "Name of choir"
=C2=A0 =C2=A0 --tl "Name of album"
=C2=A0 =C2=A0 --tg Classical
=C2=A0 =C2=A0 --ty 2015
=C2=A0 =C2=A0 --tt "Track name"
=C2=A0 =C2=A0 --tn 11
=C2=A0 =C2=A0 "C:\Dropbox\....\20150615_S_11_xyz.wav"
=C2=A0 =C2=A0 "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 y= ou
think you are.=C2=A0 I don't now anything about Macs though.=C2=A0 If S= OX_OPTS
is null, are there any other mechanisms that might be interfering?=C2=A0 Eg=
when you issue

=C2=A0 =C2=A0 sox

could that be aliased to something else that codes some defaults?


Also, your=C2=A0 =C2=A0 sox --version=C2=A0 =C2=A0 should have produced a r= esult that told
you the version number, but apparently doesn't.=C2=A0 I wonder if the b= uild
is broken somehow.=C2=A0 Here, I get

C:\>"C:\Dropbox\Programs--ALL-\~open-source sox V14-4-2\sox.exe&quo= t;
--version
C:\Dropbox\Programs--ALL-\~open-source sox V14-4-2\sox.exe:=C2=A0 =C2=A0 = =C2=A0 SoX
v14.4.2

... and note it shows "SoX v14.4.2".


I also wondered if the "soxi" you are executing really is the sam= e
executable
as your "sox"?=C2=A0 =C2=A0They are meant to be copies of the sam= e file, with
different
names...



Have you tried the command on other files?=C2=A0 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?=C2=A0 (Or, sox is internally processsing the input file to creat= e
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

=C2=A0 sox INFO mp3: using MP3 encoding defaults

because I couldn't find anything in the sox documentation that says wha= t
they are.=C2=A0 Maybe those are lame defaults?

But that precedes the info that it's creating a 24-bit output file whic= h
suggests that "24 bit output" is defined somewhere as a default.= =C2=A0 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.=C2=A0 That is, when = you
had

=C2=A0 sox -V3 vocals.wav -b 24 vocals-V3.mp3

it produced a WARN message saying

=C2=A0 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.=C2=A0 Your <= br> 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-us= ers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/s= ox-users
--000000000000d628250599cb3bf6-- --===============1158286649062250532== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============1158286649062250532== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sox-users mailing list Sox-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sox-users --===============1158286649062250532==--