* Wav to Mp3 leads to an mp3 file that has a longer duration @ 2019-12-11 14:26 Martin Ratinaud 2019-12-11 17:18 ` Jeremy Nicoll - ml sox users 2019-12-16 11:48 ` Måns Rullgård 0 siblings, 2 replies; 16+ messages in thread From: Martin Ratinaud @ 2019-12-11 14:26 UTC (permalink / raw) To: sox-users [-- 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Wav to Mp3 leads to an mp3 file that has a longer duration 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-16 11:48 ` Måns Rullgård 1 sibling, 1 reply; 16+ messages in thread From: Jeremy Nicoll - ml sox users @ 2019-12-11 17:18 UTC (permalink / raw) To: 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Wav to Mp3 leads to an mp3 file that has a longer duration 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 0 siblings, 1 reply; 16+ messages in thread From: Martin Ratinaud @ 2019-12-12 4:18 UTC (permalink / raw) To: sox-users [-- 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Wav to Mp3 leads to an mp3 file that has a longer duration 2019-12-12 4:18 ` Martin Ratinaud @ 2019-12-12 17:05 ` Jeremy Nicoll - ml sox users 2019-12-16 5:10 ` Martin Ratinaud 0 siblings, 1 reply; 16+ messages in thread From: Jeremy Nicoll - ml sox users @ 2019-12-12 17:05 UTC (permalink / raw) To: 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Wav to Mp3 leads to an mp3 file that has a longer duration 2019-12-12 17:05 ` Jeremy Nicoll - ml sox users @ 2019-12-16 5:10 ` Martin Ratinaud 0 siblings, 0 replies; 16+ messages in thread From: Martin Ratinaud @ 2019-12-16 5:10 UTC (permalink / raw) To: sox-users [-- 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Wav to Mp3 leads to an mp3 file that has a longer duration 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-16 11:48 ` Måns Rullgård 2019-12-16 12:02 ` Martin Ratinaud 1 sibling, 1 reply; 16+ messages in thread From: Måns Rullgård @ 2019-12-16 11:48 UTC (permalink / raw) To: Martin Ratinaud; +Cc: sox-users 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Wav to Mp3 leads to an mp3 file that has a longer duration 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 0 siblings, 1 reply; 16+ messages in thread From: Martin Ratinaud @ 2019-12-16 12:02 UTC (permalink / raw) To: Måns Rullgård; +Cc: sox-users [-- 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Wav to Mp3 leads to an mp3 file that has a longer duration 2019-12-16 12:02 ` Martin Ratinaud @ 2019-12-16 13:30 ` Måns Rullgård 2019-12-16 13:36 ` Martin Ratinaud 0 siblings, 1 reply; 16+ messages in thread From: Måns Rullgård @ 2019-12-16 13:30 UTC (permalink / raw) To: Martin Ratinaud; +Cc: sox-users 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Wav to Mp3 leads to an mp3 file that has a longer duration 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 0 siblings, 1 reply; 16+ messages in thread From: Martin Ratinaud @ 2019-12-16 13:36 UTC (permalink / raw) To: Måns Rullgård; +Cc: sox-users [-- 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Wav to Mp3 leads to an mp3 file that has a longer duration 2019-12-16 13:36 ` Martin Ratinaud @ 2019-12-16 17:44 ` Måns Rullgård 2019-12-17 10:04 ` Martin Ratinaud 0 siblings, 1 reply; 16+ messages in thread From: Måns Rullgård @ 2019-12-16 17:44 UTC (permalink / raw) To: Martin Ratinaud; +Cc: sox-users 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Wav to Mp3 leads to an mp3 file that has a longer duration 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 0 siblings, 1 reply; 16+ messages in thread From: Martin Ratinaud @ 2019-12-17 10:04 UTC (permalink / raw) To: Måns Rullgård; +Cc: sox-users [-- 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Wav to Mp3 leads to an mp3 file that has a longer duration 2019-12-17 10:04 ` Martin Ratinaud @ 2019-12-17 10:50 ` Måns Rullgård 2019-12-18 4:00 ` Martin Ratinaud 0 siblings, 1 reply; 16+ messages in thread From: Måns Rullgård @ 2019-12-17 10:50 UTC (permalink / raw) To: Martin Ratinaud; +Cc: sox-users 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Wav to Mp3 leads to an mp3 file that has a longer duration 2019-12-17 10:50 ` Måns Rullgård @ 2019-12-18 4:00 ` Martin Ratinaud 2019-12-18 7:43 ` Mikko Olkkonen 0 siblings, 1 reply; 16+ messages in thread From: Martin Ratinaud @ 2019-12-18 4:00 UTC (permalink / raw) To: Måns Rullgård; +Cc: sox-users [-- 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Wav to Mp3 leads to an mp3 file that has a longer duration 2019-12-18 4:00 ` Martin Ratinaud @ 2019-12-18 7:43 ` Mikko Olkkonen 2019-12-18 9:06 ` Martin Ratinaud 0 siblings, 1 reply; 16+ messages in thread From: Mikko Olkkonen @ 2019-12-18 7:43 UTC (permalink / raw) To: sox-users [-- 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Wav to Mp3 leads to an mp3 file that has a longer duration 2019-12-18 7:43 ` Mikko Olkkonen @ 2019-12-18 9:06 ` Martin Ratinaud 2019-12-19 9:52 ` Mikko Olkkonen 0 siblings, 1 reply; 16+ messages in thread From: Martin Ratinaud @ 2019-12-18 9:06 UTC (permalink / raw) To: sox-users [-- 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Wav to Mp3 leads to an mp3 file that has a longer duration 2019-12-18 9:06 ` Martin Ratinaud @ 2019-12-19 9:52 ` Mikko Olkkonen 0 siblings, 0 replies; 16+ messages in thread From: Mikko Olkkonen @ 2019-12-19 9:52 UTC (permalink / raw) To: sox-users [-- 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2019-12-19 9:53 UTC | newest] Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 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 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
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).