Wav to Mp3 leads to an mp3 file that has a longer duration

Wav to Mp3 leads to an mp3 file that has a longer duration

[Martin Ratinaud]

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

Hi all,

I'm converting a file called vocals.wav to vocals.mp3
 vocals.wav
<https://drive.google.com/file/d/1he1eCJag1G8iGkgL932jy_mXuLT_khGM/view?usp=drive_web>
For this I'm using this command

```
sox vocals.wav vocals.mp3
```
and here is the result of the corresponding files

- original file
```
soxi /Users/martin/Downloads/split-test/vocals.wav

Input File     : '/Users/martin/Downloads/split-test/vocals.wav'
Channels       : 2
Sample Rate    : 44100
Precision      : 16-bit
Duration       : 00:03:00.00 = 7938000 samples = 13500 CDDA sectors
File Size      : 31.8M
Bit Rate       : 1.41M
Sample Encoding: 16-bit Signed Integer PCM
```

- converted file
```
soxi /Users/martin/Downloads/split-test/vocals.mp3

Input File     : '/Users/martin/Downloads/split-test/vocals.mp3'
Channels       : 2
Sample Rate    : 44100
Precision      : 16-bit
Duration       : 00:03:00.04 = 7939544 samples = 13502.6 CDDA sectors
File Size      : 2.88M
Bit Rate       : 128k
Sample Encoding: MPEG audio (layer I, II or III)
```

You can see that the duration is not the same which is weird and the number
of samples also changed.
In fact, 1544 samples have been added to the beginning of the file

If I try to launch `sox -V vocals.mp3 vocals-trimmed.mp3 trim 1544s` it
does not work

Can you please help me

Thanks



-----------------------------------------------------------------------
*Martin RATINAUD*
-----------------------------------------------------------------------

[-- Attachment #1.2: Type: text/html, Size: 3022 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

Re: Wav to Mp3 leads to an mp3 file that has a longer duration

[Jeremy Nicoll - ml sox users]

On 2019-12-11 14:26, Martin Ratinaud wrote:
> Hi all,
> 
> I'm converting a file called vocals.wav to vocals.mp3
>  vocals.wav
> <https://drive.google.com/file/d/1he1eCJag1G8iGkgL932jy_mXuLT_khGM/view?usp=drive_web>
> For this I'm using this command
> 
> ```
> sox vocals.wav vocals.mp3
> ```
> and here is the result of the corresponding files
> 
> - original file
> ```
> soxi /Users/martin/Downloads/split-test/vocals.wav
> 
> Input File     : '/Users/martin/Downloads/split-test/vocals.wav'
> Channels       : 2
> Sample Rate    : 44100
> Precision      : 16-bit
> Duration       : 00:03:00.00 = 7938000 samples = 13500 CDDA sectors
> File Size      : 31.8M
> Bit Rate       : 1.41M
> Sample Encoding: 16-bit Signed Integer PCM
> ```
> 
> - converted file
> ```
> soxi /Users/martin/Downloads/split-test/vocals.mp3
> 
> Input File     : '/Users/martin/Downloads/split-test/vocals.mp3'
> Channels       : 2
> Sample Rate    : 44100
> Precision      : 16-bit
> Duration       : 00:03:00.04 = 7939544 samples = 13502.6 CDDA sectors
> File Size      : 2.88M
> Bit Rate       : 128k
> Sample Encoding: MPEG audio (layer I, II or III)
> ```
> 
> You can see that the duration is not the same which is weird and the 
> number
> of samples also changed.
> In fact, 1544 samples have been added to the beginning of the file


Which version of sox, on what OS?
Did you build the sox binary yourself or download it from somewhere?

Although you say the command was just

   sox vocals.wav vocals.mp3

sox can also incorporate values of environment variables.  Is there any
chance that on your OS the command has included any other parameters?
See the 'SOX_OPTS' section of the manual.


If you reissue the command, as eg

   sox -V3 vocals.wav vocals002.mp3

(or even -V4 or more) do any of the info messsages give any clues?  Is 
the
result file the same size as your one?




> If I try to launch `sox -V vocals.mp3 vocals-trimmed.mp3 trim 1544s` it
> does not work

You'll need to be more precise.  What sort of "not work"?   Does sox 
run?
Does it produce any messages?  Is there a result file?  How long was it?


-- 
Jeremy Nicoll - my opinions are my own


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

Re: Wav to Mp3 leads to an mp3 file that has a longer duration

[Martin Ratinaud]

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

Hi Jeremy and thanks for the quick answer (and sorry for the not very
precise report)

- I'm on OSX Mojave 10.14.6
- sox has been installed through brew `brew install sox`
- `sox --version` gives `sox:      SoX v`
- `brew info sox`gives

```

sox: stable 14.4.2 (bottled)

SOund eXchange: universal sound sample translator

https://sox.sourceforge.io/

/usr/local/Cellar/sox/14.4.2_3 (23 files, 1.8MB) *

  Poured from bottle on 2019-05-17 at 16:19:01

From: https://github.com/Homebrew/homebrew-core/blob/master/Formula/sox.rb

==> Dependencies

Build: pkg-config ✔

Required: flac ✘, lame ✔, libpng ✔, libsndfile ✔, libvorbis ✔, mad ✔,
opusfile ✘

==> Analytics

install: 2,592 (30 days), 7,521 (90 days), 36,263 (365 days)

install-on-request: 2,436 (30 days), 7,051 (90 days), 32,403 (365 days)

build-error: 0 (30 days)

```



- SOX_OPTS is empty when I `echo $SOX_OPTS`

If I launch

```

sox -V3 vocals.wav vocals-V3.mp3

```


I get

```
sox:      SoX v
sox INFO formats: detected file format type `wav'

Input File     : 'vocals.wav'
Channels       : 2
Sample Rate    : 44100
Precision      : 16-bit
Duration       : 00:03:00.00 = 7938000 samples = 13500 CDDA sectors
File Size      : 31.8M
Bit Rate       : 1.41M
Sample Encoding: 16-bit Signed Integer PCM
Endian Type    : little
Reverse Nibbles: no
Reverse Bits   : no

sox INFO sox: Overwriting `vocals-V3.mp3'
sox INFO mp3: using MP3 encoding defaults

Output File    : 'vocals-V3.mp3'
Channels       : 2
Sample Rate    : 44100
Precision      : 24-bit
Duration       : 00:03:00.00 = 7938000 samples = 13500 CDDA sectors
Sample Encoding: MPEG audio (layer I, II or III)
Comment        : 'Processed by SoX'

sox INFO sox: effects chain: input        44100Hz  2 channels
sox INFO sox: effects chain: output       44100Hz  2 channels
```

Which seems good but when I do

```
soxi vocals-V3.mp3
```

I still get a different number of samples and duration

```
Input File     : 'vocals-V3.mp3'
Channels       : 2
Sample Rate    : 44100
Precision      : 16-bit
Duration       : 00:03:00.04 = 7939544 samples = 13502.6 CDDA sectors
File Size      : 2.88M
Bit Rate       : 128k
Sample Encoding: MPEG audio (layer I, II or III)
```

I notice that the precision is different and if I launch

```
sox -V3 vocals.wav -b 24 vocals-V3.mp3
```

It ends up with the same result

```
sox:      SoX v
sox INFO formats: detected file format type `wav'

Input File     : 'vocals.wav'
Channels       : 2
Sample Rate    : 44100
Precision      : 16-bit
Duration       : 00:03:00.00 = 7938000 samples = 13500 CDDA sectors
File Size      : 31.8M
Bit Rate       : 1.41M
Sample Encoding: 16-bit Signed Integer PCM
Endian Type    : little
Reverse Nibbles: no
Reverse Bits   : no

sox WARN formats: mp3 can't encode to 24-bit
sox INFO mp3: using MP3 encoding defaults

Output File    : 'vocals-V3.mp3'
Channels       : 2
Sample Rate    : 44100
Precision      : 24-bit
Duration       : 00:03:00.00 = 7938000 samples = 13500 CDDA sectors
Sample Encoding: MPEG audio (layer I, II or III)
Comment        : 'Processed by SoX'

sox INFO sox: effects chain: input        44100Hz  2 channels
sox INFO sox: effects chain: output       44100Hz  2 channels
```

but

```
soxi vocals-V3.mp3
```

still gives

```
Input File     : 'vocals-V3.mp3'
Channels       : 2
Sample Rate    : 44100
Precision      : 16-bit
Duration       : 00:03:00.04 = 7939544 samples = 13502.6 CDDA sectors
File Size      : 2.88M
Bit Rate       : 128k
Sample Encoding: MPEG audio (layer I, II or III)
```

Here a try with V4 ```sox -V4 vocals.wav vocals-V4.mp3 && soxi
vocals-V4.mp3```

```
sox:      SoX v
time:     Jan  9 2019 13:31:37
uname:    Darwin MBP-de-Martin 18.7.0 Darwin Kernel Version 18.7.0: Tue Aug
20 16:57:14 PDT 2019; root:xnu-4903.271.2~2/RELEASE_X86_64 x86_64
compiler: gcc 4.2.1 Compatible Apple LLVM 10.0.0 (clang-1000.11.45.5)
arch:     1288 48 88 L
sox INFO formats: detected file format type `wav'
sox DBUG wav: Searching for 66 6d 74 20
sox DBUG wav: WAV Chunk fmt
sox DBUG wav: Searching for 64 61 74 61
sox DBUG wav: WAV Chunk data
sox DBUG wav: Reading Wave file: Microsoft PCM format, 2 channels, 44100
samp/sec
sox DBUG wav:         176400 byte/sec, 4 block align, 16 bits/samp,
31752000 data bytes
sox DBUG wav:         7938000 Samps/chans
sox DBUG wav: Searching for 4c 49 53 54

Input File     : 'vocals.wav'
Channels       : 2
Sample Rate    : 44100
Precision      : 16-bit
Duration       : 00:03:00.00 = 7938000 samples = 13500 CDDA sectors
File Size      : 31.8M
Bit Rate       : 1.41M
Sample Encoding: 16-bit Signed Integer PCM
Endian Type    : little
Reverse Nibbles: no
Reverse Bits   : no

sox DBUG mp3: -C option is inf
sox INFO mp3: using MP3 encoding defaults

Output File    : 'vocals-V4.mp3'
Channels       : 2
Sample Rate    : 44100
Precision      : 24-bit
Duration       : 00:03:00.00 = 7938000 samples = 13500 CDDA sectors
Sample Encoding: MPEG audio (layer I, II or III)
Comment        : 'Processed by SoX'

sox INFO sox: effects chain: input        44100Hz  2 channels (multi) 16
bits 00:03:00.00
sox INFO sox: effects chain: output       44100Hz  2 channels (multi) 24
bits 00:03:00.00
sox DBUG sox: start-up time = 0.001929

Input File     : 'vocals-V4.mp3'
Channels       : 2
Sample Rate    : 44100
Precision      : 16-bit
Duration       : 00:03:00.04 = 7939544 samples = 13502.6 CDDA sectors
File Size      : 2.88M
Bit Rate       : 128k
Sample Encoding: MPEG audio (layer I, II or III)
```


And same with V5, V6 etc..

For  the trimming
I noticed there are 1544 more samples in the resulting mp3 file, so I tried
to trim them using this command

```
sox -V3 vocals.mp3 vocals-trimmed.mp3 trim 1544s && soxi vocals-trimmed.mp3
```


which gives

```
sox:      SoX v

Input File     : 'vocals.mp3'
Channels       : 2
Sample Rate    : 44100
Precision      : 16-bit
Duration       : 00:03:00.04 = 7939544 samples = 13502.6 CDDA sectors
File Size      : 2.88M
Bit Rate       : 128k
Sample Encoding: MPEG audio (layer I, II or III)

sox INFO sox: Overwriting `vocals-trimmed.mp3'
sox INFO mp3: using MP3 encoding defaults

Output File    : 'vocals-trimmed.mp3'
Channels       : 2
Sample Rate    : 44100
Precision      : 24-bit
Sample Encoding: MPEG audio (layer I, II or III)
Comment        : 'Processed by SoX'

sox INFO sox: effects chain: input        44100Hz  2 channels
sox INFO sox: effects chain: trim         44100Hz  2 channels
sox INFO sox: effects chain: output       44100Hz  2 channels

Input File     : 'vocals-trimmed.mp3'
Channels       : 2
Sample Rate    : 44100
Precision      : 16-bit
Duration       : 00:03:00.01 = 7938397 samples = 13500.7 CDDA sectors
File Size      : 2.88M
Bit Rate       : 128k
Sample Encoding: MPEG audio (layer I, II or III)
```


So "it does not work" means, the resulting file is not exactly trimmed of
1544s as expected because there are 1147 left

It takes approximately 3s

I hope the description is clearer
Let me know if I can give you more information

Thanks

-----------------------------------------------------------------------
*Martin RATINAUD*
-----------------------------------------------------------------------


On Wed, Dec 11, 2019 at 9:39 PM Jeremy Nicoll - ml sox users <
jn.ml.sxu.88@wingsandbeaks.org.uk> wrote:

> On 2019-12-11 14:26, Martin Ratinaud wrote:
> > Hi all,
> >
> > I'm converting a file called vocals.wav to vocals.mp3
> >  vocals.wav
> > <
> https://drive.google.com/file/d/1he1eCJag1G8iGkgL932jy_mXuLT_khGM/view?usp=drive_web
> >
> > For this I'm using this command
> >
> > ```
> > sox vocals.wav vocals.mp3
> > ```
> > and here is the result of the corresponding files
> >
> > - original file
> > ```
> > soxi /Users/martin/Downloads/split-test/vocals.wav
> >
> > Input File     : '/Users/martin/Downloads/split-test/vocals.wav'
> > Channels       : 2
> > Sample Rate    : 44100
> > Precision      : 16-bit
> > Duration       : 00:03:00.00 = 7938000 samples = 13500 CDDA sectors
> > File Size      : 31.8M
> > Bit Rate       : 1.41M
> > Sample Encoding: 16-bit Signed Integer PCM
> > ```
> >
> > - converted file
> > ```
> > soxi /Users/martin/Downloads/split-test/vocals.mp3
> >
> > Input File     : '/Users/martin/Downloads/split-test/vocals.mp3'
> > Channels       : 2
> > Sample Rate    : 44100
> > Precision      : 16-bit
> > Duration       : 00:03:00.04 = 7939544 samples = 13502.6 CDDA sectors
> > File Size      : 2.88M
> > Bit Rate       : 128k
> > Sample Encoding: MPEG audio (layer I, II or III)
> > ```
> >
> > You can see that the duration is not the same which is weird and the
> > number
> > of samples also changed.
> > In fact, 1544 samples have been added to the beginning of the file
>
>
> Which version of sox, on what OS?
> Did you build the sox binary yourself or download it from somewhere?
>
> Although you say the command was just
>
>    sox vocals.wav vocals.mp3
>
> sox can also incorporate values of environment variables.  Is there any
> chance that on your OS the command has included any other parameters?
> See the 'SOX_OPTS' section of the manual.
>
>
> If you reissue the command, as eg
>
>    sox -V3 vocals.wav vocals002.mp3
>
> (or even -V4 or more) do any of the info messsages give any clues?  Is
> the
> result file the same size as your one?
>
>
>
>
> > If I try to launch `sox -V vocals.mp3 vocals-trimmed.mp3 trim 1544s` it
> > does not work
>
> You'll need to be more precise.  What sort of "not work"?   Does sox
> run?
> Does it produce any messages?  Is there a result file?  How long was it?
>
>
> --
> 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: 16355 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

Re: Wav to Mp3 leads to an mp3 file that has a longer duration

[Jeremy Nicoll - ml sox users]

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

Re: Wav to Mp3 leads to an mp3 file that has a longer duration

[Martin Ratinaud]

[-- 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

Re: Wav to Mp3 leads to an mp3 file that has a longer duration

[Måns Rullgård]

Martin Ratinaud <martinratinaud@gmail.com> writes:

> Hi all,
>
> I'm converting a file called vocals.wav to vocals.mp3
>  vocals.wav
> <https://drive.google.com/file/d/1he1eCJag1G8iGkgL932jy_mXuLT_khGM/view?usp=drive_web>
> For this I'm using this command
>
> ```
> sox vocals.wav vocals.mp3
> ```
> and here is the result of the corresponding files
>
> - original file
> ```
> soxi /Users/martin/Downloads/split-test/vocals.wav
>
> Input File     : '/Users/martin/Downloads/split-test/vocals.wav'
> Channels       : 2
> Sample Rate    : 44100
> Precision      : 16-bit
> Duration       : 00:03:00.00 = 7938000 samples = 13500 CDDA sectors
> File Size      : 31.8M
> Bit Rate       : 1.41M
> Sample Encoding: 16-bit Signed Integer PCM
> ```
>
> - converted file
> ```
> soxi /Users/martin/Downloads/split-test/vocals.mp3
>
> Input File     : '/Users/martin/Downloads/split-test/vocals.mp3'
> Channels       : 2
> Sample Rate    : 44100
> Precision      : 16-bit
> Duration       : 00:03:00.04 = 7939544 samples = 13502.6 CDDA sectors
> File Size      : 2.88M
> Bit Rate       : 128k
> Sample Encoding: MPEG audio (layer I, II or III)
> ```
>
> You can see that the duration is not the same which is weird and the number
> of samples also changed.
> In fact, 1544 samples have been added to the beginning of the file
>
> If I try to launch `sox -V vocals.mp3 vocals-trimmed.mp3 trim 1544s` it
> does not work

MP3 files have to have a multiple of 1152 samples.  This can't be
avoided.  If the input isn't such a multiple, it will be padded by the
encoder.

-- 
Måns Rullgård


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

Re: Wav to Mp3 leads to an mp3 file that has a longer duration

[Martin Ratinaud]

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

Hi Måns and thanks very much

Though it seems the resulting file is 7939544 samples

and 7939544 / 1152 = 6891.965277777777

So it's not a multiple of 1152 unless I'm missing something ?

Cheers

-----------------------------------------------------------------------
*Martin RATINAUD*
-----------------------------------------------------------------------


On Mon, Dec 16, 2019 at 3:48 PM Måns Rullgård <mans@mansr.com> wrote:

> Martin Ratinaud <martinratinaud@gmail.com> writes:
>
> > Hi all,
> >
> > I'm converting a file called vocals.wav to vocals.mp3
> >  vocals.wav
> > <
> https://drive.google.com/file/d/1he1eCJag1G8iGkgL932jy_mXuLT_khGM/view?usp=drive_web
> >
> > For this I'm using this command
> >
> > ```
> > sox vocals.wav vocals.mp3
> > ```
> > and here is the result of the corresponding files
> >
> > - original file
> > ```
> > soxi /Users/martin/Downloads/split-test/vocals.wav
> >
> > Input File     : '/Users/martin/Downloads/split-test/vocals.wav'
> > Channels       : 2
> > Sample Rate    : 44100
> > Precision      : 16-bit
> > Duration       : 00:03:00.00 = 7938000 samples = 13500 CDDA sectors
> > File Size      : 31.8M
> > Bit Rate       : 1.41M
> > Sample Encoding: 16-bit Signed Integer PCM
> > ```
> >
> > - converted file
> > ```
> > soxi /Users/martin/Downloads/split-test/vocals.mp3
> >
> > Input File     : '/Users/martin/Downloads/split-test/vocals.mp3'
> > Channels       : 2
> > Sample Rate    : 44100
> > Precision      : 16-bit
> > Duration       : 00:03:00.04 = 7939544 samples = 13502.6 CDDA sectors
> > File Size      : 2.88M
> > Bit Rate       : 128k
> > Sample Encoding: MPEG audio (layer I, II or III)
> > ```
> >
> > You can see that the duration is not the same which is weird and the
> number
> > of samples also changed.
> > In fact, 1544 samples have been added to the beginning of the file
> >
> > If I try to launch `sox -V vocals.mp3 vocals-trimmed.mp3 trim 1544s` it
> > does not work
>
> MP3 files have to have a multiple of 1152 samples.  This can't be
> avoided.  If the input isn't such a multiple, it will be padded by the
> encoder.
>
> --
> Måns Rullgård
>

[-- Attachment #1.2: Type: text/html, Size: 3400 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

Re: Wav to Mp3 leads to an mp3 file that has a longer duration

[Måns Rullgård]

Martin Ratinaud <martinratinaud@gmail.com> writes:

> Hi Måns and thanks very much
>
> Though it seems the resulting file is 7939544 samples
>
> and 7939544 / 1152 = 6891.965277777777
>
> So it's not a multiple of 1152 unless I'm missing something ?

That difference is due to a rounding error in the stream length
calculation.

> On Mon, Dec 16, 2019 at 3:48 PM Måns Rullgård <mans@mansr.com> wrote:
>
>> Martin Ratinaud <martinratinaud@gmail.com> writes:
>>
>> > Hi all,
>> >
>> > I'm converting a file called vocals.wav to vocals.mp3
>> >  vocals.wav
>> > <
>> https://drive.google.com/file/d/1he1eCJag1G8iGkgL932jy_mXuLT_khGM/view?usp=drive_web
>> >
>> > For this I'm using this command
>> >
>> > ```
>> > sox vocals.wav vocals.mp3
>> > ```
>> > and here is the result of the corresponding files
>> >
>> > - original file
>> > ```
>> > soxi /Users/martin/Downloads/split-test/vocals.wav
>> >
>> > Input File     : '/Users/martin/Downloads/split-test/vocals.wav'
>> > Channels       : 2
>> > Sample Rate    : 44100
>> > Precision      : 16-bit
>> > Duration       : 00:03:00.00 = 7938000 samples = 13500 CDDA sectors
>> > File Size      : 31.8M
>> > Bit Rate       : 1.41M
>> > Sample Encoding: 16-bit Signed Integer PCM
>> > ```
>> >
>> > - converted file
>> > ```
>> > soxi /Users/martin/Downloads/split-test/vocals.mp3
>> >
>> > Input File     : '/Users/martin/Downloads/split-test/vocals.mp3'
>> > Channels       : 2
>> > Sample Rate    : 44100
>> > Precision      : 16-bit
>> > Duration       : 00:03:00.04 = 7939544 samples = 13502.6 CDDA sectors
>> > File Size      : 2.88M
>> > Bit Rate       : 128k
>> > Sample Encoding: MPEG audio (layer I, II or III)
>> > ```
>> >
>> > You can see that the duration is not the same which is weird and the number
>> > of samples also changed.
>> > In fact, 1544 samples have been added to the beginning of the file
>> >
>> > If I try to launch `sox -V vocals.mp3 vocals-trimmed.mp3 trim 1544s` it
>> > does not work
>>
>> MP3 files have to have a multiple of 1152 samples.  This can't be
>> avoided.  If the input isn't such a multiple, it will be padded by the
>> encoder.
>>
>>
>
> _______________________________________________
> Sox-users mailing list
> Sox-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/sox-users
>

-- 
Måns Rullgård


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

Re: Wav to Mp3 leads to an mp3 file that has a longer duration

[Martin Ratinaud]

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

Ok, thanks.

But would it be possible to
- add silence samples at the end of the wav file so that is is a multiple
of 1152
- convert it to an mp3
- and get the exact same number of samples with no change between wav
duration and mp3 duration

Because I just test with a wav file that is 8640000 samples = 7500 * 1152
and when I convert it to an mp3, I get 8641152 samples

Thanks again for your insights


-----------------------------------------------------------------------
*Martin RATINAUD*
-----------------------------------------------------------------------


On Mon, Dec 16, 2019 at 5:30 PM Måns Rullgård <mans@mansr.com> wrote:

> Martin Ratinaud <martinratinaud@gmail.com> writes:
>
> > Hi Måns and thanks very much
> >
> > Though it seems the resulting file is 7939544 samples
> >
> > and 7939544 / 1152 = 6891.965277777777
> >
> > So it's not a multiple of 1152 unless I'm missing something ?
>
> That difference is due to a rounding error in the stream length
> calculation.
>
> > On Mon, Dec 16, 2019 at 3:48 PM Måns Rullgård <mans@mansr.com> wrote:
> >
> >> Martin Ratinaud <martinratinaud@gmail.com> writes:
> >>
> >> > Hi all,
> >> >
> >> > I'm converting a file called vocals.wav to vocals.mp3
> >> >  vocals.wav
> >> > <
> >>
> https://drive.google.com/file/d/1he1eCJag1G8iGkgL932jy_mXuLT_khGM/view?usp=drive_web
> >> >
> >> > For this I'm using this command
> >> >
> >> > ```
> >> > sox vocals.wav vocals.mp3
> >> > ```
> >> > and here is the result of the corresponding files
> >> >
> >> > - original file
> >> > ```
> >> > soxi /Users/martin/Downloads/split-test/vocals.wav
> >> >
> >> > Input File     : '/Users/martin/Downloads/split-test/vocals.wav'
> >> > Channels       : 2
> >> > Sample Rate    : 44100
> >> > Precision      : 16-bit
> >> > Duration       : 00:03:00.00 = 7938000 samples = 13500 CDDA sectors
> >> > File Size      : 31.8M
> >> > Bit Rate       : 1.41M
> >> > Sample Encoding: 16-bit Signed Integer PCM
> >> > ```
> >> >
> >> > - converted file
> >> > ```
> >> > soxi /Users/martin/Downloads/split-test/vocals.mp3
> >> >
> >> > Input File     : '/Users/martin/Downloads/split-test/vocals.mp3'
> >> > Channels       : 2
> >> > Sample Rate    : 44100
> >> > Precision      : 16-bit
> >> > Duration       : 00:03:00.04 = 7939544 samples = 13502.6 CDDA sectors
> >> > File Size      : 2.88M
> >> > Bit Rate       : 128k
> >> > Sample Encoding: MPEG audio (layer I, II or III)
> >> > ```
> >> >
> >> > You can see that the duration is not the same which is weird and the
> number
> >> > of samples also changed.
> >> > In fact, 1544 samples have been added to the beginning of the file
> >> >
> >> > If I try to launch `sox -V vocals.mp3 vocals-trimmed.mp3 trim 1544s`
> it
> >> > does not work
> >>
> >> MP3 files have to have a multiple of 1152 samples.  This can't be
> >> avoided.  If the input isn't such a multiple, it will be padded by the
> >> encoder.
> >>
> >>
> >
> > _______________________________________________
> > Sox-users mailing list
> > Sox-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/sox-users
> >
>
> --
> Måns Rullgård
>

[-- Attachment #1.2: Type: text/html, Size: 5190 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

Re: Wav to Mp3 leads to an mp3 file that has a longer duration

[Måns Rullgård]

Martin Ratinaud <martinratinaud@gmail.com> writes:

> Ok, thanks.
>
> But would it be possible to
> - add silence samples at the end of the wav file so that is is a multiple
> of 1152
> - convert it to an mp3
> - and get the exact same number of samples with no change between wav
> duration and mp3 duration
>
> Because I just test with a wav file that is 8640000 samples = 7500 * 1152
> and when I convert it to an mp3, I get 8641152 samples

Apparently the LAME encoder is adding an extra frame for some reason.
MP3 is weird like this.  If you need the number of samples to be exact,
you'll have to switch a more modern codec.

-- 
Måns Rullgård


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

Re: Wav to Mp3 leads to an mp3 file that has a longer duration

[Martin Ratinaud]

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

Thanks for the tip!

What codec should I use then ?

Thanks
-----------------------------------------------------------------------
*Martin RATINAUD*
-----------------------------------------------------------------------


On Mon, Dec 16, 2019 at 9:44 PM Måns Rullgård <mans@mansr.com> wrote:

> Martin Ratinaud <martinratinaud@gmail.com> writes:
>
> > Ok, thanks.
> >
> > But would it be possible to
> > - add silence samples at the end of the wav file so that is is a multiple
> > of 1152
> > - convert it to an mp3
> > - and get the exact same number of samples with no change between wav
> > duration and mp3 duration
> >
> > Because I just test with a wav file that is 8640000 samples = 7500 * 1152
> > and when I convert it to an mp3, I get 8641152 samples
>
> Apparently the LAME encoder is adding an extra frame for some reason.
> MP3 is weird like this.  If you need the number of samples to be exact,
> you'll have to switch a more modern codec.
>
> --
> Måns Rullgård
>

[-- Attachment #1.2: Type: text/html, Size: 1777 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

Re: Wav to Mp3 leads to an mp3 file that has a longer duration

[Måns Rullgård]

Martin Ratinaud <martinratinaud@gmail.com> writes:

> Thanks for the tip!
>
> What codec should I use then ?

Depends on your needs.  Obviously, you have to use a codec supported by
whatever is going to read the file.

-- 
Måns Rullgård


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

Re: Wav to Mp3 leads to an mp3 file that has a longer duration

[Martin Ratinaud]

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

Ok and what would be one that
- compresses the file a lot
- is readable on the web

Thanks
-----------------------------------------------------------------------
*Martin RATINAUD*
-----------------------------------------------------------------------


On Tue, Dec 17, 2019 at 2:50 PM Måns Rullgård <mans@mansr.com> wrote:

> Martin Ratinaud <martinratinaud@gmail.com> writes:
>
> > Thanks for the tip!
> >
> > What codec should I use then ?
>
> Depends on your needs.  Obviously, you have to use a codec supported by
> whatever is going to read the file.
>
> --
> Måns Rullgård
>

[-- Attachment #1.2: Type: text/html, Size: 1317 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

Re: Wav to Mp3 leads to an mp3 file that has a longer duration

[Mikko Olkkonen]

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

If those are your requirements why dont you just stick to mp3? If your
additional requirements would be that 1) audio quality perception remains
OK and 2) number of samples remains intact then I believe that solution is
nonexisting. You must relax either compression or quality requirement. My
reasoning is as follows: you have a lot of samples in the original audio.
If you have all those samples (in any reasonable format) in the output file
you have large file again i.e. dont have much compression. In other words,
if you want compression you must do more drastic processing e.g. transform
the signal from "time domain" to "frequency domain" like mp3 does as far as
I know. After such compression there is no any meaningful concept of a
"sample" anymore. Thus you can not require that number of samples matches.
The fact that sox reports number of samples for mp3 does not change this
fact (maybe it should not report number of samples but some concept of a
block mp3 uses). I believe that additional difficulty (e.g. the discrepancy
you observed when you trimmed your signal) arises from aspects discussed in
the sox manual section "Accuracy". regards, Mikko



On Wed, Dec 18, 2019 at 6:02 AM Martin Ratinaud <martinratinaud@gmail.com>
wrote:

> Ok and what would be one that
> - compresses the file a lot
> - is readable on the web
>
> Thanks
> -----------------------------------------------------------------------
> *Martin RATINAUD*
> -----------------------------------------------------------------------
>
>
> On Tue, Dec 17, 2019 at 2:50 PM Måns Rullgård <mans@mansr.com> wrote:
>
>> Martin Ratinaud <martinratinaud@gmail.com> writes:
>>
>> > Thanks for the tip!
>> >
>> > What codec should I use then ?
>>
>> Depends on your needs.  Obviously, you have to use a codec supported by
>> whatever is going to read the file.
>>
>> --
>> Måns Rullgård
>>
> _______________________________________________
> Sox-users mailing list
> Sox-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/sox-users
>

[-- Attachment #1.2: Type: text/html, Size: 3277 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

Re: Wav to Mp3 leads to an mp3 file that has a longer duration

[Martin Ratinaud]

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

Ok thanks Mikko

Maybe I'm doing it wrong but here is my initial request

the number of samples is not really important to me. What does is that the
compression algorithm does not add data at the beginning of the file, which
it does now

Do you have any idea how I can achieve that ?

-----------------------------------------------------------------------
*Martin RATINAUD*
-----------------------------------------------------------------------


On Wed, Dec 18, 2019 at 11:44 AM Mikko Olkkonen <molkko@gmail.com> wrote:

> If those are your requirements why dont you just stick to mp3? If your
> additional requirements would be that 1) audio quality perception remains
> OK and 2) number of samples remains intact then I believe that solution is
> nonexisting. You must relax either compression or quality requirement. My
> reasoning is as follows: you have a lot of samples in the original audio.
> If you have all those samples (in any reasonable format) in the output file
> you have large file again i.e. dont have much compression. In other words,
> if you want compression you must do more drastic processing e.g. transform
> the signal from "time domain" to "frequency domain" like mp3 does as far as
> I know. After such compression there is no any meaningful concept of a
> "sample" anymore. Thus you can not require that number of samples matches.
> The fact that sox reports number of samples for mp3 does not change this
> fact (maybe it should not report number of samples but some concept of a
> block mp3 uses). I believe that additional difficulty (e.g. the discrepancy
> you observed when you trimmed your signal) arises from aspects discussed in
> the sox manual section "Accuracy". regards, Mikko
>
>
>
> On Wed, Dec 18, 2019 at 6:02 AM Martin Ratinaud <martinratinaud@gmail.com>
> wrote:
>
>> Ok and what would be one that
>> - compresses the file a lot
>> - is readable on the web
>>
>> Thanks
>> -----------------------------------------------------------------------
>> *Martin RATINAUD*
>> -----------------------------------------------------------------------
>>
>>
>> On Tue, Dec 17, 2019 at 2:50 PM Måns Rullgård <mans@mansr.com> wrote:
>>
>>> Martin Ratinaud <martinratinaud@gmail.com> writes:
>>>
>>> > Thanks for the tip!
>>> >
>>> > What codec should I use then ?
>>>
>>> Depends on your needs.  Obviously, you have to use a codec supported by
>>> whatever is going to read the file.
>>>
>>> --
>>> Måns Rullgård
>>>
>> _______________________________________________
>> Sox-users mailing list
>> Sox-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/sox-users
>>
> _______________________________________________
> Sox-users mailing list
> Sox-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/sox-users
>

[-- Attachment #1.2: Type: text/html, Size: 4794 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

Re: Wav to Mp3 leads to an mp3 file that has a longer duration

[Mikko Olkkonen]

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

Unfortunately I dont know any tool that guarantees such characteristic. I
have performed some simple sample size transformations with sox. In those
cases, some extra samples were added as reasoned (?) in the sox manual
"Accuracy"-section. I have never seen extra samples added at the beginning
of the output. I think that adding in the beginning is not good practice as
the meaningfull parts of input and output signals are not in sync anymore.
I dont know if some time domain to frequency domain compression algorithms
like mp3 has some understandable justification for adding into the
beginning or is it just an poor and unfortunate design choice.
regards, Mikko


On Wed, Dec 18, 2019 at 11:08 AM Martin Ratinaud <martinratinaud@gmail.com>
wrote:

> Ok thanks Mikko
>
> Maybe I'm doing it wrong but here is my initial request
>
> the number of samples is not really important to me. What does is that the
> compression algorithm does not add data at the beginning of the file, which
> it does now
>
> Do you have any idea how I can achieve that ?
>
> -----------------------------------------------------------------------
> *Martin RATINAUD*
> -----------------------------------------------------------------------
>
>
> On Wed, Dec 18, 2019 at 11:44 AM Mikko Olkkonen <molkko@gmail.com> wrote:
>
>> If those are your requirements why dont you just stick to mp3? If your
>> additional requirements would be that 1) audio quality perception remains
>> OK and 2) number of samples remains intact then I believe that solution is
>> nonexisting. You must relax either compression or quality requirement. My
>> reasoning is as follows: you have a lot of samples in the original audio.
>> If you have all those samples (in any reasonable format) in the output file
>> you have large file again i.e. dont have much compression. In other words,
>> if you want compression you must do more drastic processing e.g. transform
>> the signal from "time domain" to "frequency domain" like mp3 does as far as
>> I know. After such compression there is no any meaningful concept of a
>> "sample" anymore. Thus you can not require that number of samples matches.
>> The fact that sox reports number of samples for mp3 does not change this
>> fact (maybe it should not report number of samples but some concept of a
>> block mp3 uses). I believe that additional difficulty (e.g. the discrepancy
>> you observed when you trimmed your signal) arises from aspects discussed in
>> the sox manual section "Accuracy". regards, Mikko
>>
>>
>>
>> On Wed, Dec 18, 2019 at 6:02 AM Martin Ratinaud <martinratinaud@gmail.com>
>> wrote:
>>
>>> Ok and what would be one that
>>> - compresses the file a lot
>>> - is readable on the web
>>>
>>> Thanks
>>> -----------------------------------------------------------------------
>>> *Martin RATINAUD*
>>> -----------------------------------------------------------------------
>>>
>>>
>>> On Tue, Dec 17, 2019 at 2:50 PM Måns Rullgård <mans@mansr.com> wrote:
>>>
>>>> Martin Ratinaud <martinratinaud@gmail.com> writes:
>>>>
>>>> > Thanks for the tip!
>>>> >
>>>> > What codec should I use then ?
>>>>
>>>> Depends on your needs.  Obviously, you have to use a codec supported by
>>>> whatever is going to read the file.
>>>>
>>>> --
>>>> Måns Rullgård
>>>>
>>> _______________________________________________
>>> Sox-users mailing list
>>> Sox-users@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/sox-users
>>>
>> _______________________________________________
>> Sox-users mailing list
>> Sox-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/sox-users
>>
> _______________________________________________
> Sox-users mailing list
> Sox-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/sox-users
>

[-- Attachment #1.2: Type: text/html, Size: 6182 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